MX Record Priority: What the Numbers Actually Do

Every Mail Exchanger (MX) record in your Domain Name System (DNS) zone file includes an integer value known as preference or priority. When sending servers route email to your domain, this integer dictates the exact order in which target mail gateways are evaluated.

In DNS specifications, lower priority numbers represent higher precedence. An MX record with a priority of 10 will always be selected before a record with a priority of 20. Understanding this mechanism is essential for configuring high-availability email routing, setting up security gateways, and preventing message loss during server outages.

To verify your current DNS configuration across active name servers, run a quick query using an MX record lookup tool.

---

The Mechanics of Priority Evaluation in MTAs

When an external Mail Transfer Agent (MTA) needs to deliver a message, it initiates a DNS query for the recipient domain's MX records. The authoritative DNS server returns a resource record set (RRSet) containing array entries consisting of hostnames and their associated priority integers.

The sending MTA evaluates this array using a strict algorithmic sequence:

1. Sorting the Array: The MTA sorts all returned MX records numerically by their preference value in ascending order (0, 5, 10, 20, etc.).
2. Primary Connection Attempt: The MTA initiates a TCP connection on port 25 to the IP address associated with the lowest preference number.
3. Failover Execution: If the primary host fails to accept a TCP connection, times out during the SMTP handshake, or returns a temporary error, the MTA selects the next lowest preference value in the array.
4. Queue Management: If all listed hosts fail or time out, the sending MTA stores the message in its local retry queue and attempts the delivery process again at a later scheduled interval.

For a foundational breakdown of how these DNS resource records function within global email routing, read our full guide on what is an MX record.

---

Why Are MX Priorities Spaced in Tens (10, 20, 30)?

Systems engineers adopt the convention of spacing MX preference values by increments of 10—such as 10, 20, 30—to maintain administrative flexibility within zone files.

The DNS protocol treats priority values purely as relative markers, not absolute scales. A zone file with priority values of 1 and 2 behaves identically to a zone file with priority values of 10 and 20, or even 100 and 200. The sending MTA compares only the relative mathematical difference to order its connection attempts.

Spacing these values creates numerical headroom. If you need to introduce an intermediate email security filter, an inbound archival gateway, or a specialized testing node between your primary target (priority 10) and your failover target (priority 20), you can assign the new host a priority of 15 without needing to edit and re-propagate every existing MX record in your infrastructure.

---

Equal Priority Records: Round-Robin Load Distribution

When multiple MX records share the exact same preference integer, you are explicitly instructing sending MTAs to distribute delivery attempts equally across those endpoints.

Priority  Host
10        mail-a.domain.tld
10        mail-b.domain.tld

Upon receiving identical priority integers, the sending MTA randomizes its initial target selection or uses round-robin logic across the matching host group. If mail-a.domain.tld is unreachable, the sending MTA immediately fails over to mail-b.domain.tld before falling back to any higher-numbered priority tiers.

This architecture is standard among enterprise mail clusters and modern cloud providers. In high-throughput automated delivery environments, systems like the Best-TempMail architecture rely on distributed intake clusters behind identical priority tiers to ensure incoming messages are processed instantly without bottlenecking on a single entry point.

---

The SMTP Retry Protocol: 4xx vs 5xx Response Codes

An MTA does not blindly jump to a secondary MX host on every encountered error. Priority failover is governed strictly by the type of SMTP status code returned during the session.

Transient Failure Codes (4xx Series)

A 4xx status code (such as 421 Service Not Available or 450 Action Not Taken) signals a temporary error condition on the receiving server.

• MTA Action: When a primary host (priority 10) returns a 4xx error or fails at the network layer (connection refused, packet drop, connection timeout), the sending MTA treats the failure as soft. It moves down the priority chain to attempt delivery to the secondary host (priority 20).

Permanent Failure Codes (5xx Series)

A 5xx status code (such as 550 User Unknown or 554 Transaction Failed) signals an unrecoverable refusal by the destination host.

