MX Records Priority Explained for Reliable Email

Do not index

A customer completes onboarding, but the welcome email never arrives. A prospect replies to a cold campaign, yet the response disappears before the sales team sees it. Support tickets rise, transactional messages fail, and the team starts changing SPF, DKIM, and DMARC records even though the core problem is that inbound mail is reaching the wrong server.

That's where MX records priority matters. MX records control which receiving host a sender tries first, and whether another host is considered when the preferred route can't accept mail. They don't score spam, authenticate outbound messages, or guarantee inbox placement. They're one part of the email infrastructure that supports reliable delivery.

A useful Email Deliverability Best Practices process therefore separates inbound routing from sender authentication and reputation. A clear MX check can reveal a broken hostname, an inverted order, or a backup server that looks available in DNS but can't receive mail. The sections below show how to interpret the numbers, understand real SMTP fallback, and diagnose the issue with a full mailX audit instead of guessing.

Table of Contents

What MX Records Priority Really Means The primary and backup analogy What the number doesn't tell anyone How SMTP Uses Priority to Choose Mail Servers When the next MX is tried Equal priority is a pool, not a guarantee How to Set and Read MX Priorities Correctly A verification checklist What healthy output means Real Configuration Examples for Failover and Load Sharing Ordered failover Shared primary traffic Choosing between the patterns Common MX Priority Mistakes That Break Delivery Inverting the order Pointing to an IP address Trusting a dead backup Expecting fallback after every rejection Trying to repair spam placement with MX Check Priority Without Hurting Deliverability A safer diagnostic sequence

What MX Records Priority Really Means

An MX record, or Mail Exchange record, tells sending mail servers which hostname accepts email for a domain. Each record contains a target hostname and a numeric preference value. That preference value is commonly called MX priority, although it describes routing order rather than server quality.

The field is an unsigned 16-bit value, so valid values range from 0 through 65,535, as defined in the early DNS and SMTP standards, including RFC 5321. The important rule is easy to remember once the unusual numbering is clear:

For example:

10 mx-primary.example
20 mx-backup.example

The sender tries mx-primary.example before mx-backup.example. A host assigned 0 is preferred over both. The number doesn't mean that the server is faster, safer, closer, more reputable, or more likely to reach the inbox. It only establishes relative selection order.

The primary and backup analogy

A domain can publish one receiving host as the preferred route and another as a fallback. That arrangement is useful when the preferred host becomes unreachable or can't accept a connection. It creates an intended path for inbound traffic, but the backup still needs to handle the same recipients and operate correctly.

An MX target must be a hostname, not a literal IP address. That hostname must independently resolve to usable address records before an SMTP sender can connect. A record can therefore look syntactically plausible while still failing operationally.

What the number doesn't tell anyone

MX priority is an infrastructure setting, not a deliverability score. Changing 20 to 10 changes which host is attempted first. It doesn't improve SPF authorization, DKIM signing, DMARC alignment, blacklist status, sender reputation, or spam placement.

That distinction prevents a common troubleshooting mistake. If outbound emails go to spam, changing inbound MX order won't repair the underlying authentication or reputation problem. If inbound emails disappear, checking SPF alone won't prove that the receiving route works.

How SMTP Uses Priority to Choose Mail Servers

SMTP selection starts with a DNS query for every MX record published at the recipient domain. The sending system sorts those records by preference, beginning with the lowest numeric value, then attempts delivery against the lowest-preference group available.

Consider these three patterns:

One record: The sender has one declared destination, so that host carries the inbound route.

Ordered records: A host at priority 10 is attempted before a host at priority 20.

Equal records: Hosts with the same preference form a group that can share traffic rather than create a fixed sequence.

The target hostname also matters. A sender needs to resolve the MX hostname to usable address records and then establish an SMTP connection. If the lowest-numbered target doesn't resolve, is unreachable, or can't accept the connection, the numeric order alone won't make delivery healthy.

When the next MX is tried

Higher numeric values represent fallback status, not greater priority. A sender may proceed to the next value when the preferred host is unavailable or delivery can't proceed, but fallback isn't a universal response to every error.

A connection refusal, timeout, or temporary SMTP problem can lead the sender to try another exchanger or retry later. A reachable server that returns a permanent 5xx rejection may stop delivery for that message instead of causing the sender to move automatically to the next MX. The exact behavior depends on the sending system and the response it receives.

That's why a backup test needs more than a DNS lookup. It should distinguish among:

