MX Record Priority Explained: A Complete Guide (2026)

Q: What is the maximum number of MX records I can have?

While the DNS specification doesn't set a hard "limit," the primary limit is determined by the UDP packet size (typically 512 bytes for standard DNS). Having too many records can force the DNS response to switch to TCP, causing latency. We recommend keeping your MX record count under 5 to ensure fast resolution and high deliverability.

Q: Can I point an MX record to a CNAME?

Absolutely not. This is a violation of RFC 2181. MX records must always point to an A record (IPv4) or AAAA record (IPv6). Pointing an MX record to a CNAME can cause mail loops and is frequently rejected by modern mail transfer agents (MTAs), resulting in lost email.

Q: What happens if the highest priority server is busy?

If the primary server (lowest number) responds with a "busy" signal (like a 4xx temporary error), the sending server will usually attempt to redeliver to the same server later rather than immediately failing over to the backup. Failover to the lower priority (higher number) server typically happens only when the primary is completely unreachable (connection timeout or refusal).

Q: Does MX Priority affect email delivery speed?

Indirectly, yes. If your primary server (Priority 0) is slow or misconfigured, the sending server wastes time trying to connect before timing out and moving to Priority 10. This "timeout" phase can delay email delivery by seconds or even minutes. Keeping your primary priority healthy is key to instant delivery.

Q: How do spammers exploit backup MX records?

Spammers know that backup servers (higher priority numbers) often have weaker spam filtering than primary servers. This technique, known as "MX Preference Spamming," targets your backup server hoping to bypass security. To prevent this, ensure your backup MX servers have the exact same security policies and spam filters as your primary servers.

Q: What is the "Null MX" record (Priority 0 with a dot)?

A Null MX record (RFC 7505) is used for domains that should never receive email. It is configured with priority 0 and a target of "." (a dot). This tells sending servers immediately that the domain does not accept mail, preventing them from wasting resources trying to connect or look for fallbacks.

Q: How often should I check my MX records?

We recommend auditing your DNS records quarterly. However, during any migration or infrastructure change, immediate verification is mandatory. Automated monitoring tools can also alert you if your MX records disappear or change unexpectedly, which is a common symptom of DNS hijacking.

Q: Can I mix Google Workspace and Microsoft 365 MX records?

Technically, you can add MX records for both, but it rarely works as a "dual delivery" mechanism via DNS alone. DNS creates a "race condition" or random distribution if priorities are equal, splitting mail between two unconnected inboxes. Proper dual delivery requires setting one provider as the primary MX and configuring internal forwarding rules to the second provider.

What Exactly Is MX Record Priority?
Why Do You Need Multiple MX Records?
How Does the Mail Delivery Process Actually Work?
Case Study: How an MX Checker Saved My Migration
Can You Load Balance with Equal Priority?
What Are Common Configuration Pitfalls?
Advanced Technical FAQ

Email remains the backbone of modern communication, yet the infrastructure that guides it—specifically the Mail Exchange (MX) record—is often misunderstood. While most administrators know they need an MX record to receive email, the nuance of mx server priority determines exactly how reliable that reception is. This guide deconstructs the logic behind preference numbers, helping you architect a resilient email system that can withstand server outages and high traffic loads.

What Exactly Is MX Record Priority?

Quick Answer: MX record priority is a numerical value assigned to a mail server in DNS records that dictates the order in which sending servers attempt to deliver email. A lower number (e.g., 0 or 10) indicates higher priority, meaning it is the primary destination, while higher numbers (e.g., 50 or 100) are reserved for backup or secondary servers.

When you look at a DNS zone file, you will see a preference value next to the mail server address. This integer is the "distance" or preference. The fundamental rule of analyze MX priority is counter-intuitive to some: Lowest number wins.

Think of the priority value not as a ranking of power, but as a "distance" from the optimal delivery point. A priority of '0' means "start here." If that server is unreachable, the sending server (MTA) looks for the next lowest number, perhaps '10'. It will not attempt delivery to a priority '20' server if the priority '10' server is responding. This hierarchy allows administrators to designate primary servers for handling traffic and secondary servers for disaster recovery.

💡 Expert Perspective: 2026 Standard

In 2026, we rarely see single-digit increments used in complex environments. The modern standard is to use wide gaps between your mx priority levels (e.g., 10, 20, 50). This spacing allows you to insert new mail servers into the priority list later without having to renumber your entire legacy infrastructure. Don't use '0' unless you are absolutely certain that server will always be the primary entry point; it leaves no room for a "higher" priority insertion later.

Why Do You Need Multiple MX Records?

Quick Answer: Multiple MX records provide critical redundancy and failover capabilities, ensuring that emails are not bounced back to the sender during server maintenance or outages. By defining a backup mail server with a higher priority value, you create a safety net that queues messages until the primary server comes back online.

Single points of failure are the enemy of IT infrastructure. If you only have one MX record and that server goes offline for maintenance or due to a DDoS attack, incoming emails will bounce. The sender will receive a "Delivery Failed" notification, which looks unprofessional and can disrupt business operations.

With multiple mx records, the process changes significantly. If the primary server (Priority 10) times out, the sending server automatically tries the next one (Priority 20). Usually, these secondary servers act as "store-and-forward" systems. They accept the mail, queue it, and periodically attempt to push it to the primary server once it is reachable again.

For a deeper understanding of the SMTP protocol standards that govern this behavior, referencing the IETF RFC 5321 is highly recommended for network engineers.

