Setting up multiple MX records is the standard method for achieving email redundancy. By assigning different priority values to your mail servers, you ensure that if the primary server fails, incoming messages are automatically routed to a backup host. This configuration prevents downtime and ensures uninterrupted communication for your domain without requiring complex load balancing logic.
Understanding MX Record Priorities
The Mail Exchange (MX) record tells the internet where to deliver email for your domain. Unlike A or AAAA records which point directly to an IP address, MX records point to other domain names (hostnames) that resolve to those IPs. The critical component here is the priority value, also known as preference.
This integer determines the order in which mail servers should be contacted. Lower numbers indicate higher priority. For example, a priority of 10 is preferred over a priority of 20. When a sending mail transfer agent (MTA) looks up your domain, it queries DNS for all available MX records. It then attempts to connect to the server with the lowest priority number first. If that connection fails, it tries the next lowest, continuing until a successful delivery occurs or all options are exhausted.
Configuring Primary and Backup Servers
To implement this, you need at least two distinct mail servers. One acts as the primary receiver, handling most traffic under normal conditions. The second acts as a standby, ready to take over only when the primary is unreachable. You must ensure both servers are properly configured to accept mail for your domain.
In your DNS provider’s control panel, locate the zone file for your domain. Add the first MX record for your primary server. Use a hostname like
mail.primary.example.com and assign it a low priority value, such as 10. Ensure this hostname has a corresponding A record pointing to the public IP address of your primary mail server.
Next, add the second MX record for your backup server. Use a hostname like
mail.backup.example.com. Assign it a higher priority value, such as 50 or 100. This significant gap ensures that senders will not attempt to use the backup unless the primary is completely down. Again, verify that the backup hostname resolves to the correct IP address via an A record.
It is crucial to understand that these priorities do not create a load-balanced system where traffic is split evenly. They create a failover system. All traffic goes to the primary until it fails. If you want to distribute load, you would typically use round-robin A records for a single hostname or a dedicated load balancer, but for simple redundancy, distinct MX priorities are the correct approach.
For more details on diagnosing connectivity issues that might affect your mail flow, see
Ping Strange Behavior: Troubleshooting Networking and DNS Issues.
DNS Propagation and TTL Settings
After adding your MX records, changes do not happen instantly. DNS relies on caching to reduce load on root servers. The Time To Live (TTL) value dictates how long other DNS resolvers should cache your record before checking for updates.
If you are setting up a new redundancy scheme, consider lowering the TTL of your existing MX records a few days before making changes. This allows the new records to propagate faster once you update them. However, for most self-hosted setups, the default TTL provided by your DNS host is sufficient. Once updated, use tools like
dig or online MX lookup services to verify that your records are visible globally.
Check the output of
dig MX yourdomain.com. You should see both entries listed. The one with the lower number should appear first in the response, confirming your priority settings are active.
Testing Failover Behavior
Configuration is not complete until you verify that the failover actually works. Do not rely solely on visual checks; you must simulate a failure. Start by sending test emails from external accounts (like Gmail or Outlook) to your domain. Confirm they arrive successfully on the primary server.
Then, intentionally shut down the primary mail service or block port 25 (SMTP) on its firewall. Send another test email. The sending server should receive a temporary failure message initially, but upon retrying, it should connect to the backup server due to the higher MX priority. Check the backup server’s mail queue or inbox to confirm receipt.
If the backup server does not receive the mail, check its logs. Ensure it is listening on the correct interface and that no firewall rules are blocking incoming SMTP connections. Also, verify that the backup server is not rejecting mail because it thinks it is the primary for the domain. In Postfix, for instance, ensure the
mydestination parameter includes your domain name on both servers.
Regarding local network resolution, remember that internal DNS queries might differ from external ones. If you are hosting your own DNS, ensure your internal views do not override the external MX priorities in a way that breaks external delivery. See
DNS PTR Requests for Local IP Addresses from Proxy Container for insights on managing DNS consistency across environments.
Common Pitfalls to Avoid
One common mistake is using the same priority value for both servers. If both have a priority of 10, senders may randomly choose between them, leading to inconsistent delivery and potential duplicate messages if both accept the mail. Always keep priorities distinct.
Another error is forgetting to configure SPF, DKIM, and DMARC records. These security protocols help prevent your domain from being marked as spam. While they do not control routing, they are essential for ensuring that emails delivered via your backup server are trusted by recipients. Update your TXT records to include the IP addresses of both primary and backup servers in your SPF policy.
Finally, monitor your backup server regularly. A redundant server that is offline, out of disk space, or misconfigured provides false security. Automated health checks can alert you if the backup server becomes unresponsive, allowing you to fix issues before a real emergency occurs.
Frequently Asked Questions
Can I use three or more MX records?
Yes, you can add as many MX records as needed, each with a unique priority. This allows for a tiered backup system, such as a primary, a secondary cloud backup, and a tertiary off-site archive. Senders will always try the lowest number first, moving down the list only if previous servers fail.
What happens if both my primary and backup servers are down?
If all MX records point to unreachable servers, sending MTAs will queue the message and retry periodically according to their own retry policies. Most major providers will hold the message for several hours or even days before returning a permanent failure to the sender. Your users will experience delays, but the message is rarely lost permanently.
Do I need separate domains for primary and backup?
No, both MX records should point to hostnames within the same domain. The MX record itself points to a hostname, which then resolves to an IP. You can use subdomains like
mail1.example.com and
mail2.example.com to distinguish the servers while keeping the same domain for email addressing.
How do I check if my MX records are working correctly?
Use command-line tools like
dig MX yourdomain.com or web-based mxtoolbox.com. These tools show the exact priority values and target hostnames. You can also use
telnet mail.backup.example.com 25 to manually test if the backup server is accepting SMTP connections from your current location.
Should I change the TTL when switching to a backup?
Changing the TTL after a failure is too late because resolvers have already cached the old data. Plan ahead by setting a low TTL (e.g., 300 seconds) during maintenance windows or migrations. For permanent redundancy setups, a standard TTL of 3600 seconds is usually acceptable, as failover depends on the sending server’s retry logic rather than immediate DNS propagation.