DNS uses a single type of resource record to implement enhanced mail routing: the MX record. Originally, the MX record’s function was split between two records—the MD (mail destination) and MF (mail forwarder) records. MD specified the final destination to which a message addressed to a given domain name should be delivered. MF specified a host that would forward mail on to the eventual destination, should that destination be unreachable.

Early experience with DNS on the ARPAnet showed that separating the functions didn’t work very well. A mailer needed both the MD and MF records attached to a domain name (if both existed) to decide where to send mail; one or the other alone wouldn’t do. But an explicit lookup of one type or another (either MD or MF) would cause a nameserver to cache just that record type. So mailers either had to do two queries, one for MD and one for MF records, or they could no longer accept cached answers. This meant that the overhead of running mail was higher than that of running other services, which was eventually deemed unacceptable.

The two records were integrated into a single record type, MX, to solve this problem. Now a mailer just needed all the MX records for a particular domain name destination to make a mail-routing decision. Using cached MX records was fine, as long as the TTLs matched.

MX records specify a mail exchanger for a domain name: a host that will either process or forward mail for the domain name (through a firewall, for example). Processing the mail means either delivering it to the individual to whom it’s addressed or gatewaying it to another mail transport, such as X.400. Forwarding means sending it to its final destination or to another mail exchanger closer to the destination via SMTP, the Internet’s Simple Mail Transfer Protocol. Sometimes forwarding the mail involves queuing it for some amount of time, too.

In order to prevent mail-routing loops, the MX record has an extra parameter, besides the domain name of the mail exchanger: a preference value. The preference value is an unsigned 16-bit number (between 0 and 65535) that indicates the mail exchanger’s priority. For example, the MX record:

peets.mpk.ca.us.    IN    MX    10 relay.hp.com.

specifies that relay.hp.comis a mail exchanger for peets.mpk.ca.us at preference value 10.

Taken together, the preference values of a destination’s mail exchangers determine the order in which a mailer should use them. The preference value itself isn’t important, only its relationship to the values of other mail exchangers: is it higher or lower than the values of this destination’s other mail exchangers? Unless there are other records involved, this:

plange.puntacana.dr.  IN  MX  1 listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  2 hep.puntacana.dr.

does exactly the same thing as:

plange.puntacana.dr.  IN  MX  50  listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  100 hep.puntacana.dr.

Mailers should attempt delivery to the mail exchangers with the lowest preference values first. This may seem a little counterintuitive: the most preferred mail exchanger has the lowest preference value. But since the preference value is an unsigned quantity, this lets you specify a “best” mail exchanger at preference value 0.

If delivery to the most-preferred mail exchanger(s) fails, mailers should attempt delivery to less-preferred mail exchangers (those with higher preference values), in order of increasing preference value. That is, mailers should try more-preferred mail exchangers before they try less preferred mail exchangers. More than one mail exchanger may share the same preference value, too. This gives the mailer its choice of which to send to first. However, the mailer must try all the mail exchangers at a given preference value before proceeding to the next higher value.

For example, the MX records for oreilly.com might be:

oreilly.com.    IN    MX    0 ora.oreilly.com.
oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

Interpreted together, these MX records instruct mailers to attempt delivery to oreilly.com by sending in the following order:

Of course, once the mailer successfully delivers the mail to one of oreilly.com’s mail exchangers, it can stop. A mailer successfully delivering oreilly.com mail to ora.oreilly.comdoesn’t need to try ruby.oreilly.com or opal.oreilly.com.

Note that oreilly.com isn’t a particular host; it’s the domain name of O’Reilly’s main forward-mapping zone. O’Reilly uses the domain name as the email destination for everyone who works there. It’s much easier for correspondents to remember the single email destination oreilly.com than to remember which host—ruby.oreilly.com? amber.oreilly.com?—each employee has an email account on.

This requires, of course, that the administrator of the mailer on ora.oreilly.com maintain a file of aliases for all email users at O’Reilly, forwarding their mail to the hosts on which they read it, or run a server that offers users remote access to their mail stores, such as a POP or IMAP server. What if a destination doesn’t have any MX records, but has one or more A records? Will a mailer simply not deliver mail to that destination? Actually, you can compile recent versions of sendmail to do just that. Most vendors, however, have compiled their sendmails to be more forgiving: if no MX records exist but one or more A records do, they’ll at least attempt delivery to the address. Version 8 of sendmail, compiled “out of the box,” will try the address of a mail destination without MX records. Check your vendor’s documentation if you’re not sure whether your mail server will send mail to destinations with only address records.

