Chapter 4. Electronic Mail
Introduction
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.
Configuring a Backup Mail Server in DNS
Solution
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.
To add smtp.isp.net as a backup mail server for foo.example, add another MX record to foo.example pointing to that mail server, with a preference value higher than 10. For example:
foo.example. IN MX 20 smtp.isp.net.
Discussion
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.
See Also
Section 2.5 for instructions on setting up a mail destination and “MX Records” in Chapter 5 of DNS and BIND.
Configuring Multiple Mail Servers in DNS
Problem
You want to configure DNS so that mail addressed to a destination will be sent to one of a number of equivalent mail servers.
Solution
Add MX records for the domain name of the mail destination, pointing to the domain names of the mail servers, all at the same -- and lowest -- preference value. 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.
Discussion
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.
See Also
Section 2.5 for instructions on setting up a mail destination and Section 4.2 for designating backup mail servers for a destination, as well as “MX Records” in Chapter 5 of DNS and BIND.
Configuring Mail to Go to One Server and the Web to Another
Problem
You want mail addressed to a particular domain name to be routed to one mail server, while users specifying that domain name in a URL reach a web server on a different host.
Solution
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
Discussion
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.
See Also
Recipes Section 2.5 and Section 2.6.
Configuring DNS for “Virtual” Email Addresses
Solution
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 user@bar.example to mail.foo.example, you could add this MX record to the bar.example zone:
bar.example. IN MX 10 mail.foo.example.
Discussion
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.
See Also
Configuring DNS So a Mail Server and the Email It Sends Pass Anti-Spam Tests
Problem
You want to make sure a mail server and the email it sends pass all DNS-related anti-spam tests.
Solution
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 user@foo.example, 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):
2.0.168.192.in-addr.arpa. IN PTR mail.foo.example.
Check that the domain name that the mail server’s address maps to in turn maps back to that address (that is, the domain name has an A record with the same address on the right side):
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.
Discussion
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.
See Also
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.
Get DNS & BIND Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
