Backup MX Record & Secondary Mail Server Guide

A backup MX record designates a secondary mail server to receive and queue inbound emails when your primary mail exchanger is offline. While modern cloud providers have largely eliminated the need for traditional fallback servers, understanding how priority weights and queue delivery work remains essential for resilient email architecture.

How Backup MX Records and Secondary Mail Servers Work

When a sending mail transfer agent (MTA) wants to deliver an email to your domain, it performs a Domain Name System (DNS) query for your Mail Exchange (MX) records. The DNS server returns a list of mail servers, each associated with a preference or priority number.

Lower preference numbers indicate higher priority servers. The sending MTA always attempts to connect to the lowest preference number first. If that primary server accepts the connection, the message is delivered. If the primary server times out, refuses the connection, or returns a 4xx temporary error code, the sending MTA looks for the next lowest priority server—your secondary or backup mail exchanger.

The Priority Scale

MX priorities are strictly relative integers, typically set in increments of 10 or 5. For example:

mail.example.com with Priority 10 (Primary)
backup-mx.example.com with Priority 20 (Secondary/Backup)

To verify how external mail servers view your current configuration, you can use the MX Lookup tool to instantly inspect your active mail exchangers, priority values, and associated IP addresses.

The Lifecycle of an Email on a Secondary Mail Server

When your primary mail server goes down, your backup mail exchanger accepts incoming messages on its behalf. However, a secondary mail server does not deliver mail to your final mailboxes; it merely acts as a secure holding facility.

Receipt: The sending MTA connects to the backup MX because the primary MX is unreachable.
Validation: The backup MX checks recipient validity (if configured to do so) to prevent backscatter spam and queue bloat.
Queuing: The backup MX accepts the message and stores it in its local spool directory.
Polling: The backup MX continuously attempts to deliver the queued messages to your primary mail server.
Handover: Once your primary server comes back online, the backup MX flushes its queue, transferring all stored emails to your primary server for final delivery.

Do You Still Need a Backup MX Record Today?

In the early days of the internet, self-hosted mail servers running on unstable hardware and residential connections made backup MX servers mandatory. Today, the email landscape has shifted dramatically.

Feature	Traditional Backup MX	Modern Cloud Email (e.g., Exchange Online, Google Workspace)
Infrastructure	Self-managed or third-party relay	Multi-region, highly available cloud clusters
Uptime	Variable, dependent on maintenance	99.9% to 99.99% service level agreements
Spam Filtering	Often basic or misconfigured	Advanced machine learning and threat protection
Queue Management	Manual troubleshooting required	Automatic retry and multi-day spooling
Configuration	Complex local relay rules	Fully managed by the provider

If you use a major cloud email provider, you generally do not need a secondary mail server. Major providers maintain distributed global server arrays with built-in redundancy. If one data center fails, another seamlessly takes over routing without needing a separate backup MX record.

Furthermore, adding an unmanaged backup MX can severely compromise your security posture. Spammers frequently target low-priority backup servers because administrators often neglect their security updates, spam filters, or rate-limiting rules. If your backup MX accepts mail for invalid users and later forwards it, your domain can quickly become an open relay or get blacklisted.

When You Might Still Need a Secondary Mail Server

Despite cloud dominance, specific scenarios still justify a backup MX:

Strict Regulatory Compliance: Highly regulated industries may require air-gapped or on-premises disaster recovery relays that store email locally during WAN outages.
Self-Hosted Hybrid Infrastructure: Organizations running proprietary on-premises mail servers without high-availability clustering.
Unstable Edge Connectivity: Remote sites or industrial facilities with intermittent internet links that require local mail buffering.

Step-by-Step Configuration Guide

If you decide to implement a backup mail exchanger, you must configure both your DNS records and your secondary mail server's relay rules.

Step 1: Configure DNS Records

Log in to your DNS management console. Create or update your MX records with appropriate priorities. Names and menu paths vary by provider, but look for the "DNS Manager," "Zone Editor," or "DNS Records" section.

example.com.     IN   MX   10 primary.example.com.
example.com.     IN   MX   20 backup.example.com.
primary.example.com. IN A 192.0.2.10
backup.example.com.  IN A 192.0.2.20

Step 2: Configure the Backup Mail Server

Log in to your secondary mail server administration panel. You must explicitly configure the server to act as a secondary relay for your specific domain, rather than an open relay for the entire internet.

In postfix-based systems, you define your domains in the relay_domains configuration file:

# /etc/postfix/main.cf
relay_domains = example.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients

Step 3: Verify Your Setup

Use command-line utilities to verify that your DNS records resolve correctly and that your servers respond as expected.

# Query MX records using dig
dig example.com MX +noall +answer

Sample output:

example.com.		300	IN	MX	10 primary.example.com.
example.com.		300	IN	MX	20 backup.example.com.

Test SMTP connectivity to your backup exchanger using netcat or telnet:

ncat -v 192.0.2.20 25

Common Mistakes and How to Fix Them

Accepting Mail for Invalid Users (Backscatter): If your backup MX accepts mail for non-existent mailboxes, it will bounce the message back to a spoofed sender, causing backscatter spam. Fix: Synchronize your recipient lists or implement Callout Verification so the backup MX checks with the primary server before accepting mail.
Identical Priority Values: Assigning the same priority number to both primary and secondary servers causes round-robin distribution, sending half of your inbound mail to an unequipped backup server. Fix: Ensure strict integer separation, such as 10 for primary and 20 for backup.
Missing SPF and DKIM Alignment: Backup servers that blindly forward mail can break authentication if headers are altered improperly. Fix: Ensure your backup MX preserves original headers and relies on standard SMTP relay mechanisms without rewriting sender envelopes incorrectly.

Quick Checklist for Backup MX Deployment

Primary and secondary mail servers have distinct, sequential MX priorities (e.g., 10 and 20).
Secondary mail server is explicitly restricted to relaying only your domains.
Recipient verification is enabled on the backup server to drop spam early.
Firewall rules permit inbound port 25 traffic only to authorized mail exchangers.
Monitoring alerts notify administrators when the primary server goes down and the backup queue starts filling.

What Is a Backup Mail Exchanger and Do You Still Need One?