MX record

Key takeaways

MX record belongs to science; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect MX record to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of MX record from memory before moving on to harder problems.

Reference excerpt

A mail exchanger record (MX record) specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.

Overview Resource records are the basic information element of the Domain Name System (DNS). An MX record is one of these, and a domain may have one or more of these set up, as below:

The characteristic payload information of an MX record is a preference value (above labelled "Priority"), and the domain name of a mailserver ("Host" above). The priority field identifies which mailserver should be preferred - in this case the values are both 10, so mail would be expected to flow evenly to both onemail.example.com and twomail.example.com - a common configuration. The host name must map directly to one or more address records (A, or AAAA) in the DNS, and must not point to any CNAME records. When an e-mail message is sent through the Internet, the sending mail transfer agent (MTA) queries the Domain Name System for the MX records of each recipient's domain name. This query returns a list of host names of mail exchange servers accepting incoming mail for that domain and their preferences. The sending agent then attempts to establish an SMTP connection, trying the host with the lowest "Priority" value first. The system allows high-availability clusters of mail gateways to be built for one domain if necessary. The MX mechanism does not grant the ability to provide mail service on alternative port numbers, nor does it provide the ability to distribute mail delivery across a set of unequal-priority mail servers by assigning a weighting value to each one.

MX preference, distance, and priority According to RFC 5321, the lowest-numbered records are the most preferred. 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 16-bit 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.

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. An alternative approach is to use multihomed servers, where the one host returns several IP addresses. 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.

Spammers Spammers 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.

Handling of delivery failure The SMTP RFC is ambiguous about exactly what kinds of delivery failure must result in re-attempting delivery via more distant MX records (those with higher preference values). When servers indicate temporary failures, either by explicitly sending a 4xx error or by ending the connection unexpectedly (which must be treated as a 451 error, according to Section 3.8 of the RFC), Section 4.5.4.1 says:

The sender MUST delay retrying a particular destination after one attempt has failed. However, when the sender retries, the RFC is silent about whether this should be to the same server, or a more "distant" MX record. It does say, in Section 5.1:

When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. Some servers (such as Sendmail and Postfix 2.1 or later), will attempt the next-furthest MX server after some types of temporary delivery failures, such as greeting failures. Other servers (such as qmail and Postfix 2.0 or earlier) will only use more distant MX records if the servers specified in the shortest-distance MX records could not be contacted at all. Despite the difference, both behaviors are valid - since the RFC is not specific.

Fallback to the address record In the absence of an MX record, email senders will attempt delivery to the address record - e.g. example.com. This is based on RFC 5321 sec. 5.1, which states :

SMTP clients must look up an MX record; If (and only if) no MX record for the domain is present, treat the domain as if it had an MX record with the given domain as the target hostname and a preference value of 0 Perform A or AAAA lookups as required to determine the IP address of the target hostname

… excerpt ends here. Continue reading the full article.

Worked examples

Example 1 — a first encounter with MX record

Start with the simplest possible case. Write down what MX record claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In science, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to MX record before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about MX record ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of MX record

In research: MX record appears in science research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses MX record in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: MX record is common in secondary-school and first-year university syllabi. It links to neighbouring topics DNS record types, Email, so understanding it makes those chapters shorter.
In everyday life: Look for MX record outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

How to study MX record in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what MX record means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain MX record out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is MX record in simple terms?

A mail exchanger record (MX record) specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS).

Why does MX record matter?

Because it connects several science ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study MX record?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on MX record.