Home » Php » email – Why shouldn't I use PHP's mail() function?

email – Why shouldn't I use PHP's mail() function?

Posted by: admin April 23, 2020 Leave a comment


The general opinion when it comes to sending email messages in PHP is to stay clear of PHP’s built-in mail() function and to use a library instead.

What I want to know are the actual reasons and flaws in using mail() over a library or extension. For example, the commonly specified headers that aren’t included in a standard mail() call.

How to&Answers:


Disadvantages of the PHP mail() function

In some cases, mails send via
PHP mail() did not receive the
recipients although it was send by WB
without any error message. The most
common reasons for that issue are
listed below.

  • wrong format of mail header or content
    (e.g. differences in line break
    between Windows/Unix)
  • sendmail not
    installed or configured on your server
  • the mail provider of the
    recipeint does not allow mails send by
    PHP mail(); common spam protection

Errors in the format of header or
content can cause that mails are
treated as SPAM. In the best case,
such mails are transfered to the spam
folder of your recipient inbox or send
back to the sender. In the worst case,
such mails are deleted without any
comment. If sendmail is not installed
or not configured, no mails can be
send at all.

It is common practice by free mail
provider such as GMX, to reject mails
send via the PHP function mail(). Very
often such mails are deleted without
any information of the recipient.


PHP’s mail() is said to garble headers and runs slowly. I can’t say this from personal experience because I’ve never used it, because, like you, I’ve always been advised against it. If you look at the comments on the entry for mail() in the PHP manual, you can see some of the problems people have with it (esp. with headers).

It’s definitely not suited for sending any substantial amount of email, because, according to the manual itself,

It is worth noting that the mail()
function is not suitable for larger
volumes of email in a loop. This
function opens and closes an SMTP
socket for each email, which is not
very efficient.

For the sending of large amounts of
email, see the » PEAR::Mail, and »
PEAR::Mail_Queue packages.

AFAIK, it’s never preferable (performance-wise) to open and close a socket for each message you send regardless of the amount of mail you’re sending.

Basically, it’s a function that works, but not very well, and is eclipsed by a number of better libraries.


What matters is not only the mail() function but also the smtp server you use in conjunction. I’ve used three different smtp servers with php: postfix, qmail,sendmail.

In my experience postfix was the easiest one to work with php mail() but even postfix had some problems. You will encounter small bugs. It could be things like the “to” recipients receiving correctly structured emails and “bcc” recipients receiving corrupt emails. You’ll lose a lot of time trying to figure out these bugs. And your fixes will make your code not work properly with the other smtp servers.

The problem lays with the handling of the email header and PHP unfortunately does a poor job about that. Recently I switched to “PHP Mailer” library. In our website we have two smtp servers, one with postfix, and one with qmail. “PHP Mailer” worked with both of them with no additional configuration.


The biggest reason is that mail() can talk directly to a mail server, and if you don’t know what you are doing when sanitizing your input, a hacker may be able to spoof your mail server into sending mail other than what you intend. Most third party libraries have better sanitation (or better API’s) to help prevent this.