How MX Record Priority Controls Your Email Routing in 2026

When an email leaves a sending server headed for your domain, the first thing the remote mail transfer agent does is look up your MX records. It gets back a list — potentially several entries, each with a number beside it. That number is the priority field, and getting it wrong causes delayed delivery, bounced messages, or mail silently flowing to a backup server you forgot was still active. Here is exactly how MX priority works, where configurations fail, and how to verify everything is correct in 2026.

What the MX Priority Number Actually Means

The MX (Mail Exchanger) record has two required fields: the preference value (the priority number) and the hostname of the mail server. The preference value is an integer from 0 to 65535. Lower numbers mean higher priority. When a sending MTA resolves your domain's MX records, it sorts them ascending by preference value and attempts delivery to the lowest-numbered host first.

This behavior is defined in RFC 5321, which governs SMTP delivery. The field name in the original DNS specification is PREFERENCE — not priority — which is why some DNS panels label it differently. Regardless of the label used, lower means preferred.

Common preference values you will encounter:

• 0 — Highest possible. Used by Microsoft 365 by default and by some providers like Proofpoint to force a specific inbound path.
• 1 or 5 — Primary server in most Google Workspace configurations.
• 10 — Very common primary value on cPanel hosts and self-managed mail servers.
• 20 or 30 — Typical secondary or backup MX.
• 50 or 100 — Tertiary fallback or spam trap.

The absolute numbers do not matter in isolation — only their relative ranking does. A setup with priorities 10 and 20 behaves identically to one using 1 and 2 or 100 and 200. Only the relationship between values determines routing order.

How Sending Mail Servers Use Priority During Delivery

When a remote MTA sends to user@yourdomain.com, the delivery sequence is:

1. The sending MTA queries DNS for all MX records at yourdomain.com.
2. DNS returns the full list with all preference values.
3. The MTA sorts the list ascending by preference value — lowest first.
4. It attempts an SMTP connection to the first hostname in that sorted list.
5. If that host is unreachable, refuses the connection, or returns a 4xx temporary failure, the MTA falls back to the next record in the sorted list.
6. If two or more records share the same preference value, the sending MTA selects among them at random — providing load balancing, not failover.

Step 6 is where many configurations break silently. Administrators who want primary/backup failover set both records to the same priority, then wonder why mail is hitting the backup server under normal conditions. True failover requires strictly different preference values — the backup must have a higher number than the primary.

Real-World MX Priority Configurations

Google Workspace

Google requires five MX records with specific hostnames and preference values of 1, 5, 5, 10, and 10. The two records at priority 5 (alt1 and alt2) are load-balanced intake servers. The two at priority 10 (alt3 and alt4) are load-balanced secondaries. Priority 1 (aspmx.l.google.com) is the primary intake host. A correct dig output looks like this:

Microsoft 365 / Exchange Online

Microsoft 365 uses a single MX record — yourdomain-com.mail.protection.outlook.com — with a priority Microsoft's setup wizard sets to 0. There is intentionally no backup MX because Microsoft's infrastructure handles redundancy internally. Adding a secondary MX pointing elsewhere creates a bypass vector: spammers actively probe for higher-number (lower-priority) MX records that skip your Exchange Online filtering layer.

cPanel and DirectAdmin Shared Hosting

Shared hosting providers typically set a single MX record at priority 0 or 10 pointing directly to the server. If you add a third-party spam filter (Proofpoint, SpamExperts, MXGuardDog) in front, set the filter's MX hostname at a lower number than any direct-to-server record — or remove the direct record entirely. Leaving a direct-to-server record as an accessible MX allows spammers to bypass your filter by targeting the higher-numbered (lower-preference) direct path.

Genuine Backup MX

A true backup MX queues mail when your primary is down. Correct setup: primary at priority 10, backup server at priority 20. When the primary is unreachable, senders queue at priority 20 and the backup forwards queued mail when the primary recovers. A common mistake is pointing the backup hostname to a second IP on the same physical server — when the server goes down, both MX records fail simultaneously. Real redundancy requires a separate server on separate infrastructure in a different network location.

Configuring MX Records in Popular DNS Panels

Cloudflare

Log in to the Cloudflare dashboard, select your domain, go to DNS, then Records, then Add record. Set type to MX, enter @ in the Name field, enter the mail server hostname in Mail server, and enter the preference number in Priority. TTL: Auto. Cloudflare does not proxy MX records — the orange cloud toggle is greyed out and irrelevant for MX entries.

cPanel Zone Editor

Log into cPanel, go to Zone Editor, click Manage next to your domain, locate existing MX entries, and edit or add a record. The Priority field is the preference value. Alternatively use cPanel's Email section, then MX Entry, for a guided interface that configures both the DNS zone record and Exim's local delivery rules simultaneously. Use Zone Editor directly when pointing to external mail (Google, Microsoft, Zoho) and you do not want cPanel's mail system processing the traffic.

Amazon Route 53

AWS Console, Route 53, Hosted Zones, your domain, Create Record. Select type MX. In the Value field, each line uses the format priority hostname. with a trailing dot on the hostname. Multiple MX records for the same domain go as multiple lines in a single record set — not as separate records:

Namecheap Advanced DNS

Namecheap Dashboard, Domain List, Manage, Advanced DNS, Add New Record, MX Record. Host: @ for root domain. Value: the mail server hostname without a trailing dot — Namecheap appends it. Priority: the preference number. TTL: Automatic defaults to 1800 seconds.

GoDaddy DNS Manager

My Products, DNS, your domain, scroll to MX section, Edit. Each row shows the mail server hostname and a Priority column. Note that GoDaddy's DNS interface propagates slowly — changes may take 20–30 minutes to appear externally even when the displayed TTL is set lower.

