MX record
From Wikipedia, the free encyclopedia
 |
It has been suggested that Nolisting be merged into this article or section. (Discuss) |
An MX record or Mail exchanger record is a type of resource record in the Domain Name System (DNS) specifying how Internet e-mail should be routed using the Simple Mail Transfer Protocol (SMTP). Each MX record contains a priority and a host name, so that the collection of MX records for a given domain name point to the servers that should receive e-mail for that domain, and their priority relative to each other.
Contents |
[edit] Overview
The host name contained in an MX record must have an address, i.e. an A or AAAA DNS record. CNAME aliases are prohibited in an MX record data, while CNAME is allowed for the MX record label, that is for the domain name leading to the MX record itself. [1].
When an e-mail message is sent through the Internet, the sending mail transfer agent makes a DNS query requesting the MX records for each recipient's domain name, which is the portion of the e-mail address following the "@". This query returns a list of host names of mail exchange servers accepting incoming mail for that domain, together with a preference number. The sending agent then attempts to establish an SMTP connection to one of these servers, starting with the one with the smallest preference number, delivering the message to the first server with which a connection can be made. If no MX records were present, the server falls back to A, that is to say, it makes a request for the A record of the same domain.
The MX mechanism provides the ability to run multiple mail servers for a single domain, specifying the order in which they should be tried, increasing the likelihood that mail may be delivered and providing the ability to distribute the processing of incoming mail across multiple physical servers. This ability to run multiple mail servers easily is proving very valuable for high-availability clusters of inexpensive mail gateways that can then process hundreds of messages per second in aggregate to quarantine or remove spam and/or viruses. However, not all versions of all mail transfer agents pay attention to lower priority MX records — in other words, if the highest-priority MX server fails, the MTA doesn't address the backup server [1].
The MX mechanism does not grant the ability to provide mail service on alternative ports, nor does it provide the ability to distribute mail delivery across a set of equal-priority mail servers by assigning a weighting value to each one.
[edit] MX priority
The target server, i.e. the one that knows how to deliver to the relevant user's e-mail mailbox is the one with the highest priority. Low priority servers, a.k.a. backup mx, usually keep the messages in a queue waiting for the primary server to become available.
The relative priority of an MX server is determined by the preference number present in the DNS MX record. When a remote client (typically another mail server) does an MX lookup for the domain name, it gets a list of servers and their preference numbers. The MX record with the smallest preference number has the highest priority and is the first server to be tried. The remote client will go up the list of servers until it successfully delivers the message or gets permanently rejected due to an unreachable server or if the mail account does not exist on that server. If there is more than one entry with the same preference number, all of those must be tried before moving on to lower-priority entries.
One technique used to distribute the load of incoming mail over an array of servers is to return the same preference number for each server in the set. The available mail servers are then returned in a sort of round robin order, and since the priority values of all returned MXs are equal, the remote client will send its message using the first in the list. Upon the next request, the MXs will be returned in a "shuffled" order. This technique mainly addresses routing problems; other type of server load can be addressed by using an SMTP proxy.
A favorite technique of spammers is to connect to the lowest priority MXs for a domain (those with the largest numerical value) in an attempt to avoid any anti-spam filters that may be running on the primary (highest priority) MX. In addition, backup MX servers may not know the names of user's mailboxes. The reasoning is that SMTP engines running on compromised hosts do not fully implement all SMTP error-handling routines, and this lack of complete rule-following can be used against them (grey-listing being another example of an anti-spam technique).
[edit] History of fallback to A
RFC 821 came out in 1982. It makes only passing references to DNS, because at the time the transition from HOSTS.TXT to the DNS had not yet started. RFC 883, the first description of the DNS, came out over a year later in late 1983. It described the experimental and little used MD and MF records. According to RFC 897 and RFC 921, the transition to DNS started in 1983, but HOSTS.TXT wasn't scheduled to go away until the end of 1985 and wasn't totally phased out until the late 1980s.
In January 1986, RFC 973 and RFC 974 deprecated the MD and MF records, replaced them with MX, and defined the MX lookup with fallback to A. RFC 974 recommends that clients do a WKS lookup on each MX host to see if it actually supports SMTP and discard the MX entry if it doesn't. However, RFC 1123 changed this to say that WKS "SHOULD NOT" be checked.
This means that SMTP had been in use for at least a year using HOSTS.TXT, and then another couple of years using A, MD, and MF, before MX came along. MD and MF were hard to use, so most people just used the A record. Under the circumstances, MX without fallback to A wouldn't have worked because of the substantial installed base of mail servers using A records. The early use of MX was to identify gateways to other networks, but it didn't come into wide use until the DNS was well established in the early 1990s.[2]
[edit] See also
- SRV record - a similar DNS record for advertising other network services
- Sender Policy Framework - some what of a reverse MX record, saying where mail gets sent from, rather than sent to.
- List of DNS record types
Spam related MX systems:
[edit] References
- ^ The prohibition on labels in the data that resolve to CNAMEs is discussed in RFC 2181, Section 10.3; its rationale is to allow a backup MX to recognize itself by name, thereby simplifying the algorithm used to determine the target host. See also RFC 1034
- ^ This section is adapted from John Levine ietf-smtp message
