MX Record Priority Explained: How Mail Server Preference Works
Learn what MX record priority numbers mean, how mail servers use them for failover, and how to configure primary and backup mail servers correctly.
Every MX record has two parts: a mail server hostname and a number called the priority (sometimes called preference). If you've ever looked up your domain's MX records and wondered what those numbers mean, this guide explains it clearly, no technical background required.
What Is MX Record Priority?
When an email is sent to your domain, the sending mail server looks up your MX records to find out where to deliver the message. If you have more than one MX record (which is common), the priority number tells the sending server which one to try first.
The rule is simple: lower numbers mean higher priority. A server with priority 1 will be tried before a server with priority 10. A server with priority 10 will be tried before a server with priority 20.
This feels counterintuitive at first. You might expect "priority 1" to mean "least important," the way first place in a waiting list means you're at the front. In MX records, priority works the same way: priority 1 is at the front of the line, meaning it gets contacted first.
Some DNS providers use the word "preference" instead of "priority." It means the same thing.
Why Priority Matters: The Failover Mechanism
The real purpose of priority values is failover. If your primary mail server is down or unreachable, sending mail servers won't give up immediately. Instead, they'll try your backup server.
Here's how it works in practice:
- A sending server looks up your MX records and finds two entries: one with priority 10 and one with priority 20.
- It tries to connect to the priority 10 server first.
- If the priority 10 server doesn't respond, it tries the priority 20 server.
- If the priority 20 server accepts the message, email is delivered.
Without a backup MX record, a sending server that can't reach your primary server will queue the message and retry later. Temporary problems might resolve themselves during this window, but extended outages will eventually result in bounced email. A backup server prevents that.
Common MX Priority Configurations
Single Mail Server (No Backup)
Many small businesses use a single MX record:
| Priority | Mail Server | |---|---| | 10 | mail.yourdomain.com |
This is the simplest setup. All email goes to one server. If that server is down, sending servers queue and retry, but you risk delivery failures during extended outages. Most hosted email services (Google Workspace, Microsoft 365) handle their own internal redundancy, so a single MX record pointing to their infrastructure is perfectly fine.
Primary and Backup Server
The classic resilient setup uses two MX records with different priorities:
| Priority | Mail Server | |---|---| | 10 | mail1.yourdomain.com | | 20 | mail2.yourdomain.com |
The gap between priority values (10 and 20 vs. 1 and 2) doesn't matter functionally; only the relative order matters. Many administrators prefer gaps like 10/20 or 5/10 so they can insert additional records later without renumbering.
Google Workspace Configuration
Google's recommended MX setup uses five servers across two priority levels:
| Priority | Mail Server | |---|---| | 1 | aspmx.l.google.com | | 5 | alt1.aspmx.l.google.com | | 5 | alt2.aspmx.l.google.com | | 10 | alt3.aspmx.l.google.com | | 10 | alt4.aspmx.l.google.com |
Notice that two servers share priority 5 and two share priority 10. When multiple servers have the same priority, sending mail servers distribute messages between them randomly, a simple form of load balancing. This is how Google handles scale while maintaining failover at each tier.
Microsoft 365 Configuration
Microsoft uses a single MX record per domain:
| Priority | Mail Server | |---|---| | 0 | yourdomain-com.mail.protection.outlook.com |
Priority 0 simply means it's the highest-priority (only) record. Microsoft handles redundancy within their infrastructure, so you don't need multiple MX records.
Round-Robin Load Balancing
Some organizations run their own mail infrastructure and distribute load evenly across several servers by assigning all of them the same priority:
| Priority | Mail Server | |---|---| | 10 | mail1.yourdomain.com | | 10 | mail2.yourdomain.com | | 10 | mail3.yourdomain.com |
With equal priorities, sending servers choose randomly among them. This distributes load but doesn't provide true failover, since if one server is down, the sending server might still try it. This setup is rare outside of large enterprise environments.
How to Check Your MX Record Priorities
You can see your domain's current MX records and their priority values at mxrecordchecker.com. Enter your domain name and the results will show each MX record with its priority number and whether the mail server is currently responding.
This is useful for:
- Verifying your records are configured as intended
- Confirming you have the right servers listed after a migration
- Checking that backup servers are in place
- Auditing a new client's email setup
Common Priority Mistakes
Reversed Priority Order
The most common mistake is setting priorities backward, assigning a higher number to the server that should be primary. For example:
| Priority | Mail Server | |---|---| | 20 | primary-server.com | | 10 | backup-server.com |
In this case, all email would go to the backup server first, with the primary server only receiving mail when the backup is unavailable. This causes unexpected behavior and is hard to diagnose without checking the MX records directly.
Missing Backup Records
Running a single MX record with no backup is a risk for self-hosted mail setups. If your mail server goes down for maintenance, a disk issue, or an unexpected failure, incoming email will queue up at sending servers and eventually bounce if your server is down too long.
Adding Backup Records That Point Nowhere
Some guides suggest adding a low-priority "catch-all" backup MX record pointing to your root domain or another server as a spam prevention technique. The theory is that spammers try backup servers first because they sometimes have looser filtering. In practice, this creates real delivery problems if the backup server isn't properly configured. Only add backup MX records that point to real, working mail servers.
Wrong Hostnames at Correct Priorities
Getting the priorities right but the hostnames wrong is a quieter version of misconfiguration. Email might partially work if one of several servers is correct, making the problem harder to spot. Always verify both the hostname and the priority value when checking your records at mxrecordchecker.com.
Priority Values Don't Have to Be Specific Numbers
There's no requirement to use 1, 5, 10, or 20. You could use 100 and 200, or 1 and 1000. What matters is only the relative ordering. Your email provider will tell you what values to use, and you should follow their instructions exactly.
Some providers specify exact values because their systems verify the configuration. Google, for example, checks that your MX records match their recommended values when you set up Google Workspace.