MX 2 vs MX 4 Priority: What the Numbers Actually Mean

Do not index

A mail outage can expose an MX configuration that looked correct for months. A primary receiving host fails, the sender keeps trying the lower-numbered record, and the supposedly reliable backup never receives a connection attempt. The result can be bounced replies, delayed conversations, missed contract messages, and reputation damage that reaches beyond the original DNS mistake.

MX priority 2 is preferred over MX priority 4 because lower numbers have higher preference. The number doesn't measure server quality, capacity, or reliability. It determines the order in which sending mail servers attempt delivery, so MX 2 should only point to the endpoint that deserves earlier delivery attempts, while MX 4 should represent a tested and authenticated fallback.

Table of Contents

Why Your MX Priority Number Matters More Than You Think The number controls routing order Why a backup can still damage reputation What MX Priority Actually Means in DNS Don't confuse the fields A compact record anatomy How Senders Use the Preference Value to Route Mail Failover isn't active-active by default Cached DNS can delay the result The quiet reputation problem Priority 2 vs Priority 4 Compared When MX 2 is the sensible choice When MX 4 is the sensible choice Recommended Configurations and Numbering Conventions Keep the zone easy to audit Common MX Priority Mistakes and Their Deliverability Cost Swapped priorities Identical priorities used as fake failover A narrow numbering gap Decommissioned targets left published Backups that weren't tested Connecting MX Priority to Your Full Authentication Stack A minimum review model Frequently Asked Questions About MX Priority Is MX 0 functionally different from MX 10?Does TTL change the effect of a priority update?Does every domain need a backup MX?What happens when two MX records share a priority?Can a priority change be reversed without downtime?

Why Your MX Priority Number Matters More Than You Think

A typical failure starts without warning. A company changes its inbound mail provider, adds a secondary host, and leaves the old MX record in place because the DNS screen shows no obvious error. The primary record has preference 2, but its hostname resolves to an obsolete destination. The live secondary sits at preference 4.

When an external sending system looks up the domain, it sees the lower number first. It attempts the preference-2 host, retries according to its own delivery policy, and may stop before moving to the preference-4 host. The backup exists in DNS, but it isn't functioning as a backup in the way the operations team expects.

That distinction matters for deliverability. A record that exists isn't necessarily a record that will receive mail during an incident. Senders make their own decisions about retry timing, connection failure, and when to advance to another exchange.

The number controls routing order

RFC 974 defines an MX record as a preference value paired with a host name. The standard says the lowest-numbered MX is tried first, and records with the same preference can be treated as having the same priority.

That makes MX 2 versus MX 4 an operational decision, not a formatting preference. MX 2 wins the first delivery attempt. MX 4 becomes relevant only after the sender moves beyond the lower preference.

The impact extends to revenue. If prospect replies bounce, sales conversations stop. If transactional messages can't reach users, support volume rises and customers lose confidence. If a backup server handles mail unexpectedly, authentication, filtering, and reputation controls may not match the primary route.

Why a backup can still damage reputation

A secondary host that's rarely used may not have the same monitoring, authentication, queue handling, or abuse controls as the primary. During an outage, it can accept mail successfully while creating a separate operational problem. The business then has to reconcile messages across systems, investigate delayed delivery, and explain inconsistent filtering to users.

The safer approach is to treat every MX target as a production endpoint. It needs a current hostname, working mail service, appropriate authentication relationships, and a documented failover test. Lower preference means earlier responsibility, not merely a smaller number in a DNS panel.

What MX Priority Actually Means in DNS

An MX record contains two important pieces of routing data: a preference value and an exchange host name. The preference is an unsigned 16-bit value, so valid values run from 0 through 65,535, as described in the RFC 974 specification.

A conventional zone-file representation looks like this:

example.com. 3600 IN MX 10 mail1.example.com.

In a DNS management interface, the same record normally appears as separate fields:

Type: MX

Name: the domain or host

Priority: 10

Target: mail1.example.com

TTL: 3600

The preference number has one job. It orders MX targets before a sender attempts an SMTP connection. It doesn't describe bandwidth, server strength, geographic distance, queue size, or how much mail a host can process.

Don't confuse the fields

The TTL controls how long resolvers may cache the DNS answer. It isn't the delivery priority. The exchange host identifies the destination that the sender should contact. That host then needs to resolve correctly and accept mail.

The A or AAAA record behind the exchange hostname is another dependency. An MX target can look correct while its address record is stale, missing, or directed to the wrong service. DNS managers often show these records on separate screens, which is why a visual review of only the MX row isn't enough.

The value 0 is valid and has the strongest preference when compared with higher values. A record at 10 is preferred over one at 20, while MX 2 is preferred over MX 4. The exact size of the gap doesn't create extra reliability by itself.

A compact record anatomy

Field	Example value	Purpose
Type	MX	Identifies mail exchange routing
Preference	10	Determines delivery order
Exchange host	mail1.example.com.	Names the host a sender contacts
TTL	3600	Controls DNS caching duration

