Do I need a backup MX record? Usually not anymore

For the vast majority of domains, the modern answer is no — you do not need a backup MX record. The original reason backup MX servers existed has largely gone away: every sending mail server already queues messages and retries delivery for days when your primary is unreachable, so a brief outage does not lose mail. A poorly configured backup MX can actually make things worse by generating backscatter, becoming an open relay for spam, or accepting mail it can't deliver and bouncing it. A backup still makes sense in a few specific cases, covered below.

Senders already queue and retry for you

Under RFC 5321, a sending MTA that can't reach your mail server doesn't give up. It holds the message in its queue and retries on a backoff schedule, typically for several days (commonly up to 4–5) before returning a permanent failure to the original sender. It also sends a "delayed" warning, often after a few hours, so the sender knows there's a temporary problem.

That means a short outage — a reboot, a maintenance window, a few hours of downtime — costs you nothing. The mail simply lands once your primary comes back. A backup MX is solving a problem that the retry mechanism already solves for free.

A bad backup MX is a liability

The risk is that a backup host rarely runs the exact same filtering as the primary, and the differences cause real damage:

• Backscatter. If the backup accepts a message for a recipient that doesn't exist (because it lacks the primary's valid-recipient list), it can only discover the problem later — and then it bounces to the (often forged) sender. You become a source of misdirected bounces.
• Relay and spam abuse. Spammers actively probe the highest-numbered MX expecting weaker rules. A backup that accepts mail more loosely than the primary becomes an attractive injection point.
• Accept-then-bounce. Anything the backup accepts but can't ultimately deliver turns into a delayed bounce, which is worse for the legitimate sender than a clean "try again later" they'd have gotten from the retry queue.

The fix for all of these is to make the backup byte-for-byte identical to the primary in recipient validation and anti-spam policy — which is real, ongoing work most teams don't keep up with.

When a backup MX still earns its place

There are legitimate cases:

• Genuinely separate infrastructure. A backup on a different provider, network, and physical location protects against a sustained outage of your primary's data center or ISP — not just a reboot.
• Different organization or store-and-forward by design. Some setups intentionally route through a partner MX that holds mail and forwards it, often as part of a filtering or compliance gateway.
• Long outages you can't otherwise absorb. If your primary could be down longer than senders' retry windows (days), a backup that correctly spools and forwards prevents loss.

If you do run one, give it a higher preference number than the primary and ensure it enforces identical recipient validation and anti-spam rules:

example.com.   IN MX   10 mail.example.com.
example.com.   IN MX   20 backup.partner.net.

Look up your MX records →

Further reading

• MX record priority: the lowest number gets the mail first
• No MX record found: what it means and how to fix it
• Email deliverability checklist: SPF, DKIM, and DMARC in order
• RFC 5321 — Simple Mail Transfer Protocol (queueing and retry on temporary failure)