The two parts of every MX record
An MX record has two fields: a priority (lower number means higher priority) and a target hostname — the actual mail server to deliver to. A domain typically has several MX records at different priorities:
example.com. MX 10 mail1.example.com. example.com. MX 20 mail2.example.com.
A sending mail server always attempts delivery to the lowest-priority- number target first (confusingly, "priority 10" is tried before "priority 20" — lower number wins). Only if that attempt fails — connection refused, timeout, or a permanent rejection — does it fall back to the next one.
What "failure" actually triggers fallback
Not every kind of failure moves on to the backup server. A permanent rejection for a specific message (like "mailbox doesn't exist") is final — retrying the backup server wouldn't help, since the problem is the recipient address, not the server. Fallback is for server-level failures: the connection can't be established at all, or the server times out. This distinction matters because it means a broken backup MX server can sit unnoticed indefinitely — it's only ever contacted when the primary fails, which might be rare enough that a broken fallback goes undetected for a long time.
Mail doesn't just vanish when the primary is down
This is the most commonly misunderstood part of the fallback behavior. When ALL of a domain's MX targets are unreachable, sending mail servers don't simply drop the message — SMTP is designed to retry delivery over a period of time (commonly configured for several days) before finally giving up and bouncing the message back to the sender. This is why a short mail-server outage often causes no visible mail loss at all: the senders' own servers quietly retry until your server comes back.
The record that has to point to a hostname, not an IP
MX records must point to a hostname that itself has an A (or AAAA) record — pointing directly to a bare IP address, or to a CNAME, is invalid per the DNS specification, and many mail servers will reject or ignore a misconfigured record like this. This trips people up occasionally when migrating mail infrastructure and pointing the MX target at a CNAME alias instead of a real hostname.
Why MX records matter for email authentication too
MX records aren't directly checked by SPF, DKIM, or DMARC — those are separate records — but a broken or missing MX record has a related, easily confused symptom: mail addressed to your domain bounces, which looks similar to (but is a completely different problem from) mail you send bouncing due to failed authentication.