Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  Name Systems and TCP/IP Name Registration and Name Resolution            9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)                 9  TCP/IP Domain Name System (DNS)                      9  DNS Name Servers and Name Resolution                           9  DNS Resolution Concepts and Resolver Operations

DNS Reverse Name Resolution Using the IN-ADDR.ARPA Domain 1 2 DNS Messaging and Message, Resource Record and Master File Formats

The Mail Exchange (MX) Record and Its Use

To allow the flexibility needed for these situations, a special DNS resource record type is defined called a mail exchange (MX) record. Each MX record specifies a particular mail server that is to be used to handle incoming e-mail for a particular domain. Once this record is established, resolution of electronic mail messages is pretty much similar to how it works for regular resolution. Suppose we want to send an e-mail to “joe@xyzindustries.com”. The process, roughly, is as follows:

1. Our e-mail client invokes the resolver on our local machine to perform an e-mail resolution on “xyzindustries.com”.
   
   
2. Our local resolver and local DNS server follow the process described in the topic on DNS name resolution to find the authoritative server for “xyzindustries.com”, which is “ns1.xyzindustries.com”.
   
   
3. “ns1.xyzindustries.com” finds the MX record for “xyzindustries.com” and replies back indicating that “mail.xyzindustries.com” should be used for e-mail.

Of course, the e-mail client can't actually send anything to “mail.xyzindustries.com”; it needs its IP address. So, it would then have to resolve that name. Of course, this resolution request will likely end up right back at the same DNS name server that just handled the MX request. To eliminate the inefficiency of two separate resolutions, the DNS name server can combine the information. In our example above, “ns1.xyzindustries.com” will include the A (Address) resource record for “mail.xyzindustries.com” in the Additional section of the DNS message that it sends in step 3 above.

It is also possible to specify multiple MX records for a particular domain, each pointing to a different mail server's name. This provides redundancy, so if there is a problem with one mail server, another can pick up the slack. DNS allows each mail server to be specified with a preference value, so you can clearly indicate which is the main mail server, which is the first backup, the second backup, and so on. The DNS server will choose the mail server with the lowest preference value first, then the next highest one, and so on.

Note that RFC 1035 originally defined several other resource record types related to electronic mail as well: the mailbox (MB), mail group (MG) and mail rename (MR) resource records. These are called “experimental” in the standard. I think the experiment failed, whatever it was, because I don't believe these are used today. There are also two even older mail-related resource records, mail destination (MD) and mail forwarder (MF), which must have been used at one time but were already obsolete at the time RFC 1035 itself was written.

DNS Reverse Name Resolution Using the IN-ADDR.ARPA Domain 1 2 DNS Messaging and Message, Resource Record and Master File Formats