Postfix Not Delivering To Google Gmail Addresses

I’ve recently spent the entire week getting my Postfix email server up and running. It’s been a journey to say the least. Installing the server itself is a breeze, and Postfix for the most part works out of the box. As long as you have your MX records properly configured Postfix receives email for your domain just fine.

The problems come when you try to send email. Gmail accounts are particularly difficult to send to. Without proper authentication and encryption methods in place, your emails rarely get delivered.

In fact, they don’t even get marked as spam…Google just flat out rejects your emails. As you can see, I was getting a 550-5.7.28 error. “Our system has detected an unusual rate of unsolicited mail…”

Google rejecting my emails. Not a very nice thing!

This post is not going to baby you through the entire process but will serve as a high level overview of what needs to happen before Google will start accepting your emails.

IP Blacklisted?

Initially I started to panic thinking my IP had been used in the past for spamming purposes. This would no doubt be an almost impossible obstacle to overcome. I took my server IP and plugged it in to a free online tool which compared it to known blacklisted addresses. I was relieved to find my IP was not on any known blacklist database.

So what was going on then?

Doing my own research I began to uncover there was a lot more to running a Postfix server than I thought.

SPF (Sender Policy Framework)

SPF is an email authentication strategy which informs other email servers what systems are allowed to send email on behalf of your domain. SPF information is sent as part of the email headers. When other email servers receive email from your domain, it checks the IP address of the sender and compares it to the IP address listed in your DNS TXT records. Since you are the only one with access to the DNS configuration, the rest of the world will take what’s in there as gospel. This type of authentication prevents other spammers from spoofing your domain. Only IP addresses listed in the records are allowed to send email.

Below is an example of my own SPF record:

DKIM (DomainKeys Identified Mail)

DKIM is another authentication mechanism used to prevent spammers and other raiders of the internet wasteland. With DKIM, your email server digitally signs every single email you send with a private key. When the recipient server receives your email it attempts to decrypt the supplied signature with the public key published in your DNS records. If a server is unable to decrypt the signature, or a signature is not present, it discards the message as spam (in most cases.)

On my server I used OpenDKIM to create my public/private key combination.

I then published the public key in my DNS as a TXT record:

Email servers use your public key to verify the authenticity of your emails

TLS Encryption

In my research I could not find any information as to whether or not TLS encryption was a requirement for email servers. I do know that TLS encryption was one of the first things I did setting up Postfix. It seems like something you’d want to have considering most email servers and websites provide encrypted connections. Despite this, Google still refused my emails suggesting that it’s either not important, or that it’s simply one piece of the puzzle.

I used LetsEncrypt to create all the certificates for my domain and then configured Postfix to secure the email.

Reverse DNS

This was the final piece to the puzzle. I had it all. SPF, DKIM, and TLS encryption. Despite all of this my emails were still getting flat out rejected by Google. It wasn’t until I changed my server hostname to the name of my domain that Google finally started accepting my email.

Reverse DNS does the opposite of what DNS typically does. Instead of mapping a name to an IP address, it maps an IP address to a name. This allows receiving servers to further identify who is actually sending the email. When an MTA receives email from your server, it will check that the IP address presented resolves to the appropriate domain name/name of the sending server.

Using the control panel for my Digital Ocean droplet I changed the name of my server to match my domain. Digital Ocean automatically created the appropriate PTR records. You may have to contact your provider to change PTR settings unless you have a dedicated IP and more advanced control.

Conclusion

There are perils to running your own Postfix email server. It can take weeks to get a proper configuration up and running. Despite the complexity of the MTA, once you get things setup appropriately and work out the kinks they will treat you well. There are many authentication and encryption mechanisms which must be present in order for the rest of the internet to take you seriously.

 

Leave a Comment