Even though nearly all mailers will deliver mail to a destination with just an address record and no MX records, it’s still a good idea to have at least one MX record for each legitimate mail destination. Most mailers, including sendmail, will always look up the MX records for a destination first when there is mail to deliver. If the destination doesn’t have any MX records, a nameserver—usually one of your authoritative nameservers—still must answer that query, and then sendmail will go on to look up A records. That takes extra time, slows mail delivery, and adds a little load to your zone’s authoritative nameservers. If you simply add an MX record for each mail destination pointing to a domain name that maps to the same address an address lookup would return, the mailer sends only one query, and the mailer’s local nameserver caches the MX record for future use.

Finally, note that you can’t use an IP address instead of a domain name to identify the mail exchanger (in the field after the preference value). While some mailers are forgiving enough to accept an IP address, some aren’t, so your mail will fail unpredictably.

At movie.edu, we have a single mail hub, postmanrings2x.movie.edu . postmanrings2x runs both an SMTP server and an IMAP server with accounts for all movie.edu mail users.

To direct mail servers on the Internet to send mail addressed to users at movie.edu to our mail hub, we add this MX record to db.movie.edu:

movie.edu.  IN  MX  10 postmanrings2x.movie.edu.

Our ISP runs a backup SMTP server as a service for customers; it will queue mail for us if our mail server or our connection to the Internet fails. To tell Internet mailers to try it if postmanrings2x isn’t available, we add another MX record to the movie.edu zone datafile:

movie.edu.  IN  MX  20 smtp.isp.net.

The idea of a mail exchanger is probably new to many of you, so let’s go over it in a little more detail. A simple analogy should help here: imagine that a mail exchanger is an airport, and instead of setting up MX records to instruct mailers where to send messages, you’re advising your in-laws as to which airport to fly into when they come to visit you.

Say you live in Los Gatos, California. The closest airport for your in-laws to fly into is San Jose, the second closest is San Francisco, and the third Oakland. (We’ll ignore other factors such as price of the ticket, Bay Area traffic, etc.) Don’t see the parallel? Then picture it like this:

los-gatos.ca.us.    IN    MX    1 san-jose.ca.us.
los-gatos.ca.us.    IN    MX    2 san-francisco.ca.us.
los-gatos.ca.us.    IN    MX    3 oakland.ca.us.

The MX list is just an ordered list of destinations that tells mailers (your in-laws) where to send messages (fly) if they want to reach a given email destination (your house). The preference value tells them how desirable it is to use that destination; think of it as a logical “distance” from the eventual destination (in any units you choose), or simply as a “top 10"-style ranking of the proximity of those mail exchangers to the final destination.

With this list, you’re saying, “Try to fly into San Jose, and if you can’t get there, try San Francisco and Oakland, in that order.” It also says that if you reach San Francisco, you should take a commuter flight to San Jose. If you wind up in Oakland, you should try to get a commuter to San Jose or at least to San Francisco.

What makes a good mail exchanger, then? The same qualities that make a good airport:

Keep this example in mind because we’ll refer to it again later.

That’s the basic idea behind MX records and mail exchangers, but there are a few more wrinkles you should know about. To avoid routing loops, mailers need to use a slightly more complicated algorithm than what we’ve described when they determine where to send mail.^[*]

Imagine what would happen if mailers didn’t check for routing loops. Let’s say you send mail from your workstation to [email protected], raving (or raging) about the quality of this book. Unfortunately, ora.oreilly.comis down at the moment. No problem! Recall oreilly.com’s MX records:

oreilly.com.    IN    MX    0  ora.oreilly.com.
oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

Your mailer falls back and sends your message to ruby.oreilly.com, which is up. ruby.oreilly.com’s mailer then tries to forward the mail on to ora.reilly.com but can’t because ora.oreilly.comis down. Now what? Unless ruby.oreilly.com checks the sanity of what she is doing, she’ll try to forward the message to opal.oreilly.com or maybe even to herself. That’s certainly not going to help get the mail delivered. If ruby.oreilly.com sends the message to herself, we have a mail-routing loop. If ruby.oreilly.com sends the message to opal.oreilly.com, opal.oreilly.com will either send it back to ruby.oreilly.com or send it to herself, and we again have a mail-routing loop.

