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.

Related Posts

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More

ESPs, Non-portable Reputation and Vendor Lock-in

I’ve seen some mentions recently of ESPs suggesting that if you use your own domain in the From: of mail you send through an ESP then that ESP can’t “do email authentication” properly unless they require you to edit your domains DNS settings. That’s not really so, but there is a kernel of truth in there.
The real situation is, unsurprisingly, a bit more complicated.
What authentication features should you look for in an ESP?

Read More