DNS resolution failure.

TCP connection failure.

A timeout.

A temporary 4xx SMTP response.

A permanent 5xx SMTP response.

Successful connection but recipient rejection.

Equal priority is a pool, not a guarantee

Equal-preference records allow senders to select among alternatives. RFC-oriented behavior requires randomization among same-priority exchangers, which supports traffic distribution. It doesn't promise perfectly even load, identical connection paths, synchronized queues, or consistent filtering.

Teams should use equal priority only when the participating servers are operationally equivalent. Each should accept the same recipient domains, apply compatible policy, support the required transport security, and remain reachable across the relevant network paths.

For teams reviewing outbound infrastructure or an SMTP Relay, this distinction is important. MX records describe where inbound mail should go. They don't turn a receiving host into an authorized outbound sender, and they don't repair an authentication failure.

How to Set and Read MX Priorities Correctly

A healthy configuration has two properties: the records express the intended order, and every declared target works as an actual mail server. A DNS panel may accept a record that is formally entered but operationally useless, so verification should continue after publication.

A practical example looks like this:

10 mx-primary.example
20 mx-backup.example

The target names are hostnames, the lower value identifies the preferred route, and the higher value identifies the fallback route. The specific gap between the values doesn't matter. Their relative order does.

A verification checklist

Confirm the target format: Each MX exchange should be a hostname, never a literal IP address.

Resolve every target: Check that each hostname has usable address records.

Read the order numerically: The lowest value should match the intended primary receiving host.

Test SMTP reachability: A preferred target must accept connections from outside the local network.

Check recipient handling: A backup isn't useful if it can't accept the same addresses as the primary.

Review the DNS response: Confirm that public resolvers return the records the domain owner intended.

Allow for caching: A change may not appear everywhere immediately because resolvers cache DNS responses according to TTL settings.

What healthy output means

A healthy lookup shows valid hostnames, the intended preference order, and targets that resolve consistently. A healthy SMTP test then confirms that the host responds and handles recipients according to the domain's architecture.

A lookup that shows 10 and 20 proves only that the order is published. It doesn't prove that the priority-10 host accepts mail, that the priority-20 host can take over, or that the receiving system's policy is consistent across both servers.

Teams can also check MX records with nslookup when debugging from a terminal. For nontechnical users, a live MX lookup provides the same initial visibility in a more readable format. The result should always be interpreted alongside resolution and SMTP connectivity, not as a standalone deliverability verdict.

Real Configuration Examples for Failover and Load Sharing

The right pattern depends on the operational goal. Ordered priorities create a preferred route and a fallback route. Equal priorities create a group of alternatives that can share traffic. Both can be valid, but they solve different problems.

Pattern	Example	Best for	Risk if misused
Single route	`10 mx-primary.example`	A simple architecture with one receiving host	One declared destination leaves no alternate route in DNS
Ordered failover	`10 mx-primary.example`, `20 mx-backup.example`	Keeping normal traffic on one host while reserving another for fallback	The backup may not accept the same recipients or may be unreachable
Shared primary with backup	`10 mx1.example`, `10 mx2.example`, `20 mx3.example`	Distributing primary traffic while retaining a separate fallback	Equal hosts may have different policies, capacity, or filtering behavior
Equal alternatives only	`10 mx1.example`, `10 mx2.example`	Two operationally equivalent receiving hosts	Equal priority doesn't guarantee balanced traffic or active-active reliability

Ordered failover

The 10 and 20 pattern is appropriate when one system should receive normal traffic and another should be reserved for an outage path. The higher value doesn't make the backup less trustworthy. It tells senders to try it after the lower-preference group can't accept delivery.

The backup must be more than a server that answers a network connection. It needs compatible mailbox or relay handling, recipient coverage, transport security, and policy configuration. Otherwise, the domain has a fallback record without a dependable fallback service.

Shared primary traffic

The 10, 10, and 20 pattern has a different intent. The two priority-10 hosts form the primary group, while the priority-20 host remains outside that group until the primary options can't accept delivery.

This can support distribution, but teams should monitor each host independently. Different senders may randomize differently, address-family reachability may vary, and one server may have a problem hidden by the apparent health of the group.

Choosing between the patterns

Teams seeking disaster recovery should start with ordered priorities and test the actual failure behavior. Teams seeking traffic distribution should use equal priorities only after confirming that every equal-priority host can handle the same workload and recipients.