• MTA Action: If the primary host returns a 5xx response, the sending MTA terminates the connection and immediately generates a Non-Delivery Report (NDR/bounce message) to the sender. It will not attempt delivery to lower-priority MX hosts, because a permanent failure applies logically to the entire recipient domain, not just the single responding node.

---

The Operational Pitfalls of Legacy Secondary Backup MX Servers

In legacy network designs, organizations frequently operated a low-spec secondary server assigned a high preference number (e.g., priority 50) located at a remote site. This host was configured to store incoming mail when the primary server (priority 10) was down, flushing its queue back to the primary once connectivity was restored.

In modern email infrastructure, this pattern introduces severe operational risks:

1. Spam Vectors and Filtering Asymmetry

Spammers continuously run global port scans to discover secondary MX hosts. Because legacy backup servers often lacked the computing power and real-time security rules present on primary clusters, attackers purposefully targeted priority 50 endpoints to bypass primary security checks.

2. Delivery Delays and Greylisting Interactions

When secondary servers accept messages on behalf of a primary server, security mechanisms like greylisting can create extended delivery stalls. Modern mail delivery relies on temporary deferrals, so check our breakdown on what is greylisting to see how deferred connection attempts impact backup routing.

3. Queue Poisoning and Non-Delivery Loops

If a secondary MX host accepts a message for a non-existent user, it stores the message in a local spool. When it later attempts to deliver that message to the primary server, the primary server rejects it with a 550 error. The secondary server must then attempt to send a bounce back to the original sender address, which is often forged. This turns your secondary server into an unwitting source of backscatter spam.

---

How Priority Interacts with Authentication and DNS Caching

Changing an MX priority value in a active DNS zone requires careful synchronization with mail authentication protocols and cached time-to-live (TTL) counters.

Authentication Alignment

Every server listed across all MX priority tiers that directly sends outbound responses or processes inbound traffic must align with your domain's identity framework. To understand how cryptographic keys and IP policies protect these endpoints, read our detailed guide on how reliable temp mail infrastructure works. Ensure that secondary MX addresses are explicitly accounted for in your SPF record to prevent outbound failover messages from failing receiver checks.

DNS TTL and Propagation Delays

When you update an MX priority value—for example, changing a secondary server from priority 20 to priority 5 to prepare for maintenance—external MTAs will not recognize the update until their locally cached record set expires.

If your original record had a TTL of 86400 seconds (24 hours), sending MTAs worldwide will continue using the old priority hierarchy for up to a full day. To prevent dropped connections during migrations, shorten your MX record TTL to 300 seconds several days before altering priority assignments. For a deeper technical analysis of cache expiration behaviors across internet resolver trees, view our analysis on why DNS changes take time.

---

Deployment Patterns: Single vs. Multiple MX Architectures

Choosing between a single MX entry and a multi-tiered array depends on your underlying host infrastructure.

Single MX Architecture:
DNS MX Record (Priority 10) ---> Inbound Load Balancer / API Gateway ---> Internal Worker Cluster

Multi-Tier Architecture:
DNS MX Record (Priority 10) ---> Cloud Security Gateway (Primary)
DNS MX Record (Priority 20) ---> On-Premise Data Center (Failover)

Single MX Record Deployments

Deploying a single MX record pointing to a high-availability entry gateway is ideal when using managed disposable email platforms, modern cloud load balancers, or serverless intake endpoints.

For quick integration tests or ephemeral inbox provisioning, using a single endpoint managed via a temp mail infrastructure eliminates DNS lookup overhead. Developers can rely on services like Best-TempMail to receive incoming verification payloads at a unified entry point, avoiding the complex failover delays associated with multi-tiered DNS architectures.

Multi-Tier MX Record Deployments

Deploying multiple MX entries across distinct priority integers is necessary when:

• Operating hybrid setups where an cloud-based spam filter (Priority 10) scrubs incoming traffic before relaying clean messages to an on-premise exchange server (Priority 20).
• Maintaining geo-redundant datacenters where separate physical locations handle direct inbound SMTP connections.

