Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

Data you need before you start:

[table] Information,for example
Return path / bounce address,bounces.myesp.com
Mailserver hostname,mail4.myesp.com
Mailserver external address,192.0.2.4
DKIM “d=”,greatbigmarketer.com
DKIM selector,oct2012.myesp
From / Reply-To domain,greatbigbrand.com
[/table]

What this looks like in email headers:

Return-Path: <verp-gobbledygook@bounces.myesp.com>
Received: from mail4.myesp.com (mail4.myesp.com [192.0.2.4]) by ...
DomainKey-Signature: d=greatbigmarketer.com; s=oct2012.myesp; b= ...
From: Happy Friendly Brand <replies@greatbigbrand.com>

How to check your DNS

You can use the simple DNS lookup tools at xnnd.com to check existing DNS – I’m using the other dns lookup for these examples. Enter a hostname or IP address and the record type you want to look up, hit Submit and it will either give you one or more answers …

wordtothewise.com mail is handled by 10 m.wordtothewise.com.
m.wordtothewise.com has address 184.105.179.154

… or it’ll give you an error, meaning that the record you were looking for doesn’t exist, or is broken in some way. For the shallow checking we’re doing here any mention of NXDOMAIN, NOERROR or SERVFAIL means that the record doesn’t exist or isn’t set up correctly.

What everyone needs to publish

You need forward and reverse DNS for your MTA host name, it’s just the right thing to do. You need to be able to send mail to your return path, so you can handle bounces. And you need to be able to send mail to your From: or Reply-To: address, so recipients can contact you.
[table] Check,Type,Query,Expected result
Forward DNS,A,mail4.myesp.com,… has address 192.0.2.4
Reverse DNS,PTR,192.0.2.4,… pointer mail4.myesp.com
Return path,MX,bounces.myesp.com,… is handled by something
From,MX,greatbigbrand.com,… is handled by something
[/table]

If you’re using authentication

Authentication is a way of proving that a piece of email was sent by you – a very good thing if you’re relying on your reputation to get good email delivery. It doesn’t let you prove that a piece of email wasn’t sent by you, that’s a different thing we’ll cover later.
There are two commonly used authentication methods, SPF and DKIM.
SPF is in some ways the simplest, it’s just a DNS record that lists the IP addresses you expect to send email from. The way the data is published can be rather complex, though, with options to include lists of addresses from elsewhere or imply them from other DNS entries. It’s pretty much impossible to check that a complex SPF setup is correct without either specialized tools or a fairly deep understanding of the SPF spec. You can do some basic checks, though.
DKIM is more complex to implement – it requires your mailserver to be set up to cryptographically sign outgoing mail, based on a key you publish via DNS. But the DNS aspect of it is simpler. There’s just one relevant DNS record to publish, the DKIM key. The hostname it’s published at isn’t one that appears explicitly in your mail, though, rather it’s created from two separate strings – the selector and the “d=” value glued together with the string “._domainkey.”. You choose those when you configure DKIM signing on your mailserver, and just have to make sure that the DNS matches the values you’re using. For our example selector of “oct2012.myesp” and “d=” of “greatbigmarketer.com we’d look up “oct2012.myesp._domainkey.greatbigmarketer.com”.
dkimcore.org covers setting DNS up for senders in more detail.
[table] Check,Type,Query,Expected result
SPF,TXT,bounces.myesp.com,v=spf1 something ~all
DKIM,TXT,oct2012.myesp._domainkey.greatbigmarketer.com,v=DKIM1 …
[/table] What the something should be in the SPF record is a tricky question. If it includes the IP address of your smarthost or an address range that includes your smarthost – such as “ip4:192.0.2.4” or “ip4:192.0.2.0/26” – that’s good. If it has the string “include:something” that means you’re referring to someone else’s SPF setup, and it’s probably OK. If your smarthost is set up to handle it’s own bounces – meaning the MX record of the bounce domain points at the external IP of the smarthost – then “mx” covers it. If you’re a tiny setup, where there’s a single server that handles all your email, inbound and outbound, as well as hosting your website then “a” will work. If it’s anything other than that, you should look harder at the SPF record.
There’s a tool at dkimcore.org/tools that will check your published DKIM records in more depth, given the selector and “d=” values.

Repudiation

Repudiation is the opposite of authentication. It’s a way to let you say that a particular email wasn’t sent by you. DMARC is the only current approach being used for this. Whether DMARC is appropriate for you, and how to set it up, is a much deeper issue than a few paragraphs, but checking whether a domain is publishing it is fairly simple.
[table] Check,Type,Query,Expected result
DMARC,TXT,_dmarc.greatbigbrand.com,v=DMARC1 …
[/table]

And finally

This is very shallow coverage of DNS. There are a lot of subtleties it glosses over, and it doesn’t touch on DNS for URLs used in the body of the mail at all.
I hope it’s a useful quick checklist for you to sanity check your DNS setup.