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. MX records point to the servers that should receive an e-mail, and their priority relative to each other.
Contents |
Overview
An MX record should contain a host name defined by an A record. CNAME aliases are strongly discouraged as MX record host names[1]. When an e-mail message is sent through the Internet, the sending mail transfer agent makes a DNS query requesting the MX record for the 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, a second request is made for the A record of the domain instead. The MX mechanism provides the ability to run multiple mail servers for a single domain and 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 [2]. 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. As of 2004, some mail transfer agents support the use of SRV records for publishing the IP addresses, ports, priority, and weights of mail servers.
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, which usually are defined on the primary server only. When a secondary MX accepts a message that will eventually be rejected by the primary server, backscatter is generated. For that reason, many network administrators recommend to avoid using backup MXes, a legacy technique that was needed when internet connections were unreliable and that should be considered harmful nowadays.
MX Record and spam
When an MX-lookup fails, RFC rules call for fallback to the domain's A record. For situations where a domain's A record and MX record both point to the same machine or IP address, it is usually the case that the MX record can safely be deleted. This usually results in no missing valid or "legit" e-mail, but a drop in spam should be noted. The reason being is that because of the theories that SMTP engines running on comprimised hosts do not fully impliment 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).
See also
- LOC record
- SRV record
- Sender Policy Framework
- Email hub: MX based load-balancing and simple failover.