A missing MX record can also create confusion during migrations because mail systems may apply implicit handling rules when no explicit exchange is published. A migration should therefore verify the complete returned record set, not just the intended new entry.

How Senders Use the Preference Value to Route Mail

A sending mail transfer agent generally begins by requesting the recipient domain's MX records. It receives the available set, sorts the records by preference, and starts with the lowest-numbered exchange.

If that host accepts the connection and the recipient address, delivery proceeds there. If the connection fails, the sender follows its own retry and fallback behavior. It may retry the first host for a period of time before attempting the next higher preference. No single sender is required to use identical timeout values, so a DNS change cannot guarantee an immediate route switch.

Failover isn't active-active by default

Different preference values create an ordered failover path. They don't normally split ordinary traffic between the primary and backup. The lower-numbered host receives the normal delivery attempts, while the higher-numbered host waits for a condition that causes the sender to advance.

Equal preference values have a different purpose. Two MX 10 records can be treated as equivalent targets, allowing senders to distribute attempts through selection methods such as randomization or round-robin behavior. That is traffic distribution, not a primary-and-backup arrangement.

Cached DNS can delay the result

Resolvers can continue using a cached MX response until its TTL expires. Changing MX 2 to MX 4 therefore doesn't instantly reshuffle every sender's route. Some senders may have the new order while others still hold the previous answer.

That delay matters during an outage. A team can correct the zone and still see old delivery behavior for a while. The incident response plan should account for cached answers, queue retry behavior, and the possibility that different senders will transition at different times.

The quiet reputation problem

The primary endpoint handles normal traffic and accumulates the operational history associated with that route. The backup may remain untested until a failure forces it into service. If its filtering, authentication, queue policy, or abuse controls differ, the organization discovers the gap at the worst possible moment.

Priority 2 vs Priority 4 Compared

MX 2 and MX 4 have no inherent quality difference. The lower value wins the ordering decision. Their correct roles depend on what sits below them, what sits above them, and whether the organization has tested the entire path.

A preference-2 host can serve as a secondary behind MX 0 or MX 1. A preference-4 host can serve as a later fallback behind those routes. Neither value automatically means “primary,” “backup,” or “disaster recovery.”

Attribute	Priority 2	Priority 4
Preference	Tried before MX 4	Tried after MX 2 if the sender advances
Typical role	Early fallback or an ordered receiving endpoint	Later fallback or disaster-recovery route
Traffic share	Receives normal traffic if no lower value exists	Usually receives no normal traffic when a lower value is available
Operational risk	A stale target can block earlier delivery attempts	An untested target may fail when needed
Correct use	A reachable, monitored, authenticated host	A separately verified and authenticated backup

When MX 2 is the sensible choice

MX 2 makes sense when the endpoint should be reached before MX 4 but after a lower-numbered primary. It can also be the only explicit MX value in a simple configuration. The number is less important than the ordering and the ownership of the target.

A company shouldn't select MX 2 merely because it appears more “preferred” or more powerful. If the target is a retired host, the lower number increases the chance that senders spend time on the wrong route before considering the live server.

When MX 4 is the sensible choice

MX 4 works as a later fallback when the organization wants another route behind MX 2. It should not be used to create a false sense of redundancy. If the host doesn't accept the same recipient domains, preserve the relevant message flow, and apply equivalent controls, it isn't a dependable backup.

The same comparison discipline used for head-to-head Shopify tools applies here, although the technical object is different. The useful question isn't which number looks better. It's which route should receive the first attempt, which route should receive the next attempt, and whether both routes are operationally ready.

Recommended Configurations and Numbering Conventions

A readable numbering scheme helps during handovers and incident response. Many teams place the primary at a low value and leave room between successive records so a new route can be inserted without renumbering the entire set.

The following examples show the ordering principle without treating any number as mandatory:

A single route can use one MX record at a chosen preference.

A primary and secondary can use a lower value for the primary and a higher value for the secondary.

A three-tier design can use ascending values for primary, secondary, and disaster recovery.

Some organizations start at 10 because it has long been a familiar convention and leaves room below it. Others use 0 or 1 for the primary. RFC behavior doesn't make 10 more capable than 0. Only the relative order controls which record is preferred.

Keep the zone easy to audit

Naming should make ownership obvious. A target that belongs to the primary receiving service shouldn't look interchangeable with an emergency route managed by another team. Consistent names also reduce the chance that a migration leaves a retired host in the record set.

A practical review should confirm:

Ordering: The intended primary has the lowest preference.

Targets: Every exchange hostname resolves to the intended service.

Recipient handling: Each route knows which domains and addresses it should accept.

Authentication: The receiving architecture doesn't undermine SPF, DKIM, or DMARC decisions.

Failover: The secondary has been tested, not merely published.

Rollback: The previous route remains available long enough to support a controlled change.

For teams sending outbound campaigns, MX is only one part of the reputation picture. MailAdept's guidance on cold email deliverability is relevant because routing errors can compound with weak authentication and poor sending practices. A correctly ordered MX set can't repair a sender reputation problem created elsewhere.

