Email Routing

Let's consider for a moment one way that email routing might work. A user horatio in the domain example.com has a workstation named denmark. He could receive mail by using the email address horatio@denmark.example.com. An MTA with a message to deliver would simply look up the IP address for denmark.example.com and deliver it to that system for the user horatio. This scenario requires that Horatio's workstation is always turned on, that it has a functional MTA running at all times to receive messages, and that it is accessible by unknown MTAs from anywhere on the Internet. Rather than manage hundreds or thousands of MTAs on workstations and expose them to the Internet, nearly all sites make use of mail hubs that receive all the mail for a domain. MTAs such as Postfix need a way to determine which host or hosts are the mail hubs for a domain. DNS MX records provide this information.

A mail exchanger either delivers mail it receives or forwards it to another mail system. A domain may have multiple mail systems for reliability, and therefore multiple MX records. Generally, one host is the primary mail server and the others serve as backup or secondary mail servers. Each MX record in DNS contains a preference value that orders mail systems from most preferred to least preferred.

BIND is one of the most common DNS server applications. (O'Reilly's DNS and BIND by Paul Albitz and Cricket Liu fully explains the DNS system and documents the BIND software.) A simple BIND configuration file for the domain example.com looks like the following:

example.com. IN SOA ns.example.com. kdent.example.com. ( 1049310513 10800 3600 604800 900 ) ; ; Nameservers ; example.com. IN NS ns.example.com. ; ; Host Addresses ; example.com. IN A 192.168.100.50 server1.example.com. IN A 192.168.100.220 ns.example.com. IN A 192.168.100.5 mail1.example.com. IN A 192.168.100.50 mail2.example.com. IN A 192.168.100.54 mail3.example.com. IN A 192.168.100.123 ; ; Mail Exchangers ; example.com. IN MX 10 mail1.example.com. example.com. IN MX 20 mail2.example.com. example.com. IN MX 30 mail3.example.com. ; ; CNAME Records ; pop.example.com. IN CNAME mail1.example.com. www.example.com. IN CNAME server1.example.com.

For this discussion, we're primarily interested in the mail exchanger records:

example.com. IN MX 10 mail1.example.com. example.com. IN MX 20 mail2.example.com. example.com. IN MX 30 mail3.example.com.

The domain name is in the first column. The second column indicates that the entries are Internet class records, and the third indicates that they are mail exchanger resource records. The last column shows the mail exchanger host, and the second-to-last column shows its preference value. Preference values can be any number between 0 and 65,536, and a lower value indicates a more preferred host. The numbers are meaningful only in relation to each other and can be anything within the allowed range. By convention, most administrators create priority values in multiples of 10, which allows some flexibility for inserting or temporarily rearranging preferences.

In our simple example above, mail1.example.com receives all the mail for the domain example.com. In this case, all mail must eventually arrive at mail1.example.com. When an MTA has to deliver a message to a user at the domain example.com, it retrieves all of the MX records and sorts them in order of priority. It first attempts delivery to mail1.example.com. If mail1.example.com is available and accepts the message, the delivery is finished; however, if for some reason mail1.example.com is not available to accept the message, the MTA continues down the list until it finds a mail exchanger able to accept the message. If a secondary mail exchanger accepts a message, it takes the responsibility of delivering it to a more preferred mail server (possibly the primary) when the unavailable server comes back online.

If no MX records are found for a domain, an MTA checks to see if there is an A record associated with the domain name itself. If there is an A record, the MTA attempts delivery to the system at that IP address.

This mail-routing scheme seems simple enough, but it does get slightly more complicated. Consider an example where the MTA on mail2.example.com receives a message for ophelia@example.com. Presumably, mail1.example.com is offline, since mail2 received the message. The MTA running on mail2.example.com gets the list of mail exchangers for example.com, determines that the message should go to mail1.example.com, and discovers that mail1 is not available. The next mail exchanger on the list is itself. Delivery to itself doesn't really make sense. So, the next mail exchanger in line is mail3.example.com. The MTA could deliver the message there, but mail3 will go through the same process and immediately try to hand the message back to mail2, creating a mail loop. (MTAs actually resolve hostnames to IP addresses for comparisons, since MX hosts might have multiple A records. Postfix compares the IP address to its list of addresses in inet_interfaces and proxy_interfaces.)

The solution is that when an MTA gets the list of mail exchangers and discovers itself among them, it discards its own record plus all other mail exchangers with an equal or less preferred priority (higher number). For our example, the host mail2 eliminates itself and mail3, thus reducing the list of mail exchangers to only mail1. Since mail1 is not available and mail2 has no other options for delivery, it queues the message and makes the delivery when mail1 comes back online.

In order for mail routing to work successfully, you should be very careful when setting up MX records. In particular, you should observe the following rules for MX records in your DNS configuration:

Mail exchangers must have valid A records.

The mail exchanger pointed to by the MX record must be a hostname with a valid A record. Once an MTA has determined which host should receive the mail, it has to be able to find that host.

Mail exchangers cannot be aliases.

The host pointed to by an MX record should not be an alias (CNAME record). Under normal circumstances, an MTA knows itself by its canonical name and looks for that name when checking the list of mail exchangers to prevent mail loops. The server must be able to find itself, so make sure that you list the canonical name in the MX record, or you risk creating a mail loop. Even if an MTA accommodates CNAME records (by looking up and using the canonical name), using them causes inefficiencies in mail delivery.

Use hostnames and not IP addresses for mail exchangers.

List a hostname rather than an IP address for mail exchangers. While you may get by with a bare IP address, RFC 974 states that you must use a name of a host. Future changes (IPv6, for example) might cause bare IP addresses to break mail routing.

Make sure that you specify preference values.

Leaving out the preference value for MX records may have different effects, depending on your DNS server and MTA. At best, the problem creates ambiguity; at worst, it can prevent mail delivery.