Neither arrangement improves outbound inbox placement by itself. A domain can route inbound mail correctly while outbound messages still fail authentication, encounter reputation problems, or land in spam.

Common MX Priority Mistakes That Break Delivery

Many MX incidents come from treating the number as a quality rating or assuming that any second record guarantees failover. The safest diagnosis starts with the failure type, then checks whether the DNS record, hostname, network path, and SMTP response match the intended design.

Inverting the order

A team may assign 20 to the intended primary server and 10 to the backup. The backup then becomes the first target, which can create unexpected routing, policy differences, or mailbox gaps.

Fix: Write down the intended path before editing DNS. The preferred host gets the lower value, and the fallback receives the higher value.

Pointing to an IP address

An MX exchange must be a hostname. An IP address in the target field violates the expected record structure and can prevent senders from resolving the route correctly.

Fix: Publish the mail hostname as the MX target, then ensure that hostname resolves through its own address records.

Trusting a dead backup

A backup record can exist for months without anyone testing it. When the primary fails, the backup may lack recipient data, network access, TLS configuration, or the ability to accept mail.

Fix: Check every target independently. Confirm DNS resolution, SMTP connectivity, recipient acceptance, and operational parity.

Expecting fallback after every rejection

A reachable primary that returns a permanent 5xx response may cause the sender to stop delivery instead of trying the next MX. Changing the priority number won't convert a permanent policy rejection into a temporary connectivity failure.

Fix: Capture the SMTP response and classify it before changing DNS. A timeout, connection failure, temporary 4xx response, and permanent 5xx response require different remedies.

Trying to repair spam placement with MX

MX priority controls inbound host selection. It doesn't authenticate outbound mail or establish sender reputation, so it can't fix missing SPF, invalid DKIM, misaligned DMARC, or blacklist problems.

Fix: Keep the routing layer separate from the authentication and reputation layers. A full diagnostic should inspect each one.

Check Priority Without Hurting Deliverability

MX priority belongs at the inbound-routing layer of a larger deliverability system. It helps a sending system find the right receiving host, but it doesn't prove that outbound messages are authenticated or trusted by mailbox providers.

Google's sender guidance says that senders to personal Gmail accounts must configure SPF or DKIM. For bulk senders, defined there as more than 5,000 messages per day, Google requires SPF, DKIM, and DMARC. Google's sender requirements also explain that DMARC passes when SPF or DKIM authenticates and the authenticating domain aligns with the domain in the visible From header.

A safer diagnostic sequence

Inspect MX records: Confirm the targets are hostnames and that the preference order matches the intended architecture.

Resolve each target: Check that every declared mail host returns usable address records.

Test SMTP connectivity: Determine whether the preferred and fallback hosts accept connections.

Classify failures: Separate DNS errors, timeouts, connection failures, temporary SMTP responses, and permanent rejections.

Check SPF: Confirm that authorized outbound senders are represented correctly.

Check DKIM: Verify that messages are signed and that the selector resolves.

Check DMARC: Review policy, authentication results, and alignment with the visible From domain.

Review reputation signals: Check blacklist status, sending infrastructure, and behavior that may affect spam filtering.

Run a full audit: Combine the findings into a prioritized remediation list rather than treating one green DNS result as proof of deliverability.

A live diagnostic layer makes this workflow faster for both technical and nontechnical teams. mailX checks DNS, MX, SPF, DKIM, DMARC, BIMI, SMTP and IMAP connectivity, blacklist status, domain configuration, and related infrastructure, then returns plain-English explanations with remediation steps. Its web tools, API, and MCP interface also give developers and AI agents a way to inspect deliverability conditions before an automated workflow sends mail.

AI agents can draft campaigns, operate follow-up sequences, and monitor domains, but they shouldn't send blindly. Before launch, an agent should verify authentication, MX health, blacklist status, and infrastructure reachability, then flag unresolved risks for a human or a remediation workflow.

The core rule remains simple: lower MX preference values are tried first, equal values form a shared group, and fallback depends on the receiving outcome rather than the number alone. Correct routing improves the chances that inbound messages reach the intended infrastructure, while SPF, DKIM, DMARC, reputation, and blacklist checks determine whether outbound mail receives fair treatment in the inbox.

mailX provides free live checks for MX priority, DNS resolution, authentication, blacklist status, and SMTP or IMAP connectivity, with clear explanations instead of raw records. Visit mailX to run a deliverability audit, identify the routing or authentication issue, and get the next practical fix.