MX DNS Record

What the MX record does

An MX record answers one question for one protocol: where does SMTP deliver mail addressed to this domain. Nothing else in DNS consults it.

The preference number is the part people misread. It is an ordering, not a percentage split and not a health check. Preference 10 and preference 20 mean “try the first, and if it will not take the message, try the second”; hosts sharing one preference are interchangeable, which is how providers spread inbound load.

Zone-file and wire format

The syntax is name TTL IN MX preference target., and the RDATA on the wire is a 16-bit unsigned integer followed by a domain name. Because the target is a name, the sender must resolve it, and RFC 2181 §10.3 is explicit that it must not be an alias: an MX target owns address records directly and is never a CNAME. The special case is the null MX of RFC 7505 — preference 0, target . — declaring that the domain accepts no mail.

; two hosts, tried in ascending preference order
example.com.        3600   IN   MX   10 mail1.example.com.
example.com.        3600   IN   MX   20 mail2.example.com.

; the targets need real address records, not aliases
mail1.example.com.  3600   IN   A    203.0.113.25

; a name that will never receive mail: null MX
noreply.example.com. 3600  IN   MX   0 .

Common uses

Nearly every MX set now points at a hosted provider, which is why the records are usually pasted from a setup page and then forgotten. The null MX is the deliberate use worth knowing: publish it on parked domains and on names you use only for outbound tooling, and senders give up immediately instead of queueing for days.

Troubleshooting

Check the target chain first. Resolve each MX target and confirm it returns an address record and not a CNAME; several large receivers treat an aliased MX as a configuration error. Then confirm the host listens on port 25 from outside your network, since a correct record in front of a firewalled host looks identical to a missing one. A sender that reaches nothing queues and retries for hours, so an MX outage surfaces as delay rather than loss.

If mail arrives at a server you did not expect, look for the absence of MX records rather than their presence: a sender with no MX answer falls back to the domain’s address records, so deleting an MX set routes mail at your web server.

# the MX set, sorted the way a sender will read it
dig example.com MX +short | sort -n

# every target must resolve to an address, not a CNAME
for t in $(dig +short example.com MX | awk '{print $2}'); do
  printf '%s -> ' "$t"; dig +short "$t" A "$t" AAAA | tr '\n' ' '; echo
done

# a null MX looks like this
dig noreply.example.com MX +noall +answer

Equal-preference hosts are load balanced by a MUST, not a convention

The claim that same-preference hosts “spread inbound load” is not merely a side effect of having several targets — it is a mandatory requirement on the sending side. RFC 5321 §5.1 states that when multiple destinations share the same preference and there is no clear reason to prefer one, “the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.” This is one of the few places DNS-adjacent protocol behaviour is dictated to the client this strictly: a compliant sending server cannot simply always try the first equal-preference host listed in the DNS response and fall back only on failure, the way a naive implementation of “try in order” might read.

The same section requires the client to keep working down the full sorted list, retrying each relevant address until one delivery attempt succeeds, so the randomization applies within a preference tier while the overall ordering across tiers is still respected. In practice this means you cannot rely on DNS response ordering to bias load between two equal-preference mail exchangers — some resolvers and forwarders reorder answers anyway, and a compliant sender ignores the order and picks randomly regardless. If you need genuinely uneven load distribution between two mail servers rather than an even split, the correct tool is different preference values, not the order you list equal-preference records in the zone file; a preference-10 and a preference-20 host will be tried in that order deterministically, while two preference-10 hosts will not.

The defining RFC

MX is type 15, defined in RFC 1035 §3.3.9. How a sender uses the records — sorting by preference, falling back to address records when no MX exists — is RFC 5321 §5.1. The prohibition on aliased targets is RFC 2181 §10.3, and the null MX convention is RFC 7505, a Proposed Standard. Inspect a mail domain with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

MX record

Zone-file example