Common MX Priority Mistakes and Their Deliverability Cost

The most expensive MX errors often look valid in a DNS editor. The record type is correct, the target is syntactically complete, and the domain publishes an answer. The failure appears only when a sender must choose a route or when the receiving system handles a message under pressure.

Swapped priorities

A backup receives the lower number and becomes the preferred destination. The organization may unknowingly send all inbound mail through a less monitored or less trusted endpoint.

Fix: Put the intended primary at the lower preference and confirm the returned order from outside the authoritative DNS environment.

Identical priorities used as fake failover

Two providers receive the same preference even though the team expects one to wait behind the other. Senders may distribute attempts across both targets, so traffic doesn't follow a predictable primary-first path.

Fix: Use equal values only when both hosts are intended to receive traffic, and use different values when the design requires ordered fallback.

A narrow numbering gap

A small numerical gap isn't automatically wrong, but teams often use it without documenting the reason. Later changes can create accidental ties, inverted ordering, or a confusing zone that nobody wants to edit during an outage.

Fix: Choose a consistent convention with room for future routes and document the intended order.

Decommissioned targets left published

An old MX target may remain in DNS after a provider migration. It might refuse connections, accept some recipients, or return inconsistent SMTP responses. Each behavior creates a different delivery outcome, from delayed retries to hard bounces and misrouted mail.

Fix: Remove retired records only after the migration plan accounts for cached DNS responses and pending queues.

Backups that weren't tested

A backup can resolve correctly and still reject mail, mishandle aliases, or lack the controls expected by the domain owner. During a primary outage, that gap becomes an inbox-placement and continuity issue.

Fix: Test acceptance, routing, authentication, logging, and recovery on every published fallback.

The correction process should use independent DNS queries, SMTP-level testing, and message-header review. A successful DNS lookup proves that a record is published. It doesn't prove that the recipient system accepts mail or that the message will avoid spam filtering.

Connecting MX Priority to Your Full Authentication Stack

MX priority controls where inbound mail goes, but it doesn't authenticate the sender by itself. SPF evaluates authorized sending infrastructure, DKIM validates a cryptographic signature, and DMARC evaluates alignment between the authenticated domains and the visible From domain.

A receiving environment can therefore have a sensible MX order and still create deliverability problems if its routing, filtering, and authentication policies disagree. A priority-2 endpoint that accepts mail should be monitored as part of the domain's reputation-bearing infrastructure. A priority-4 endpoint needs the same scrutiny, even if it normally receives little or no traffic.

A minimum review model

A practical authentication review includes:

SPF: Publish the authorized sending policy for the relevant domain.

DKIM: Publish the selector key expected by the sending system and verify signatures in received headers.

DMARC: Start with a reporting-oriented policy such as v=DMARC1; p=none; rua=mailto:dmarc@example.com, then use reports to identify alignment issues before enforcing a stricter policy.

MX routing: Confirm that every receiving target is intended, reachable, and governed by the same operational owner.

The example DMARC record is syntax, not a guarantee that the policy is correct for every domain. The correct reporting address, alignment mode, and enforcement decision depend on the organization's mail sources and ownership.

Teams can set up email authentication alongside MX validation, but tools alone won't establish whether a fallback behaves correctly during a real delivery event. A backup route that accepts mail without equivalent logging, filtering, and abuse controls can become a blind spot. The numbering should reflect a route the organization can defend.

Frequently Asked Questions About MX Priority

Is MX 0 functionally different from MX 10?

Only the relative ordering matters. MX 0 is preferred over MX 10, but MX 10 can be the primary if every other published MX value is higher. The number doesn't represent capacity or a quality score.

Does TTL change the effect of a priority update?

Yes. Resolvers can use a cached MX response until its TTL expires, so a priority change won't reach every sender immediately. A controlled migration lowers the TTL in advance, changes the records, verifies the result, and raises the TTL after the intended routing is visible.

Does every domain need a backup MX?

No. A backup is useful only when the provider supports the design and the organization has tested it. Publishing an unmaintained fallback adds complexity and can expose mail to a route that doesn't share the primary's controls.

What happens when two MX records share a priority?

They can be treated as equivalent delivery targets, with senders distributing attempts between them. That isn't the same as ordered failover. Equal values are appropriate only when both routes are prepared to receive normal traffic.

Can a priority change be reversed without downtime?

It can, provided the previous primary remains reachable while cached answers expire and senders transition. A rollback should verify both DNS visibility and actual SMTP acceptance rather than relying on the DNS editor alone.

The operating rule is simple: use the lowest number for the host whose reputation and reliability the organization owns, and use higher numbers only for tested, authenticated backups.

Still facing deliverability issues? Get a free deliverability audit from Mailadept. Its subscription-based consulting combines ongoing technical monitoring with human review of MX routing, SPF, DKIM, DMARC, and the delivery behavior that DNS records alone can't reveal.