When the internet really started catching steam, email was one of it’s flagship services. Back then it was simple but somewhat archaic – it’s goal was to be redundant enough to get your message through even if it required several tries. It was the digital equivalent of:
Neither snow nor rain nor heat nor gloom of night stays these couriers from the swift completion of their appointed rounds.
Think of all the stuff that has been added atop of email such as encryption and MIME encoding to send attachments. But it was our must-deliver mantra that was used by the spammers for their personal gain. Then even more layers for spam and virus filtering were added. Spammers have sort of negated that “must deliver” image of email to where I click send and think, “I hope it will be delivered.”
God Save the Email Administrator
I used to manage my own email server. Postfix SMTP, Courier POP/IMAP, Amavis/Freshclam SPAM & Antivirus. I don’t like being an email administrator. It’s frankly too much to keep up with. I just want email to work. Recently I switched my self-managed email to google mail. I figured it would be a set-it-and-forget-it type of deal. I was wrong.
The reason I still had issues is because I still wanted control of my DNS. Turns out there is a lot contained within DNS besides MX records that can effect mail delivery. I found this DNS TXT record page at google that got me started, but each individual entry could use some additional explanation.
Before moving to google, I had added this SPF record:
IN SPF "v=spf1 mx a ip4:188.8.131.52 -all" IN TXT "v=spf1 mx a ip4:184.108.40.206 -all"
I’m not sure why the SPF record exists on its own and in a TXT record, but I don’t really care, as long as email goes through. But it wasn’t going through. The problem with this set up is, it tells the receiver that anything received from my domain is good if it came from my server IP (mostly system & website generated notifications). But my google mail comes from google, not my IP. So I was getting bounce-backs from picky providers. The solution was to add google into the mix and loosen the failure type on the “all” mechanism:
IN SPF "v=spf1 mx a ip4:220.127.116.11 include:_spf.google.com ~all" IN TXT "v=spf1 mx a ip4:18.104.22.168 include:_spf.google.com ~all"
Google Site Verification
This is one of those things you probably already did by putting a HTML file on your site to prove to google that you own it. This gives your ownership even more credibility. It’s not required for email delivery, but since I was going over the list of TXT records, I figured I’d add it. Locating this section in the webmaster tools is tricky, so I made a video:
Add the verification key to your DNS file:
IN TXT "google-site-verification=DqPNHNAJ5DnBpLr1TzZe38vQucZZ49wnCGiU9e75RTo"
After saving your changes and restarting bind, you can test to make sure your new TXT entries are showing using
dig. I recommend using the ‘@nameserver’ parameter so you can query your own nameserver before the changes have propagated internet-wide.
$ dig @ns.foell.org TXT foell.org ... ;; QUESTION SECTION: ;foell.org. IN TXT ;; ANSWER SECTION: foell.org. 604800 IN TXT "v=spf1 mx a ip4:22.214.171.124 include:_spf.google.com ~all" foell.org. 604800 IN TXT "google-site-verification=DqPNHNAJ5DnBpLr1TzZe38vQucZZ49wnCGiU9e75RTo"
I don’t know the full details of how DKIM works, but it’s an encryption key added to your domain name which helps insure that the email received was sent from who you think it was. It works because your email provider (google) adds a DKIM domain key to the header of the email, and the receiver can validate it by using the DKIM public key saved on your DNS record.
Here’s how to get your DKIM key:
Add it to your DNS file:
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnCPVKm4lCMECaU/eFOQewJaGpAk/hx4D8pQCRQ+Iq1Y7pUL09iyFImWRveBTBRccOEy/gchsZoseBVMvAS4L86GQhUgi+4tk4VvpxkQLgbuPouoLs54W4kIDUhgZcmNe4fBjoIMgHQvRfXc1G6MnwBZcU3a0URtxfhExFCflfUwIDAQAB"
Verify that it has been saved using
$ dig @ns.foell.org TXT google._domainkey.foell.org
DMARC combines both DKIM and SPF to combat phishing and protect your domain’s reputation. I added this to my bind resource record:
_dmarc IN TXT "v=DMARC1; p=quarantine\; pct=100\; rua=mailto:email@example.com"
$ dig @ns.foell.org TXT _dmarc.foell.org
Again, I’m not exactly sure how it all works, but I now get informational reports from servers that I’ve sent emails to, letting me know my “standing” from an email perspective as they see it. I don’t plan on being proactive about them, but they’ll be useful if I start getting bounce messages again.