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 ( domain of designates <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
dkim=pass header.s=default header.b=HnochmZG;
dkim=pass header.s=default header.b=C8B9JAt8;
spf=pass ( domain of designates <your MTA IP> as permitted sender) smtp.mailfrom=””;

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

Received-SPF: fail ( domain of does not designate <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
spf=fail ( domain of does not designate <your MTA IP> as permitted sender);
dmarc=fail (p=NONE sp=NONE dis=NONE)

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.

8 thoughts on “SMTP error from remote mail server after end of data: 550 Action not taken”

  1. I’m also having this issue and namecheap refuse to acknowledge it. Can you recommend a new provider that will not have these issues?

  2. Hi

    Thanks for the blog post. Unfortunately I am also user of namecheap VPS and encountering below errors randomly (4/10) of my emails.
    host[] said:
    550 Action not taken (in reply to end of DATA command)

    How did you come to know that it was namecheap intercepting the emails and hence mail server is not able to send the emails and what was the response from namecheap on this. I have my web server as well as Postfix mail server configured on their VPS.

  3. I know I’m super late to this post, but in case it helps anyone else using NameCheap VPS, here’s what I did to fix this issue… in WHM go to the Resolver Configuration and change the default IPs to: (primary) (secondary)

    I’m not 100% sure this won’t break something, so be sure to keep the default IPs handy in case you need to revert, but immediately mail started being delivered after this update.

  4. To those who have been having problems with Namecheap and are looking at alternatives, I ended up finding a local infrastructure provider here in Australia that gives you a virtual machine that just has direct internet access with nothing funky in the way.

    For those in Australia, the provider I went with is Network Presence (

Leave a Reply

Your email address will not be published. Required fields are marked *