How do fallback MX servers function?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Your primary mail server goes offline. Maybe it's a planned maintenance window, maybe something just crashed. What happens to all the email headed your way? That's exactly what fallback MX servers are for.
A fallback MX server (also called a backup MX) is a secondary mail server listed in your DNS with a higher MX priority number. Lower numbers win, so a primary at priority 10 beats a backup at priority 20. Sending servers always try the lowest-priority server first.
When the primary goes down, here's what actually happens on the sending side. The sending server attempts your primary MX and gets either no response or a temporary error code (a 4xx SMTP response). That tells it to try the next server on the list. It finds your backup MX, connects successfully, and hands off the message. The backup server accepts it and queues it locally.
Now the backup server has a job to do. It holds that message and periodically retries delivery to your primary. Once the primary comes back online, the backup flushes its queue over. From the sender's perspective, the whole thing happened invisibly. The message got delivered. The timing might be off by a few hours, but nothing bounced.
How long will a sending server keep trying before giving up? Most ESPs and mail servers retry for 3 to 5 days before issuing a permanent bounce. So your backup MX gives you a meaningful window to fix the primary without losing mail in transit.
One thing worth knowing: backup MX servers are a real attack target. Spammers occasionally probe backup servers because they assume the filtering and authentication checks there are looser than on the primary. Your backup server needs the same spam filtering, SPF/DKIM/DMARC validation, and access controls as your primary. If it doesn't, it becomes the weak door into your infrastructure.
Hosted email services like Google Workspace and Microsoft 365 handle redundancy automatically behind the scenes. You typically have multiple MX records pointing to their infrastructure, and failover is managed for you. If you're running a self-hosted mail setup, you'll need to configure your backup MX explicitly and make sure it's just as hardened as the primary.
If you want to check how your MX records are currently configured and whether your fallback is set up correctly, our free email header analyzer can help you trace what actually happens to a message in transit. Or if something's actively broken, our SOS hotline is free and we actually pick up.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
