PHP Mail() Function on Cpanel Hosts Going to SPAM

Question

Email sent from the PHP mail() function hosted on a Cpanel account frequently ends up in SPAM (all the time for @outlook.com, some of the time for @gmail.com)

I've determined it is NOT due to the content of the message but due to something in the headers. My best guess is that it's either because there's a header field indicating the email was sent by a PHP script, or it's the fact that no matter if you set the From: Reply-To: and Return-Path: to the same email address, the SMTP server is always showing the email was sent from {cpanel account username}@servername.serverdomain.com and this does not match the From/Reply-To address and it appears it overrides any Return-Path address I use to the {cpanel account username}@servername.serverdomain.com

As you know Web apps can send email on behalf of a user where the user doesn't have an email address hosted on the same domain that the application is running from. So the server may be serverdomain.com and the user's email might be something@someotherdomain.com

Examining the headers of the test script or the emails sent from, the SMTP server is always showing the email was sent from cpanel-account-username@server1.serverdomain.com Part of the header after coming through to Gmail shows this:

Received-SPF: pass (google.com: domain of cpanel-account-username@server1.serverdomain.com designates XXX.XXX.XXX.XXX as permitted sender) client-ip=XXX.XXX.XXX.XXX;
To: testto@gmail.com
Subject: Something
From: From Name <something@someotherdomain.com>
Reply-To: something@someotherdomain.com
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1

If I was able to change the header so it thinks the email was sent from something@someotherdomain.com instead of cpanel-account-username@server1.serverdomain.com I don't think that would work as the server1.serverdomain.com's IP address would not match the MX or SPF records for someotherdomain.com since the cpanel account's domain does not handle email for that application user's email address's domain.

Some coders out there running PHP on CPanel (or using PHP mail()) in general must have run into this before and wondering if anyone found any solutions? Should I switch to PhpMailer for better header control and if so what should I change?

Maybe https://stackoverflow.com/questions/5935087/how-do-i-prevent-mails-sent-through-php-mail-from-going-to-spam will give some useful information. — Nigel Ren, Sep 23 '20 at 17:34

score 0 · Answer 1 · answered Sep 23 '20 at 17:48

X-PHP-Script and X-PHP-Originating-Script are bolted on to emails by default if you initiate the PHP mail function - many people are using this to send emails to both Gmail and Hotmail without trouble so I suspect it is not header related.

Spam filtering is both an art and a science. Usually, an email starts with 0 score, is put through 100s of tests and at the end of it a score is taken, and if it meets a threshold, it is put in the spam folder.

Sometimes this is not within your control.

If it is a shared hosting server with 100s or even 1000s of sites on, another website on the server could be compromised, sending out spam emails, and the server IP could be listed on a known blacklist.

You can use MX Toolbox to check this: https://mxtoolbox.com/blacklists.aspx

Public providers such as Gmail and Hotmail also run their own internal blacklists - they will identify if their own users are reporting spam emails from a particular IP, and take appropriate action to protect their users across the board.

It can also be because of reverse DNS. server1.serverdomain.com resolves to XXX.XXX.XXX.XXX but does XXX.XXX.XXX.XXX resolve to server1.serverdomain.com?

If it doesn't, this can add negative score when a spam filter is scoring an email.

MX toolbox can also help here: https://mxtoolbox.com/ReverseLookup.aspx

Also, sometimes if the sender domain (server1.serverdomain.com) does not have both an A record and MX record specified, it causes spam filters to add score to an email. In some cases shared hosts set up servers with an A record, but not an MX record.

I would perform checks on the above 3 options and if any fail, go to your hosting provider and ask them to look in to it. I have written them in order of severity.

SPF is passing in this instance so doesn't look like the problem.

score 0 · Answer 2 · answered Sep 23 '20 at 19:25

As you know Web apps can send email on behalf of a user where the user doesn't have an email address hosted on the same domain that the application is running from. So the server may be serverdomain.com and the user's email might be something@someotherdomain.com

You can try to do this, but generally speaking it will not work, and you shouldn't try. It's forgery, and will simply result in you getting blacklisted or blocked. Just don't.

Many services will only allow you to send from your account address, and will ignore any other address. Gmail allows you to pre-configure additional aliases, but you can't send from arbitrary addresses, largely because it's usually forgery.

Implement SPF, DKIM (preferably in your local mail server rather than in PHP), and DMARC with the strictest settings you can live with, ensure your reverse IPs match your forward names. Use VERP addressing for your envelope senders so that you can identify bounces from misbehaving mail servers.

I'd recommend not using PHP's mail() function (it's slow, unsafe, and inflexible) – send via SMTP to localhost instead. Don't build your own messages either – use a library (like PHPMailer that you tagged this question with), because you will run into encoding and other problems.

Gmail's spam filtering is extremely variable, but a look at the headers of a received message will tell you why it's unhappy with your message.

There is an article about these kind of deliverability issues in the PHPMailer wiki.

PHP Mail() Function on Cpanel Hosts Going to SPAM

2 Answers2