This is not a complete guide how to properly setup your email server. There are many gotchas, starting from your host and postfix configuration, DNS SPF/TXT and DKIM records, rDNS PTR/TXT records, SSL/TLS certificates etc. Each and every one of them can prevent your emails from being delivered, marked as spam or not even being sent in the first place. Instead, in this brief article we are going to describe how we’ve fixed specific 550-5.7.1 error in a once perfectly working setup.
A while ago, we’ve moved almost all our websites from the old VPS server to a brand new hosting service. We left only one project there, as it has very low traffic / requirements, and the old hosting was perfectly fine for that particular case. And that’s when the problems with the old server started.
HOW TO FIX BOUNCED EMAIL FROM YOUR SERVER BY GOOGLE GMAIL
However, couple of weeks later we’ve noticed that our email notifications completely stopped working on old server and that our email traffic is suddenly missing. What happened?
First, we tried to send couple of dummy test emails to known accounts (all gmail). Nothing. Silence. We then wrote a simple server-side script, just to be sure our CMS is not acting strange. Again nothing. Silence.
Well, server runs on Ubuntu using Postfix, and we checked mail.log file in /var/log directory, and noticed these strange errors about bounced email notifications from Google’s GMAIL servers:
12:00:00 myserver postfix/smtp: 24EA53C6008X: to=<email@example.com>, relay=gmail-smtp-in.l.google.com[22.214.171.124]:25, delay=1.6, delays=0.75/0.01/0.46/0.4, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[126.96.36.199] said:550-5.7.1 This message does not have authentication information or fails to pass 550-5.7.1 authentication checks. To best protect our users from spam, the 550-5.7.1 message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.1 information
After visiting the https://support.google.com/mail/answer/81126#authentication we were faced with overwhelming amount of information. Plus, we don’t really use “bulk” email services on our server, quite the opposite in fact – email traffic is very very low, only couple of notification emails per month, but still it was important that it works. What’s reffered here as ‘bulk email senders’ are automated mass email services.
Now, many parameters mentioned in the above article are about DNS configurations, SPF TXT records, SSL certificates etc. All the things we actually never touched/changed/modified for years! So, how can they be suddenly wrong, if our server’s IP address didn’t change in the meantime?
Also, as this is very important, we have checked and verified that our domain or server IP was not listed in any publicly available email spam and IP address blacklists (e.g. SpamHaus.org, DNSBL.info). This is important, as many times your server(s) may be hacked and abused to send bulk spam emails, without your knowledge and consent.
Back to the drawing board…
Then, it occurred to us that we had multiple virtual domains in the good old days, and that our ‘main’ domain was set in Postifx’s main.cf configuration file. Since we moved that ‘main’ domain few months ago to a new home, and we had only one domain left, it was suspicious in the eyes of Google why are we pretending to be sending emails from Domain A using Domain B ? It makes sense, we have to admit.
Once we realized this, it was easy to fix it! Simply, edit your Postfix /etc/postfix/main.cf file and under myhostname enter your actual website address (without http/https/www prefixes):
myhostname = mywebsite.com // <- this entry was wrong!
Lastly, restart Posfix service. For example, in Ubuntu 14/16/18 you can do it like this in the terminal / ssh console (you need to use sudo prefix and verify your account with a proper password if your user does not have root privileges):
admin@myserver:~# sudo service postfix restart * Stopping Postfix Mail Transport Agent postfix [ OK ] * Starting Postfix Mail Transport Agent postfix [ OK ] admin@myserver:~#
No need to reboot your entire server, and in fact, your emails should instantly start being delivered again!