SMTP error from remote mail server after end of data: 550 Action not taken

Have you set up a new mail server, configured DKIM and SPF correctly, but for some reason you still have email being intermittently rejected when forwarding to Gmail and other services with messages that are unhelpful like: –

SMTP error from remote mail server after end of data: 550 Action not taken

If that’s the case, you may need to set up a DNS PTR record for your mail server’s IP address. It appears that, depending on the circumstances of the forwarded email and the domain performing the forwarding, this step is crucial to ensure smooth email forwarding delivery.

Of course, you should ensure that the PTR record IP address and hostname match what you see in the SMTP header.

Update 31st Oct 2018:

Since writing this article a few days ago, I encountered some further issues with reliable mail delivery, specifically through Exim on cPanel.

Normally, when configuring forwarding, you should also enable SRS (Sending Rewriting Scheme), which adds additional information to the mail headers to inform the receiving MTA that the email has been forwarded and “signed” by the forwarding MTA (in my case, Exim on a cPanel/centOS installation).

While this was enabled in the Exim config, I did not realise that it wasn’t actually operating correctly.

Below is what you SHOULD see when SRS is operating correctly (forwarding to a Gmail account): –

Received-SPF: pass (google.com: domain of srs0=lu0ygv=nl=senderoriginaldomain.com=senderfirstpartemail@yourforwardingdomain.com designates <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
Authentication-Results: mx.google.com;
dkim=pass header.i=@yourforwardingdomain.com header.s=default header.b=HnochmZG;
dkim=pass header.i=@senderoriginaldomain.com header.s=default header.b=C8B9JAt8;
spf=pass (google.com: domain of srs0=lu0ygv=nl=senderoriginaldomain.com=senderfirstpartemail@yourforwardingdomain designates <your MTA IP> as permitted sender) smtp.mailfrom=”SRS0=Lu0yGv=NL=senderoriginaldomain=senderfirstpartemail@yourforwardingdomain.com”;

Here’s what it looks like WITHOUT SRS (again, forwarding to a Gmail account): –

Received-SPF: fail (google.com: domain of senderfirstpartemail@senderoriginaldomain.com does not designate <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of senderfirstpartemail@senderoriginaldomain.com does not designate <your MTA IP> as permitted sender) smtp.mailfrom=senderfirstpartemail@senderoriginaldomain.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=senderoriginaldomain.com

As you can see, in the SRS example, the sender information is modified to include information about the forwarding domain (i.e. your domain) so that it is clear that your MTA is not trying to forge or spoof the original sender’s domain.

In my case, SRS was turned on properly, however it seems that the cPanel archiving functionality was somehow breaking this on the version of cPanel that I was running. As a workaround, I will be disabling email archiving to ensure that SRS is applied to my forwarded messages and applying any cPanel updates as they are released that will hopefully resolve the issue.

Final Update 3rd November 2018:

Further to my last update, it seems that I had another factor contributing to this issue – Namecheap (my previous provider) had been intercepting my SMTP traffic through the use of a transparent SMTP proxy of some description (they were not forthcoming with information).

It seems that this was also causing mail delivery issues that were causing the likes of Gmail and Microsoft to return 550 back to my server after transmitting messages.

After unsuccessfully attempting to persuade Namecheap to allow me to bypass this technology, I have moved to a new VPS provider and my emails are again being delivered perfectly.