skip to content

How does DNS MX preference decide which mail server a sender tries, and what rules apply to the name an MX record points at?

level: middleimportance: should knowfreq 38%

answer

  1. a number plus a name
  2. smaller is sooner
  3. ties broken by chance
  4. the target is never an alias

basics

~20 s

Each MX record holds a 16-bit preference and an exchange host name; senders try the lowest value first, pick randomly among equal values, and the exchange must be a name with its own address records, never a CNAME or an IP address.

solid answer

~40 s

An `MX` record's RDATA is a 16-bit `PREFERENCE` and an `EXCHANGE` domain name, and RFC 1035 says lower values are preferred. A sender builds a list from all the `MX` records for the domain, sorted by preference; RFC 1123 §5.3.4 adds that among equal preferences it SHOULD pick at random to spread load, and that it must try the addresses in order until one succeeds. If every attempt fails with a temporary error, the message is requeued and retried later rather than bounced at once. The exchange name must not be an alias and must itself have address records (RFC 2181 §10.3), which is why servers add those addresses to the additional section of an `MX` answer. Only the relative order of the numbers matters, so 10/20 and 1/2 behave the same.

go deeper

for a junior

Recall that MX records name mail hosts with a number, that the lower number is tried first, and that the host is given by name.

for a middle

Explain the sender's ordering: sort by preference, random among ties, try each address in turn, requeue on temporary failure, and why the exchange must not be an alias.

for a senior

Design the MX set for resilience: equal preferences to share load, a backup that genuinely accepts mail, and exchange names whose address records you or your provider actually control.

for a principal

Judge whether a backup exchange earns its keep: senders already queue and retry, so a backup adds another server that must enforce the same filtering and policy.

## What an MX record contains An **MX** (mail exchange, type 15) record is published at the domain that receives mail, for example `example.com`. Its RDATA has exactly two fields (RFC 1035 §3.3.9): - **`PREFERENCE`**: a 16-bit unsigned integer. RFC 1035: "Lower values are preferred." - **`EXCHANGE`**: the domain name of a host willing to act as a mail exchange for the owner name. There is no port, no weight and no address in the record. The exchange's addresses come from its own `A` and `AAAA` records, and RFC 1035 says MX records cause additional-section processing, so a server answering an `MX` query usually includes those addresses too. ## How a sender orders the exchanges 1. Query `MX` for the domain to the right of the `@` in the envelope address. 2. Sort the exchanges by preference, lowest first. Only the order matters: preferences 10 and 20 behave exactly like 1 and 2, and leaving gaps simply makes room to insert servers later. 3. Among exchanges with **equal** preference, RFC 1123 §5.3.4 says the sender SHOULD pick one at random to spread load. 4. Resolve each exchange name to addresses. A multihomed exchange yields several, which are tried in the order the resolver interface presents them. 5. Try the resulting list in order until a delivery succeeds. RFC 1123 requires the sender to be able to try each address in turn, allows a configurable limit, and says it SHOULD try at least two. 6. If mapping or delivery fails with a temporary error, requeue the message and retry later (RFC 1123 §5.3.4, under the sending strategy of §5.3.1.1). A primary exchange that is down for an hour delays mail; it does not lose it. RFC 1123's SMTP rules are now carried by the current SMTP specification, which keeps the same ordering behaviour. ## Primary and backup exchanges | Record | Role | |---|---| | `example.com. MX 10 mx1.example.com.` | primary, tried first | | `example.com. MX 10 mx2.example.com.` | equal preference: a sender picks between the two at random | | `example.com. MX 50 backup.example.net.` | tried only when both preference-10 exchanges fail | A higher-numbered exchange is a **fallback**, not a share of the traffic. If you want two servers to split load, give them the same preference. A backup exchange must be configured to accept mail for the domain and to apply the same filtering as the primary, or it becomes the easiest way in. ## Rules for the exchange name - **Not an alias.** RFC 2181 §10.3: the domain name in an `MX` (and in an `NS`) record must not be an alias; it must have one or more address records of its own and may carry other records, but never a `CNAME`. - **Not an address.** `MX 10 192.0.2.25` is not a valid MX: the field is a domain name, so the text would be read as a name, not an IP address. - **Can live anywhere.** The exchange can be in another organisation's zone, which is how hosted mail works; that zone must publish the address records. - **Preference is mandatory.** Every `MX` record carries a preference value, even when there is only one exchange. ## Where SRV takes the idea further The **SRV** record (RFC 2782, type 33) generalises the MX pattern to any service. It lives at a name such as `_sip._tcp.example.com` and carries a **priority** (lowest-numbered first, like MX preference), a **weight** (proportional random choice among equal priorities), a **port**, and a **target** that, like an MX exchange, must have address records and must not be an alias. A target of `.` means the service is decidedly not available at that domain. MX has no weight and no port because mail's port is fixed by the mail protocol. ## What interviewers probe The direction of the number is the classic trap: many candidates guess that "higher preference" means "preferred". The next layer is what happens with equal values, whether a backup MX shares load, and why the exchange cannot be a CNAME. Mail-policy records such as SPF sit in `TXT`, not `MX`, and are a separate subject.

  • How does an SRV record extend the MX preference model?
    RFC 2782's SRV record, published at `_service._proto.name`, adds a 16-bit weight and a port to a priority and a target. Clients try the lowest priority they can reach and, among equal priorities, choose proportionally to weight. Like an MX exchange, the SRV target must have address records and must not be an alias, and a target of `.` says the service is not offered.
  • Two exchanges share preference 10 and a third has 50; does the preference-50 server take any traffic while both 10s are healthy?
    No. The sender works through the list in preference order and reaches the preference-50 exchange only after the preference-10 exchanges have failed. Between the two equal ones, RFC 1123 §5.3.4 says to pick at random, which is how equal preferences share load.

saying these in an interview costs you the question

  • The MX record with the highest preference number is tried first.
  • A backup MX with a higher number receives a share of normal traffic.
  • An MX record can name its mail server by IP address.
  • Pointing an MX at a CNAME is fine because resolvers follow aliases anyway.
  • If the primary MX is unreachable, the mail bounces back to the sender immediately.