When leveraging modern API structures for instant event updates, developer workflows can stream inbound payloads over active subscriptions using a live WebSocket connection, bypassing traditional polling loops entirely. Platforms including the Best-TempMail developer suite utilize these real-time streaming sockets to deliver parsed incoming emails directly to automated test runners.

---

Architectural Decision Guide

Scenario 1: Standard Cloud Email Deployment

Label: Single-Tier Multi-Record Configuration Use the exact MX record entries and identical preference numbers provided by your cloud email hosting platform. Modern platforms handle high availability behind unified ingress IP pools. Assigning custom preference numbers to provider records disrupts their built-in load distribution algorithms.

Scenario 2: External Security Filtering Architecture

Label: Multi-Tiered Dual-Host Configuration Set your cloud email security gateway host to Priority 10. Set your origin mail server hostname to Priority 20. Ensure your origin mail server firewall strictly rejects port 25 traffic originating from any IP outside your security filter's published netblocks to prevent attackers from bypassing your primary defense layer.

Scenario 3: Automated QA Testing Infrastructure

Label: Single-Tier Dedicated Gateway Configuration Do not use multi-tier failover models for automated integration test environments. Use a single dedicated gateway with a low TTL. Multi-tiered fallbacks introduce unpredictable retry latency when assertions depend on rapid message arrival within strict CI test timeouts.

---

Common MX Priority Misconfigurations and How to Fix Them

Misconfiguration: Asymmetric Priority TTLs

When configuring multiple MX records, administrators sometimes assign different TTL values to different priority rows within the same zone file.

• The Issue: Resolvers cache the primary record for one duration and the backup record for another, leading to inconsistent priority array sorting across sending servers.
• The Fix: Ensure every MX record in your domain's zone file shares the exact same TTL setting.

Misconfiguration: Direct-to-IP Host Routing

The RDATA field of an MX record must contain a valid, fully qualified domain name (FQDN). It must never contain a raw IPv4 or IPv6 address.

• The Issue: MTAs will reject the MX record as malformed during DNS parsing, causing immediate delivery failures regardless of the configured priority.
• The Fix: Create an A or AAAA record pointing to your server's IP address, then point your MX priority record directly to that A/AAAA hostname.

Misconfiguration: Host pointing to CNAME Records

Setting an MX record host value to point to a domain name that is itself a CNAME alias violates RFC 2181.

• The Issue: Sending MTAs encountering a CNAME inside an MX lookup may abort the session or drop the priority preference order, triggering unexpected route selection.
• The Fix: Ensure every MX record target resolves directly to an A/AAAA record canonical name.

---

Frequently Asked Questions

What is the highest possible MX record priority value?

The priority value in an MX record is a 16-bit unsigned integer. The valid range extends from 0 to 65535. Zero (0) represents the highest possible priority preference, while 65535 represents the lowest possible preference.

What happens if two MX records have the exact same priority?

When two or more MX records share an identical priority integer, sending servers distribute traffic across them. The sending MTA selects one of the matching hosts at random or via round-robin logic for its initial connection attempt. If that host is unreachable, it attempts delivery to the remaining equal-priority hosts before escalating to higher preference integers.

Does setting a priority of 0 make emails deliver faster?

No. Priority values dictate server selection sequence, not transport velocity. An MX record assigned priority 0 simply tells sending servers to attempt connection to that host first. Delivery speed depends entirely on network latency, SMTP handshake processing, queue length, and receiver processing efficiency.

Can I mix cloud email providers across different MX priority levels?

While technically permitted by DNS syntax, mixing completely different hosting providers across priority levels (e.g., Priority 10 pointing to Provider A, Priority 20 pointing to Provider B) is strongly discouraged. Because inbox rules, user accounts, and cryptographic signing keys are rarely synchronized across competing platforms in real time, failing over to a secondary provider often results in bounced messages or broken message threading.

How long does an MX priority change take to take effect?

The operational propagation time for an MX priority modification is governed directly by the Time-To-Live (TTL) value of the original record set. Sending MTAs will hold the old priority configuration in their local resolver cache until that TTL counter counts down to zero. Changing priorities globally typically takes anywhere from 5 minutes to 24 hours depending on your previous zone configuration.