⚙️ Pro Tip: Geo-Redundancy

Don't just add a second server in the same data center. A true backup strategy involves mx distance in a geographic sense as well. Host your Priority 10 server in US-East and your Priority 20 server in US-West or Europe. This protects your mail flow against regional power grid failures or natural disasters.

How Does the Mail Delivery Process Actually Work?

Quick Answer: The delivery process begins with a DNS lookup where the sending server queries the recipient's domain for MX records. The sender sorts the returned records by priority preference (lowest to highest) and attempts to connect to the primary server first; if that connection fails, it moves sequentially down the list to the mail preference backups.

Let's visualize the handshake. When someone sends an email to [email protected]:

DNS Query: The sending server asks DNS, "Who handles mail for example.com?"
Record Retrieval: The DNS returns a list:
- mx1.example.com (Priority 10)
- mx2.example.com (Priority 20)
Selection: The sender selects mx1 because 10 < 20.
Connection Attempt: It tries to open an SMTP connection on port 25.
Failover (If needed): If mx1 is dead, the sender references the list again and tries mx2.

Case Study: How an MX Checker Saved My Migration

Last month, I was tasked with migrating a client from a legacy on-premise Exchange server to Google Workspace. The stakes were high—this was a logistics company that operated 24/7. Missing an invoice email meant halting trucks.

The plan was a "split delivery" setup where we routed mail to Google first, and if the user wasn't found there, it would route back to the on-premise server. This required precise MX record manipulation. I set the Google servers to Priority 1 and the legacy server to Priority 10.

However, 24 hours after the switch, users reported intermittent delays. Some emails arrived instantly; others took 45 minutes. I was baffled. The TTL was low, and propagation should have been complete.

I used ToolCheckers MX Tool to analyze MX priority configuration from an external perspective. The tool instantly flagged an issue I had missed: a rogue, "ghost" MX record from an old spam filtering service (Barracuda) that had been set to Priority 5 years ago and forgotten.

Because Priority 5 is lower than my "backup" Priority 10 but higher than Google's Priority 1, it was catching failover traffic and creating a routing loop whenever Google's servers had even a millisecond of latency. Without a dedicated tool to visualize the hierarchy clearly, I would have spent days troubleshooting firewall logs. I removed the record, and mail flow smoothed out instantly.

Can You Load Balance with Equal Priority?

Quick Answer: Yes, assigning the same priority number to multiple MX records creates a load-balancing configuration. When sending servers encounter multiple records with identical preference values, they randomly pick one to connect to, effectively distributing the incoming email traffic across your server cluster.

This is a technique used by major providers like Google and Microsoft. If you query Google's MX records, you might see five different servers all set to priority '10' (or varying slight differences).

How Round-Robin DNS Affects MX

When priorities are equal (e.g., mx1 is 10 and mx2 is 10), the load is shared roughly 50/50. This is excellent for high-volume environments where a single server cannot process the queue fast enough. It also improves reliability; if one "Priority 10" server dies, the traffic simply shifts to the remaining "Priority 10" servers without needing to fall back to a "Priority 20" disaster recovery site.

⚖️ Pro Tip: Weighting vs. Priority

Unlike SRV records, standard MX records do not support "weighting" (sending 70% to server A and 30% to server B). If the priority numbers are the same, the distribution is random/even. To control traffic flow more precisely, you need a load balancer in front of your mail servers rather than relying solely on DNS.

Advanced Technical FAQ

Below are answers to complex configuration questions often faced by systems administrators. These insights are designed to help you verify your MX priority levels and ensure compliance with 2026 security standards.

1. What is the maximum number of MX records I can have?

While the DNS specification doesn't set a hard "limit," the practical limit is determined by the UDP packet size (typically 512 bytes for standard DNS). Having too many records can force the DNS response to switch to TCP, causing latency. We recommend keeping your MX record count under 5 to ensure fast resolution and high deliverability.

2. Can I point an MX record to a CNAME?

Absolutely not. This is a violation of RFC 2181. MX records must always point to an A record (IPv4) or AAAA record (IPv6). Pointing an MX record to a CNAME can cause mail loops and is frequently rejected by modern mail transfer agents (MTAs), resulting in lost email.

3. What happens if the highest priority server is busy?

If the primary server (lowest number) responds with a "busy" signal (like a 4xx temporary error), the sending server will usually attempt to redeliver to the same server later rather than immediately failing over to the backup. Failover to the lower priority (higher number) server typically happens only when the primary is completely unreachable (connection timeout or refusal).

4. Does MX Priority affect email delivery speed?

Indirectly, yes. If your primary server (Priority 0) is slow or misconfigured, the sending server wastes time trying to connect before timing out and moving to Priority 10. This "timeout" phase can delay email delivery by seconds or even minutes. Keeping your primary priority healthy is key to instant delivery.

5. How do spammers exploit backup MX records?

Spammers know that backup servers (higher priority numbers) often have weaker spam filtering than primary servers. This technique, known as "MX Preference Spamming," targets your backup server hoping to bypass security. To prevent this, ensure your backup MX servers have the exact same security policies and spam filters as your primary servers.

6. What is the "Null MX" record (Priority 0 with a dot)?

A Null MX record (RFC 7505) is used for domains that should never receive email. It is configured with priority 0 and a target of "." (a dot). This tells sending servers immediately that the domain does not accept mail, preventing them from wasting resources trying to connect or look for fallbacks.

7. How often should I check my MX records?