Remember when you were little, and it was a thrill to get mail, any mail at all? Postcards from relatives on vacation, greeting cards, the odd misdirected credit card offer -- it didn’t matter. I’ll bet that if you think back far enough, you can remember a time when it was exciting to get Internet email, too.
Now, of course, most Internet email is spam, but we can dream of a simpler time, before the Nigerian email scam and ordering Viagra on the Internet.
One of the linchpins of getting all of that email into your inbox is DNS. Mail transport agents all over the Internet look up MX records attached to your domain names to determine where to deliver your mail. I showed you the basic syntax of the MX record back in Recipe Section 2.5, but you also can craft those MX records to designate backup mail servers (Section 4.2), multiple, equivalent mail servers (Recipe Section 4.3), and more. This chapter will show you how.
Add an MX record for the mail destination, listing the domain name of the backup mail server at a higher preference value (and therefore lower preference) than the main mail server. For example, say the MX record for the mail destination foo.example, currently looks like this:
foo.example. IN MX 10 mail.foo.example.
foo.example. IN MX 20 smtp.isp.net.
By default, most modern mail software won’t accept mail addressed to just any old domain name. You may need to configure the backup mail server to accept mail addressed to the mail destination. But don’t configure the mail destination as local to the mail server; the backup mail server should accept the mail but queue it for later delivery to your main mail server.
Section 2.5 for instructions on setting up a mail destination and “MX Records” in Chapter 5 of DNS and BIND.
foo.example. IN MX 10 smtp1.foo.example. foo.example. IN MX 10 smtp2.foo.example. foo.example. IN MX 10 smtp3.foo.example.
Most modern mail servers that have mail to send to a destination will choose randomly among mail servers with the same preference value. All of these mail servers are the “final destination” for the mail, as far as DNS is concerned, so all should be configured to see the mail destination as local.
If one of the mail servers fails, a mail server trying to send mail to the destination will simply try another of the mail servers.
Using multiple “main” mail servers doesn’t preclude your listing one or more backup mail servers, too. Just add MX records pointing to the destination’s backup mail servers, with higher preference values than the value you used for the main mail servers. For example:
foo.example. IN MX 10 smtp1.foo.example. foo.example. IN MX 10 smtp2.foo.example. foo.example. IN MX 10 smtp3.foo.example. foo.example. IN MX 20 backup.isp.net.
Mail servers sending mail to the destination will only try the backup mail server if they fail to deliver the mail to all more-preferred mail servers.
Since mail servers sending mail to a particular domain name mail destination preferentially use MX records for that domain name, add an MX record to that domain name pointing to the mail server. Web browsers, on the other hand, only look up A records, so attach an A record to the domain name pointing to the address of the web server. For example:
foo.example. IN MX 10 mail.foo.example. foo.example. IN A 192.168.0.100
This is less a recipe than a reminder that a single domain name can serve multiple purposes: it can represent a mail destination when it appears on the right side of an email address. It can represent a web site when it appears in a URL. Since some of these services look up different types of records, you simply attach multiple record types to a single domain name to accommodate them.
Add an MX record to the appropriate zone with the domain name of the mail destination as the owner name and the domain name of the mail server for that destination on the right side. For example, to route mail addressed to firstname.lastname@example.org to mail.foo.example, you could add this MX record to the bar.example zone:
bar.example. IN MX 10 mail.foo.example.
There’s really nothing virtual about the mail destination bar.example from a DNS perspective -- hence the quotation marks. bar.example is a legitimate domain name in a real zone that happens to own an MX record, so it’s usable as a mail destination.
Note that the MX record must be added to the correct zone. If you want to direct mail addressed to bar.example to a particular mail server, you must add the MX record to the bar.example zone data file. It won’t do anyone any good in the foo.example zone data file: it’ll be ignored as out-of-zone data.
mail.foo.example will probably need to be configured to understand that bar.example is a local mail destination. Then it’s up to the mail server on mail.foo.example to decide what to do with mail addressed to individual users at bar.example. This might be handled by an aliases file or a virtual user table.
First, make sure that any domain names used in return addresses resolve to an MX record or an A record. For example, if the mail server sends out all mail addressed from email@example.com, make sure foo.example owns at least an MX record:
foo.example. IN MX 10 mail.foo.example.
Next, make sure that the IP address that the mail server sends mail from reverse-maps to a domain name (that is, that the domain name in in-addr.arpa that corresponds to the address has a PTR record attached):
18.104.22.168.in-addr.arpa. IN PTR mail.foo.example.
mail.foo.example. IN A 192.168.0.2
Finally, check that the domain name your mail software uses in the HELO or EHLO (extended HELLO) SMTP commands is either the same as the domain name you just checked (mail.foo.example), or else passes the same forward- and reverse-mapping checks. For example, if your mail server announces itself as smtp.foo.example, make sure smtp.foo.example maps to an address, and that address maps back to smtp.foo.example.
Not all mail software performs all of these checks when receiving email, but ensuring that a mail server passes them will help guarantee that the mail it sends won’t be refused as spam by the stricter mail servers on the Internet.
Len Conrad’s article “How to Keep Your DNS from Blocking Mail Delivery from your and your Clients’ Mail Servers” on his “BIND 8 for NT” web site, at http://bind8nt.meiway.com/itsaDNSmess.cfm.