Backup MX Configuration: Setting Up a Secondary Mail Host Correctly

Why "Just Add a Second MX Record" Isn't Enough

A domain administrator adds a second MX record, points it at some spare server, sets the priority higher than the primary, and considers the job done. Months later the primary goes down for an afternoon and that second host either refuses every connection, accepts mail and then has nowhere to send it, or — worse — accepts it, sits on it, and never delivers it at all. The record existed. The redundancy didn't.

A working backup MX isn't a DNS entry, it's a small piece of operational infrastructure with its own configuration, its own security posture, and its own testing routine. This guide walks through building one that actually does its job, using Postfix and Exim as the two most common self-hosted relay platforms, plus how the concept maps onto Microsoft 365 and Google Workspace environments where you don't control the primary server yourself.

What a Backup MX Host Actually Needs to Do

Functionally, a backup MX host has exactly one job: accept mail on behalf of a domain when the primary can't, hold it safely, and get it to the primary once that's possible again. That's it — it is not supposed to be a parallel mailbox system, and it doesn't need webmail, calendaring, or any of the features end users associate with "email." Three capabilities define whether a backup MX is actually functional:

• Restricted relay: it must only accept and forward mail for the specific domain(s) it's backing up, for nobody else, in either direction.
• Durable queueing: if it accepts a message it must hold it reliably, on disk, surviving its own restarts, until the primary is reachable — not drop it if its own process recycles.
• Retry logic toward the primary: it needs its own backoff schedule for re-attempting delivery to the primary, independent of whatever the original sender's retry schedule was doing.

Step-by-Step: Backup MX With Postfix

Postfix is a common choice for a lightweight backup relay because its default behavior already leans toward exactly this use case — accept, queue, forward — with only a few settings needing explicit attention.

1. Restrict accepted domains. In main.cf, set relay_domains = example.com to the specific domain(s) being backed up — never leave this open-ended.
2. Point relay transport at the primary. In transport_maps, map example.com to the primary mail host's hostname, so Postfix knows exactly where to forward once it accepts a message.
3. Enable relay recipient validation. Without a valid recipient list (via relay_recipient_maps or an LDAP/SQL lookup against the primary), the backup will accept mail for addresses that don't exist, then bounce it later — a backscatter problem that damages your sending reputation. Reject unknown recipients at SMTP time instead.
4. Set a sane queue lifetime. maximal_queue_lifetime should match or exceed how long you're willing to have mail stuck if the primary is down for an extended period — five days is a common default, longer for critical domains.
5. Add MX record. Publish the backup host as an MX record at a distinctly higher priority number than the primary (e.g. primary at 10, backup at 50).

Step-by-Step: Backup MX With Exim

Exim's approach is conceptually identical but configured through its router and transport sections rather than Postfix's flatter file structure.

1. Define the relay domain in a domain list, restricting acceptance to exactly the domain(s) being backed up.
2. Configure a manualroute router that sends accepted mail directly to the primary host's IP or hostname, bypassing a fresh MX lookup that would just point back at itself.
3. Enable recipient verification against the primary (via a callout or a synced recipient list) so invalid addresses are rejected during the SMTP conversation, not after acceptance.
4. Set retry rules in the retry configuration file specifically for the primary host's route, distinct from Exim's general retry policy for arbitrary destinations.

Backup MX for Microsoft 365 and Google Workspace Domains

When the primary platform is a cloud suite rather than self-hosted infrastructure, the calculus changes. Both Microsoft 365 and Google Workspace maintain substantial internal redundancy behind their own single published MX endpoint (or five-record set, for Workspace) — the kind of infrastructure a small organization couldn't replicate on its own. A dedicated third-party backup MX is far less commonly necessary here than in a self-hosted scenario, and adding one introduces its own operational overhead: another system that must stay in sync on spam filtering policy, another point where authentication headers could be altered in transit, another thing to monitor. For most Microsoft 365 and Google Workspace deployments, the pragmatic recommendation is to rely on the platform's own built-in redundancy rather than bolting on a self-managed backup MX, and reserve custom backup MX architecture for self-hosted mail infrastructure where no such built-in layer exists. Organizations with strict compliance or business-continuity requirements sometimes still choose to run one anyway — that's a legitimate choice, but it should be a deliberate one, not a default.

Security Implications: The Open Relay Trap

The single most damaging mistake in backup MX configuration is accidentally building an open relay — a server that will forward mail for any domain, to any domain, for any sender. This happens most often when an administrator, trying to "just get it working," relaxes relay restrictions rather than configuring them precisely, intending to lock it down "later." Spammers actively scan for exactly this misconfiguration, and an open relay is typically found and abused within hours of going live, not weeks. The consequences compound: your backup host's IP gets blacklisted, which then affects deliverability for the legitimate mail it's supposed to be protecting, and cleanup — getting delisted from blacklists — can take days to weeks even after the misconfiguration is fixed.

A second, subtler risk is authentication drift. If the backup host doesn't preserve or correctly pass through DKIM signatures and doesn't align with the domain's SPF record, mail routed through it during a failover event can fail DMARC alignment even though it's entirely legitimate — arriving from an authorized, intended host, just one that wasn't properly accounted for in the authentication configuration.

Disaster Recovery and High Availability Design Patterns

For organizations where email continuity is a hard business requirement rather than a nice-to-have, backup MX is one layer in a broader pattern rather than a complete solution on its own. Common patterns layered together:

• Geographic separation: primary and backup hosted in genuinely different physical locations or cloud regions, so a regional outage doesn't take both down together.
• Provider diversity: primary on one platform, backup relay hosted with a different provider entirely, avoiding a shared point of failure at the infrastructure or account level.
• Extended queue tolerance: configuring the backup's queue lifetime generously enough to survive a multi-day primary outage, not just a brief blip.
• Active monitoring, not passive existence: synthetic test messages sent through the backup path on a schedule, with alerting if delivery to the primary doesn't complete within an expected window.

Performance Considerations

A backup MX host under real failover load can see a sudden traffic spike — every sender that had been queuing against an unreachable primary starts succeeding against the backup simultaneously once it's live, and depending on how long the primary was down, that can mean a backlog measured in hours of normal volume arriving in a short window. Sizing the backup relay's disk queue capacity and connection concurrency limits for that burst pattern — not just steady-state traffic — avoids the backup itself becoming the bottleneck exactly when it's needed most.

Troubleshooting a Backup MX That Isn't Working

Related Tools

Confirm your backup host is published correctly with MX Lookup. Verify it's covered by your authentication policy with SPF Lookup. For the priority mechanics that determine when the backup gets used at all, read MX Priority Explained. For exactly what triggers a sender to fall through to this backup, see MX Failover: How Automatic Mail Rerouting Works. For the broader record type, the MX Record Complete Guide.