To prevent this from happening, mailers discard certain MX records before they decide where to send a message. A mailer sorts the list of MX records by preference value and looks in the list for the canonical domain name of the host on which it’s running. If the local host appears as a mail exchanger, the mailer discards that MX record and all MX records in which the preference value is equal or higher (that is, equally or less-preferred mail exchangers). That prevents the mailer from sending messages to itself or to mailers “farther” from the eventual destination.

Let’s think about this in the context of our airport analogy. This time, imagine you’re an airline passenger (a message) trying to get to Greeley, Colorado. You can’t get a direct flight to Greeley, but you can fly to either Fort Collins or Denver (the two next-highest mail exchangers). Since Fort Collins is closer to Greeley, you opt to fly to Fort Collins.

Now, once you’ve arrived in Fort Collins, there’s no sense in flying to Denver, away from your destination (a lower-preference mail exchanger). (And flying from Fort Collins to Fort Collins would be silly, too.) So the only acceptable flight to get you to your destination is now a Fort Collins-Greeley flight. You eliminate flights to less-preferred destinations to prevent frequent-flyer looping and wasteful travel time.

One caveat: most mailers will look only for their local host’s canonical domain name in the list of MX records. They don’t check for aliases (domain names on the left side of CNAME records). Unless you always use canonical names in your MX records, there’s no guarantee that a mailer will be able to find itself in the MX list, and you’ll run the risk of having your mail loop.

If you do list a mail exchanger by an alias, and it unwittingly tries to deliver mail to itself, most mailers will detect the loop and bounce the mail with an error. Here’s the error message from recent versions of sendmail:

554 MX list for movie.edu points back to relay.isp.com
554 <[email protected]>... Local configuration error

This replaces the quainter “I refuse to talk to myself” error older versions of sendmail emitted. The moral: in an MX record, always use the mail exchanger’s canonical name.

One more caveat: the hosts you list as mail exchangers must have address records. A mailer needs to find an address for each mail exchanger you name or else it can’t attempt delivery there.

To go back to our oreilly.com example, when ruby.oreilly.com received the message from your workstation, her mailer would have checked the list of MX records:

oreilly.com.    IN    MX    0  ora.oreilly.com.
oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

Finding the local host’s domain name in the list at preference value 10, ruby.oreilly.com’s mailer discards all the records at preference value 10 or higher (the records in bold):

oreilly.com.    IN    MX    0 ora.oreilly.com.oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

leaving only:

oreilly.com.    IN    MX    0 ora.oreilly.com.

Since ora.oreilly.comis down, ruby.oreilly.com defers delivery until later and queues the message.

What happens if a mailer finds itself at the highest preference (lowest preference value) and has to discard the whole MX list? Some mailers attempt delivery directly to the destination host’s IP address as a last-ditch effort. In most mailers, however, it’s an error. It may indicate that DNS thinks the mailer should be processing (not just forwarding) mail for the destination, but the mailer hasn’t been configured to know that. Or it may indicate that the administrator has ordered the MX records incorrectly by using the wrong preference values.

Say, for example, the folks who run acme.com add an MX record to direct mail addressed to acme.com to a mailer at their Internet service provider:

acme.com.    IN    MX    10 mail.isp.net.

Most mailers need to be configured to identify their aliases and the names of other hosts for which they process mail. Unless the mailer on mail.isp.net is configured to recognize email addressed to acme.com as local mail, it assumes it’s being asked to relay the mail and attempts to forward the mail to a mail exchanger closer to the final destination.^[*] When it looks up the MX records for acme.com, it finds itself as the most-preferred mail exchanger and bounces the mail back to the sender with the familiar error:

554 MX list for acme.com points back to mail.isp.net
554 <[email protected]>... Local configuration error

Many versions of sendmail use class w or fileclass w as the list of local destinations. Depending on your sendmail.cf file, adding an alias can be as easy as adding the line:

Cw acme.com

to sendmail.cf.

You may have noticed that we tend to use multiples of 10 for our preference values. Ten is convenient because it allows you to insert other MX records temporarily at intermediate values without changing the other weights, but otherwise there’s nothing magical about it. We could just as easily have used increments of 1 or 100; the effect would have been the same.

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.

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

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

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

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