Verifying MX Records from the Command Line

Never rely solely on the DNS panel's confirmation. Verify externally using the tools below to see what the rest of the internet actually sees.

dig (Linux and macOS)

The +short flag returns one line per record showing priority and hostname. The full output without +short includes the TTL in seconds — divide by 60 to know how many minutes remain before the old cached record expires and new values take effect.

nslookup (Windows, macOS, Linux)

Windows nslookup labels the field preference rather than priority — same value, different label. The output may not be sorted by preference order, so read the numbers explicitly rather than assuming the first entry is the primary.

resolvectl (systemd Linux: Ubuntu 20.04+, Fedora, Debian 11+)

PowerShell (Windows)

PowerShell output includes a Preference column showing the priority value and an Exchange column showing the mail server hostname. This is the cleanest Windows MX verification option compared to nslookup.

Mobile and Browser-Based Verification

iOS and Android lack built-in DNS query tools. Use the DNS Lookup tool from any browser — it queries from the server side, bypassing your local resolver cache and any DNS-over-HTTPS settings on the device, giving a clean external view of current MX records without needing any app installed.

Common MX Priority Mistakes

Mistaking Higher Number for Higher Priority

This is the most frequent error by a wide margin. An admin sets the primary mail server to priority 100 and a backup to priority 10, reasoning that 100 means most important. All mail routes to the backup. The fix is simple: the primary must have the lower number. Set primary to 10, backup to 20 — or any pair where primary is numerically smaller.

Ghost MX Records After Migration

You migrate from shared hosting to Google Workspace. You add all five Google MX records but do not delete the old record pointing to the cPanel server. Now you have six MX records. If the old cPanel entry carries a low preference number, a significant fraction of inbound mail still flows there — into a mailbox nobody checks. Always audit the complete MX record list before and after every provider migration. Delete every record that no longer belongs.

Equal Priorities for Primary and Backup

Setting both a primary server and backup to priority 10 produces 50/50 random distribution between them — not failover. Senders treat equal-priority MX records as a load-balancing pool and select randomly. For genuine failover, use different numbers: 10 for primary, 20 for backup.

Backup MX on the Same Physical Server

Two MX hostnames resolving to the same IP address provide zero redundancy. A server outage makes both records unreachable simultaneously. A real backup MX requires a physically separate server on separate infrastructure, ideally in a different datacenter or with a different upstream provider.

High TTL at the Start of a Migration

Starting an MX migration when the TTL is 86400 (24 hours) means old records persist globally for up to a full day. Standard practice: lower the TTL to 300 seconds at least 24 hours before a planned migration, make the record changes, confirm delivery is clean, then raise the TTL back to 3600 or higher.

MX Priority in 2026: IPv6, DNSSEC, and DoH

IPv6 Delivery Paths

An MX hostname must resolve to an IP — either an A record (IPv4) or AAAA record (IPv6). Dual-stack sending servers attempt the AAAA record first. If your mail server has an AAAA record published but is not actually listening on IPv6, connection attempts will time out before falling back to IPv4, adding 30–60 second delays to every inbound delivery attempt. Verify with:

If your mail server does not support IPv6, remove any AAAA record for the MX hostname. Do not leave an AAAA record pointing at an address that does not have port 25 open.

DNSSEC and MX Record Protection

DNSSEC cryptographically signs your DNS zone, including MX records. Without DNSSEC, a successful DNS cache poisoning attack could redirect your domain's MX records to an attacker's server, silently intercepting all inbound email. With DNSSEC, validating resolvers reject any forged MX response that does not carry a valid signature. In 2026, DNSSEC adoption for .com and .net zones exceeds 60% and most major registrars — Cloudflare, Namecheap, GoDaddy, Route 53 — support DS record submission. If you have not enabled DNSSEC, enabling it is the single highest-impact DNS security step available for protecting your email routing.

DNS over HTTPS and MX Lookups

DoH and DoT encrypt DNS queries in transit. Sending MTAs use standard UDP/TCP port 53 for MX queries — they do not use DoH — so this does not affect actual delivery routing. It does affect verification tooling on managed or corporate networks that intercept port 53 traffic. If your dig or nslookup commands return empty or suspicious results, your network may be intercepting the query. Use the DoH JSON API to bypass it and get a clean external view:

Confirming the Fix Worked

After changing MX records and waiting for the previous TTL to expire, verify from multiple external resolvers — not just your own local DNS, which may still be caching old values:

• dig MX yourdomain.com @1.1.1.1 +short — Cloudflare resolver
• dig MX yourdomain.com @8.8.8.8 +short — Google resolver
• dig MX yourdomain.com @9.9.9.9 +short — Quad9 resolver

Then send a test email from an external account (Gmail or Outlook) to your domain. Inspect the full headers of the received message — the Received: header chain is ground truth. It shows which mail server actually accepted the connection and at what timestamp. If the wrong server appears in those headers, you have a stale cache, a misconfigured TTL, or a ghost MX record still in your zone.

Preventing Recurrence

• Document your complete MX configuration — all records and all priority values — before any DNS migration or hosting panel transfer.
• Schedule a quarterly DNS audit. Hosting panel transfers and domain renewals can silently reset or duplicate records without notification.
• Lower TTL proactively 24 hours before any planned MX change. Raise it back after confirming clean delivery.
• If using an inline spam filter, ensure no direct-to-mail-server MX record is reachable from the public internet. Either remove it or firewall port 25 to accept connections only from your filter's published IP ranges.
• Enable DNSSEC at your registrar to protect against MX record hijacking via cache poisoning.
• When a mail provider support ticket references an MX issue, audit all your MX records — not just the one they mention. Migrated domains routinely carry stale entries from previous providers that were never cleaned up.