|
 |
 |
 |
 |
MX Record FAQ
Copyright © 2002-2009 by Doug Barton, dougb - at - dougbarton -dot- us
All rights reserved.
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 Outlook 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 IETF RFC web site.
- 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.
$Id: MX.html,v 1.6 2009/08/24 06:11:56 dougb Exp $
|
 |
|
 |
 |
 |
|
