MX record
Names the hosts that accept mail for a domain, in preference order.
Last updated July 27, 2026
Zone-file example
example.com. 3600 IN MX 10 mail1.example.com.Typical uses
- Pointing a domain's inbound mail at a hosted provider
- Listing several equal-preference hosts so a provider can spread inbound load
- Publishing a null MX on domains that will never receive mail
- Giving a subdomain its own mail routing, separate from the apex
When it breaks, check
- An MX target must be a hostname with an A or AAAA record, never a CNAME
- Lower preference numbers are tried first; the numbers are an order, not a weight
- With no MX record at all, senders fall back to the domain's own address records
- A backup MX you do not actively run is a spam relay, not resilience
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
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.