5.1 MX Records

DNS uses a single type of resource record to implement enhanced mail routing, the MX record. Originally, this functionality 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 Internet showed that separating the functionality 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 the 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 name server to cache just that record type. So mailers either had to do two queries, one for MD and one for MF data, or they could no longer accept cached answers. This meant that the overhead of running mail was higher than that of running other services, and 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 TTL s 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 it's addressed to, or gatewaying it to another mail transport, like UUCP . "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.com is a mail exchanger for peets.mpk.ca.us at preference value 10.

Taken together, the preference values of a host'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 host's other mail exchangers? Unless there are other records involved:

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 seems a little counterintuitive at first - 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.[1] The mailer should try all the mail exchangers at a given preference value before proceeding to the next higher value, though.

[1] The newest version of sendmail , version 8, will actually choose randomly among mail exchangers at the same preference.

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

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

Interpreted together, these MX records instruct mailers to attempt delivery to ora.com by sending to:

1. ora.ora.com first

2. Either ruby.ora.com or opal.ora.com next, and finally

3. The remaining preference 10 mail exchanger (the one not used in 2)

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

What if a host doesn't have any MX records? Will a mailer simply not deliver mail to that host? Actually, you can compile recent versions of sendmail to do just that. Most vendors, however, have compiled their sendmail s to be more forgiving: if no MX records exist, they'll at least attempt delivery to the host's address. sendmail version 8, 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 which variety your sendmail is.

Even though nearly all mailers will deliver mail to a host with just an address, and no MX records, it's still a good idea to have at least one MX record for each host. sendmail will request MX records for a host each time it needs to deliver mail. If the host doesn't have any MX records, a name server - usually one of your authoritative name servers - still ends up answering that query. If you simply add an MX record for the host pointing to itself, sendmail will have its first query answered, and the mailer's local name server will cache the MX record for future use.