• What is an MX record?
• Is an MX record the same as the server I download my mail from?
• What is the proper format for an MX record?
• Are there other considerations?
• Why is the proper format so important?
• Can I have an MX record for a host that points to itself?

What is an MX record?
When a remote site on the internet wants to send someone at your domain an e-mail message, their mail server software uses the global DNS system to look up the hostname of the appropriate mail server to receive that mail. This type of record is referred to as an "MX," "Mail Exchanger" or "Mail Relay" record. The response that the remote server gets tells it where to send the mail so that it will be relayed to you.

Is an MX record the same as the server I download my mail from?
When your site has received e-mail it is stored for you by your e-mail server. In order to retrieve your mail from the server you need to use an interface between your mail program (like Eudora or Thunderbird) and the mail server itself. This interface is usually a piece of software like POP (the Post Office Protocol) or IMAP. The hostname that you use to access the POP or IMAP server might be the same as your MX record, or it might be different. The MX record's only job is to tell other sites where mail for you should be sent. You retrieving your mail is a completely separate operation from the standpoint of the DNS.

What is the proper format for an MX record?
The documents commonly referred to as "RFC's" (Request For Comment) define the standards for all things related to the internet, including the global DNS system. A very handy reference to these documents can be found at The RFC Editor.

• From Page 16, Section 3.3.9 of RFC 1035
  PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred.

  EXCHANGE A <domain-name> which specifies a host willing to act as a mail exchange for the owner name.

  MX records cause type A additional section processing for the host specified by EXCHANGE. The use of MX RRs is explained in detail in [RFC-974].

• From Page 1 of RFC 974
  The domain servers store information as a series of resource records (RRs), each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of a RR is as a typed pair of datum, a domain name matched with relevant data, and stored with some additional type information to help systems determine when the RR is relevant. For the purposes of message routing, the system stores RRs known as MX RRs. Each MX matches a domain name with two pieces of data, a preference value (an unsigned 16-bit integer), and the name of a host. The preference number is used to indicate in what order the mailer should attempt deliver to the MX hosts, with the lowest numbered MX being the one to try first. Multiple MXs with the same preference are permitted and have the same priority.
• From Page 5 of RFC 974
  Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs.
• From Page 11, Section 10.3 of RFC 2181 (Standards Track)
  The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

  Searching for either NS or MX records causes "additional section processing" in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made.

  Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query.

• From Page 6 of RFC 1912 (Informational)
  Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged:

  podunk.xx. IN MX mailhost
  mailhost IN CNAME mary
  mary IN A 1.2.3.4

  [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer.

Taken together, these definitions describe a format that includes a preference value which tells remote servers what order in which to try the mail relay servers for your domain, and the hostname of the mail server itself. You may have more than one MX record for a given hostname, and you may have more than one at the same preference level.

It is extremely important that the hostname for the mail server not be a CNAME record, for the reasons described above in the reference from RFC 2181. The point that excerpt is making is that there are some sites (perhaps many sites) that will not be able to send you mail if your MX records point to CNAME's. Additionally, even if it does happen to work, you are causing additional (and unnecessary) DNS traffic by configuring records in this manner.

Are there other considerations?
Current best practices have a few additional things to be aware of when configuring MX records. While one machine may have more than one hostname and/or IP address that it answers to, the MX record should point to the hostname that the mail server software knows itself as. This is a configuration option for the mail software, and is usually the same name as the name of the machine itself. Also, many sites are installing software that prevents their site from being used by unauthorized persons to send e-mail. One of the tests that software uses to determine if a remote site is "legitimate" or not is to first look up the IP address for the hostname of the mail server, then look up the hostname using that IP address and see if they match. If they do not match, many sites will refuse to send the mail.

From Page 6, Section 2.4 of RFC 1912

[The use of] chained records such as CNAME's pointing to CNAME's may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names.

Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.

Why is the proper format so important?
There are two parts to this answer, the most obvious one having already been addressed, namely that without the proper format the chances of your mail being delivered properly go down. As the abuse prevention systems that check for proper format become more and more common your chances for having the mail delivered properly go down even more. The other part of this answer is less obvious however. If you have improperly formatted MX records and remote sites are not able to send you mail, chances are you will never know. There are many sites that simply discard undeliverable mail and never attempt to find an alternate contact address to let you know that your e-mail is not being delivered.

Can I have an MX record for a host that points to itself?
The simple answer to this question is yes. While the default for attempting mail delivery for a host with no MX records is to try delivering to the host itself, there is nothing wrong with adding an explicit MX record for the host, and in fact adding this record will help some less-compliant MTA's get the mail to the right place.