5.5. DNS and Email Authentication

In addition to using MX records stored in DNS to determine where to send mail, some modern mail servers can now use other data in DNS to authenticate a message's sender. In particular, several recently proposed email authentication mechanisms use resource records to store critical information. While a complete description of any of these proposals is beyond the scope of this book, we'd like to introduce you to the most widely deployed of them, with a particular emphasis on how it uses DNS.

5.5.1. The Sender Policy Framework

We'll cover SPF, the Sender Policy Framework, both because it's the most widely deployed of these authentication mechanisms and because it's fairly simple to describe. SPF allows a company's postmastermaybe with the cooperation of his friendly DNS administratorto specify which mail servers are allowed to send email addressed from the organization's domain names. It's a little like the opposite function of the MX record: an MX record tells a mailer to send mail addressed to a particular domain name to particular mail servers, while SPF information tells a mailer which mail servers can send mail addressed from a particular domain name.^[*]

^[*] In fact, SPF is descended from a proposal called "Reverse MX," by Hadmut Danisch.

Here's a simple example: Say O'Reilly Media's postmaster knows that all legitimate oreilly.com email is sent from one of two SMTP servers, smtp1.oreilly.com and smtp2.oreilly.com. He can advertise this fact in DNS by adding a TXT record to the domain name oreilly.com (or by asking whomever administers the oreilly.com zone to do it for him). Here's one possible TXT record that accomplishes this:

oreilly.com.  IN  TXT  "v=spf1 +a:smtp1.oreilly.com +a:smtp2.oreilly.com -all"

The tag v=spf1 at the beginning of the record-specific data identifies this TXT record as an SPF record. This is needed because TXT records can be used for many purposes, including human-readable comments, and you wouldn't want Internet mail servers trying to interpret your comments as SPF instructions. If SPF takes off, it will eventually receive its own, dedicated record type, SPF, and the tag will become unnecessary.

The next two fields specify that mail addressed from oreilly.com can come from any of the IP addresses of the hosts smtp1.oreilly.com or smtp2.oreilly.com. The leading plus signs are qualifiers, and indicate that email from these hosts' IP addresses should be allowed. There are four possible qualifiers:

+

Pass. A mailer that matches is a valid sender.

-

Fail. A mailer that matches is not a valid sender.

~

SoftFail. A mailer that matches probably isn't a valid sender, so the message should be carefully scrutinized.

?

Neutral. Has no effect.

The default is + (pass), so the plus signs could have been omitted. The final field, -all, tells mailers to deny (fail) every other sender of oreilly.com email.

There are other ways to specify a domain name's valid senders. Since oreilly.com's two MX records list smtp1.oreilly.com and smtp2.oreilly.com, the postmaster can instead add this shorter TXT record:

oreilly.com.  IN  TXT  "v=spf1 +mx -all"

Without a colon and a domain name argument, "mechanisms" such as a and mx use the domain name in the owner field. Just plain +mx, then, is the same as +mx:oreilly.com in this record.

Here's a list of common mechanisms used in SPF TXT records:

a

Specifies the domain name of a mail server whose address or addresses are allowed to send email from the owner domain name.

mx

Specifies a domain name whose mail exchangers are allowed to send email from the owner domain name.

ip4

Specifies the IP(v4) address of a mail server that is allowed to send email from the owner domain name. Can also specify a network in CIDR notation (e.g., 192.168.0.0/24). Note that all four octets of the network must be specified.

ip6

Specifies the IPv6 address of a mail server that is allowed to send email from the owner domain name. Can also specify an IPv6 network in RFC 3513 notation.

ptr

Requires that a PTR record exist for the sending mail server's address. The PTR record must map the address to a domain name that ends in the domain name in the owner field of the TXT record or the argument specified after the colon. For example, +ptr:oreilly.com requires that a sending mail server's address reverse-map to a domain name ending in oreilly.com.

SPF records also support a redirect modifier, which allows multiple domain names to share a common set of SPF instructions. For example, say the administrator of oreilly.com wants the ca.oreilly.com and ma.oreilly.com domain names to use the same rules he's established for oreilly.com. Rather than duplicate oreilly.com's TXT record, he can add these TXT records:

ca.oreilly.com.  IN  TXT  "v=spf1 redirect=oreilly.com"
ma.oreilly.com.  IN  TXT  "v=spf1 redirect=oreilly.com"

These tell mailers to refer to the SPF records for oreilly.com when determining which are valid mailers for ca.oreilly.com and ma.oreilly.com. Now if the administrator needs to modify his SPF instructions, he must only change one TXT record.

The include mechanism is a similar construct, designed to let administrators refer to SPF instructions configured by someone else. For example, if the oreilly.com administrator also wants to allow any legitimate senders of isp.net email to send oreilly.com email, he can amend the oreilly.com TXT record to read:

oreilly.com.  IN  TXT  "v=spf1 +mx include:isp.net -all"

Note that the separator between include and its argument is a colon, while the separator between redirect and its argument is an equals sign.

A couple of miscellaneous hints: It's a good idea to use ?all or ~all in your SPF records in the beginning because it can be surprisingly difficult to enumerate all the valid sources of your domain name's email. You may have remote employees running their own mail servers, mobile workers sending email from PDAs with company email addresses, and many others. You don't want to inadvertently cut them off.

If your SPF records are very long and complex, they may exceed the maximum length of a TXT record's data, 255 bytes. In that case, you can break the record into multiple TXT records, each beginning with the v=spf1 tag. They'll be concatenated before evaluation.

Two final notes of caution: Remember that, even if you publish SPF information, only mail servers with SPF support will look it up and use it. Right now, that's a very small proportion of the Internet's mailers. (Still, there's no harm in publishing SPF records, so why not?) And be aware that SPF may change, may never become a standard, and may be superseded by other mechanisms.