Backup MX Records

Backup MX records promise something appealing: email that keeps flowing even when your primary server goes down. Add a second server to your DNS, sleep easier at night.

But here's what the simple setup guides don't tell you: spammers know something most administrators don't. Backup mail servers are often the weakest link in email security. They target them specifically, probing for the filtering gaps that inevitably exist when backup systems don't mirror primary defenses.

Get backup MX right, and you have genuine resilience. Get it wrong, and you've created a spam gateway with your name on it.

How Backup MX Works

MX records tell the world where to deliver your email. The priority number determines the order—lower numbers get tried first:

example.com.    IN  MX  10  mail.example.com.
example.com.    IN  MX  20  backup-mail.example.com.

Under normal operation, all mail flows to the primary server at priority 10. The backup at priority 20 sits idle.

When the primary fails—connection timeout, server down, network unreachable—sending servers immediately try the backup. The backup accepts the message, queues it, and waits. When the primary recovers, the backup forwards everything it collected.

This is the promise. The reality is more complicated.

The Spam Problem Nobody Mentions

Backup MX servers face a unique vulnerability. Spammers deliberately target them using a technique called "backup MX snowshoeing"—probing secondary servers that often have weaker filtering than primaries.

The trap works like this:

1. Your backup accepts a message because its spam filtering is looser than your primary's
2. The backup forwards the message to your primary
3. Your primary rejects it as spam
4. Your backup must now send a bounce—but to a forged sender address
5. Your backup server is now sending unsolicited mail to innocent third parties

This is called backscatter, and it destroys your IP reputation. Your legitimate forwarding starts getting rejected. The backup you set up for reliability is now causing delivery failures.

Making Backup MX Actually Work

The solution is unglamorous: your backup must be as paranoid as your primary.

Match your spam filtering. Same rules, same blacklists, same greylisting. If your primary rejects something, your backup should reject it too—before accepting the message, not after.

Validate recipients before accepting. Your backup needs to know which email addresses actually exist in your organization. Accept mail for unknown users and you'll generate backscatter when you try to forward it. Options include:

• LDAP queries to your directory
• Synchronized recipient databases
• Recipient callout verification to your primary
• Static lists for smaller deployments

Filter at SMTP time. Reject bad mail during the SMTP conversation, before you've accepted responsibility for delivery:

• Check SPF and DKIM even on backup
• Reject mail from known spam sources
• Require proper HELO/EHLO
• Implement rate limiting

Configuration

Basic setup:

example.com.    IN  MX  10  mail.example.com.
example.com.    IN  MX  20  backup-mail.example.com.

Multiple backup tiers:

example.com.    IN  MX  10  mail.example.com.
example.com.    IN  MX  20  backup1.example.com.
example.com.    IN  MX  30  backup2.example.com.

Load-balanced backups (same priority distributes traffic):

example.com.    IN  MX  10  mail.example.com.
example.com.    IN  MX  20  backup1.example.com.
example.com.    IN  MX  20  backup2.example.com.

Critical detail: the backup server's priority number must be higher than the primary's. Getting this backwards means your backup receives all mail while your primary sits idle.

When Primary Recovers

The backup has been collecting messages. Now what?

Don't flood the primary. A server that just recovered doesn't need thousands of messages hitting it simultaneously. Throttle delivery to manageable rates.

Handle rejections gracefully. The primary might reject some messages—quota exceeded, recipient no longer exists. Generate bounces for permanent failures, re-queue for temporary ones, log everything for review.

Authenticate properly. Your primary server needs to accept relay from your backup. Whitelist the backup's IP address or configure authenticated SMTP between them. Otherwise your backup's forwarding attempts get rejected as unauthorized relay.

The Infrastructure Trap

Hosting your backup with the same provider as your primary defeats the purpose. When that provider has an outage, both servers go down together.

This seems obvious, but it's surprisingly common. The whole point of backup MX is surviving infrastructure failures. Put your backup somewhere different—different provider, different network, different geography.

Testing (Do This Before You Need It)

Backup MX failures are typically discovered during actual outages, which is the worst possible time.

Verify DNS:

$ dig example.com MX

Simulate outage: Disable SMTP on your primary, send test messages, confirm the backup accepts them.

Test forwarding: Re-enable the primary, verify the backup forwards its queue.

Test filtering: Send spam patterns to the backup, confirm rejection.

Test recipient validation: Send to nonexistent addresses, confirm rejection rather than acceptance.

Managed Services vs. Self-Hosted

Cloud backup MX services handle the complexity for you:

• SpamExperts (N-able) — Filtering plus backup
• MailRoute — Spam filtering with backup queuing
• MXGuarddog — Backup MX and filtering
• Cloudflare Email Routing — Basic forwarding

Self-hosted options if you want control:

• Postfix with queue management
• Exim with routing rules
• rspamd for spam detection

When You Don't Need Backup MX

Cloud email platforms like Office 365 and Google Workspace handle redundancy internally. If you've migrated to these services, backup MX configuration is usually unnecessary—and sometimes counterproductive if it interferes with the provider's own failover logic.

For low-volume personal domains, the complexity of proper backup MX often exceeds the benefit. Sending servers queue messages and retry for days before bouncing. Brief outages resolve themselves.