Editing MX record (section)

==MX preference, distance, and priority==
According to RFC 5321, the lowest-numbered records are the most preferred.<ref name="RFC5321">RFC 5321</ref> This phrasing can be confusing, and so the ''preference number'' is sometimes referred to as the ''distance'': smaller distances are more preferable. An older RFC, RFC 974, indicates that when the preference numbers are the same for two servers, they have the same ''priority'', hence those two terms are used interchangeably.

The preference number is an unsigned<ref name="RFC974">RFC 974</ref> 16-bit<ref name="RFC974">RFC 974</ref><ref>RFC 1035 section 3.3.9</ref> field, thus valid values range from 0 to 65535.

===The basics===
In the simplest case, a domain may have just one mail server. For example, if an MTA looks up the MX records for example.com, and the DNS server replied with only mail.example.com with a preference number of 50, then the MTA will attempt delivery of the mail to the server listed. In this case, the number 50 could have been any integer permitted by the SMTP specification.

When more than one server is returned for an MX query, the server with the smallest preference number must be tried first.  If there is more than one MX record with the same preference number, all of those must be tried before moving on to lower-priority entries. An SMTP client ''must'' be able to try (and retry) each of the relevant addresses in the list in order, until a delivery attempt succeeds.<ref name="RFC5321">RFC 5321</ref>

===Load distribution===
The standard approach to distributing a load of incoming mail over an array of servers is to return the same preference number for each server in the set. When determining which server of equal preference to send mail to, "the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization", unless there is a clear reason to favor one.<ref name="RFC5321">RFC 5321</ref> 

An alternative approach is to use [[multihomed]] servers, where the one host returns several IP addresses.<ref name=balance/> This method places the burden on the DNS rather than the SMTP-sender to perform the load balancing, which in this case will present a list of IP addresses in a specific order to the clients querying the A record of the mail exchanger. Since the RFC requires that the SMTP-sender use the order given in the A record query, the DNS server is free to carefully manipulate its balancing based on any method, including [[round robin DNS]], mail server load, or some undisclosed priority scheme.

==="Backup" MX===
Some domains will have several MX records, one of which is intended as a "backup" - with a higher preference number so that it would not normally be picked as the target for email delivery. 

However, in the case of errors from the lower-numbered hosts, (perhaps due to an outage of some sort), sending email servers will deliver to the "backup" host - ''queue.example.com'' in the example below:

{{sxhl|2=zone|
Domain          TTL   Class    Type  Priority   Host
example.com.    1936    IN      MX   10         onemail.example.com.
example.com.    1936    IN      MX   10         twomail.example.com.
example.com.    1936    IN      MX   100        queue.example.com.
}}

If the backup server has direct access to user mailboxes, mail will proceed there, but otherwise will likely be queued on ''queue.example.com'' until the outage is resolved.

In the absence of this sort of arrangement, when a domain's mail servers are all offline, ''sending'' servers are required to queue messages destined for that domain to retry later. However, these sending servers have no way of being notified that a previously offline domain's servers are now available, and so resort to a [[polling system|polling schedule]] - and will only discover that the domain is available whenever they next attempt delivery. The delay between when a receiving domain's servers come online and when delayed messages are finally delivered can be therefore anywhere from minutes to days, depending on the retry schedule of the sending servers - and the receiving domain has no visibility or control over this.

===Spammers===
[[Spammer]]s may deliberately direct mail to one of the backup (high distance) MX servers of a domain first, on the assumption that such a server will have less effective anti-spam filters. An anti-spam technique called [[nolisting]] is based on assuming this behaviour.