UNIX System Administration Handbook - Evi Nemeth [265]
MX records
The mail system uses mail exchanger records to route mail more efficiently. An MX record preempts the destination of a message, in most cases directing it to a mail hub at the recipient’s site rather than the recipient’s own workstation.
See Chapter 19 for more information about email.
The format of an MX record is
name [ttl] IN MX preference host ...
Two examples are shown below, one for a host that receives its own mail unless it is down, and one for a host that can’t receive mail at all:
piper IN MX 10 piper
IN MX 20 mailhub
IN MX 50 boulder.colorado.edu.
xterm1 IN MX 10 mailhub
IN MX 20 anchor
IN MX 50 boulder.colorado.edu.
Hosts with low preference values are tried first: 0 is the most desirable, and 65,535 is as bad as it gets. In this example, mail addressed to bob@xterm1 would be sent to mailhub if it were accessible, to anchor as a second choice, and if both mailhub and anchor were down, to boulder. Note that boulder’s name must be fully qualified since it is not a member of the default domain (here, “cs.colorado.edu.”).
The list of preferences and hosts can all be on the same line, but separate lines are easier to read. Leave numeric “space” between preference values so you don’t have to renumber if you need to squeeze in a new destination.
MX records are useful in many situations:
• When you have a central mail hub
• When the destination host is down
• When the destination isn’t reachable from the Internet
• When the destination host doesn’t speak SMTP
• When the local sysadmin knows where mail should be sent better than your correspondents do
In the first of these situations, mail is routed to the mail hub, the machine where most users read mail. In the second case, mail is routed to a nearby host and forwarded when the destination comes back up.
Hosts that are not directly on the Internet can’t have A records, but they can have MX records. sendmail can’t connect directly to the destination, but it can get the mail closer by connecting to one of the destination’s MX hosts. The MX hosts presumably have a direct connection to the destination or know how to reach it (behind a firewall or with the UUCP protocol, perhaps).
The final reason to use MX records is that the local sysadmins probably know the mail architecture much better than your correspondents. They need to have the final say on how your site channels its mail stream.
Every host should have MX records.For minor hosts, one or two alternates is enough. A major host should have several records. For example, the following set of records might be appropriate for a site at which each host sends and receives its own mail:
• One for the host itself, as first choice
• A departmental mail hub as second choice
• A central mail hub for the domain or parent domain as a backup
The domain itself should have an MX record to a mail hub machine so that mail to user@domain will work. Of course, this configuration does require that user names be unique across all machines in the domain. For example, to be able to send mail to evi@cs.colorado.edu, we need a machine called cs, MX records in cs.colorado.edu, or perhaps both.
cs IN MX 10 mailhub.cs.colorado.edu.
IN MX 20 anchor.cs.colorado.edu.
IN MX 50 boulder.colorado.edu.
A machine that accepts mail for another host must list that other host in its sendmail configuration files; see page 578 for a discussion of sendmail’s use_cw_file feature and the file local-host-names.
Wild card MX records are also sometimes seen in the DNS database:
* IN MX 10 mailhub.cs.colorado.edu.
At first glance, this record seems like it would save lots of typing and add a default MX record for all hosts. But wild card records don’t quite work as you might expect. They match anything in the name field of a resource record that is not already listed as an explicit name in another resource record.
Thus, you cannot use a star