MX Record Priority Explained: Lower Numbers Win

MX priority is backwards on purpose

One wrong MX number can send new sales replies to an old mail server while the real inbox sits empty.

An MX record tells the internet which server accepts email for a domain. The priority value tells sending servers which MX host to try first. The lowest number wins. A record with priority 1 is tried before priority 10. A record with priority 0 is even higher priority than 1.

That feels backwards because people read bigger numbers as higher rank. Email uses the number like distance. Smaller means closer. RFC 5321 says SMTP senders sort MX records by preference, with the lowest-numbered records most preferred.

Example:

• example.com MX 1 primary.mail.example is tried first.
• example.com MX 5 backup1.mail.example is tried if the first level is unavailable.
• example.com MX 10 backup2.mail.example is a later fallback.

If two MX records have the same priority, they are equal. A sending server should choose among the equal-preference hosts in a way that spreads load. That is how some providers balance inbound mail across several hosts.

How sending servers choose an MX host

MX priority controls the first connection attempt. It does not make a slow server faster or repair a broken mailbox.

When someone sends mail to you, their mail server asks DNS for your domain's MX records. It sorts the answers from lowest priority number to highest. Then it tries to open an SMTP connection to one host in the best available priority group. If that host cannot be reached, it tries another host at the same priority or moves to the next priority group.

That fallback is for outages. It is not a routing rule for certain users, campaigns, or departments. MX does not send marketing mail one way and support mail another way. It also does not control outbound email. SPF, DKIM, and DMARC handle sender authentication for mail you send.

Common setup patterns:

• One provider, one MX record. Simple domains often use this.
• One provider, several MX records. Older Google Workspace setups often used several Google MX hosts for redundancy; current provider instructions may be different, so follow your admin console.
• Equal priority records. These share inbound load at the same preference level.
• Higher-numbered backup MX. This accepts mail only when lower-numbered hosts are unreachable.

Avoid mixing two mailbox providers unless you know exactly why. Publishing Google and Microsoft 365 MX records together usually means some inbound mail lands at one provider and some lands at the other. That looks random to users, but DNS is doing what you told it to do.

Priority mistakes that break delivery

Most MX failures are boring DNS mistakes. Boring mistakes still lose mail.

• Using a higher number for the primary host. If your primary is priority 20 and an old backup is priority 10, the old backup gets the first try.
• Leaving stale MX records after a migration. Mail may keep reaching the old provider.
• Pointing an MX target at a CNAME. MX targets should name hosts that have address records.
• Publishing a backup MX that accepts mail but cannot forward it to the real mailbox.
• Using equal priority when you meant failover. Equal numbers tell senders the hosts are peers.
• Expecting MX priority to fix spam placement. It only routes inbound mail.

DNS TTL also matters during a change. If the old MX answer is cached, some senders may keep using it until the TTL expires. Plan mailbox moves during a quiet window and keep the old provider able to receive mail until the change has settled.

MX is only one part of inbox placement

A perfect MX record can receive mail, but it does not prove your outbound mail is trusted.

Mailbox providers such as Gmail and Outlook look at authentication, reputation, user complaints, message content, engagement, and infrastructure. If your domain is missing authentication, they may place mail in spam or reject it.

SPF is a TXT record that lists which hosts may send using a domain in the SMTP envelope. Use only one SPF record for each sending domain. End it with ~all while you are still testing, or -all when you are sure every real sender is covered. Keep SPF under the 10 DNS-lookup limit in RFC 7208. Too many include, a, mx, exists, or redirect lookups can cause SPF permerror.

DKIM signs outgoing mail with a private key at your mail provider. Receivers verify it with a public DNS record under a selector, such as selector1._domainkey.example.com. If you move providers, make sure the new provider signs mail and that its selector records are published. The base DKIM rules are in RFC 6376.

DMARC checks whether the visible From domain aligns with a passing SPF or DKIM result. It also tells receivers what policy to apply when DMARC fails. Start with p=none so you can watch reports. Move to p=quarantine or p=reject after SPF or DKIM is passing and aligned for all real senders. Add a rua address so aggregate reports show who is sending as your domain. DMARC is defined in RFC 7489. If those XML reports are hard to read, use the free DMARC report reader.

Blocklists still matter, especially after a compromised account or bad list import. Check them after authentication, because many spam problems start with broken SPF, DKIM, or DMARC. A quick domain scorecard can show your live MX, SPF, DKIM, and DMARC state in one pass.

What to check before changing MX records

Treat MX changes like a mailbox migration, even when the edit looks small.

• Confirm the exact MX hostnames from your email provider.
• Remove old provider records unless the provider says to keep them.
• Set priorities exactly as documented. Lower number means higher preference.
• Keep equal priority only for hosts that are meant to share traffic.
• Verify every MX target resolves to A or AAAA records.
• Test inbound mail from Gmail, Outlook, and a third provider after DNS changes.
• Check SPF, DKIM, and DMARC after the change, because mailbox migrations often break outbound authentication.

Do not copy another domain's MX values. Providers use different hostnames, priorities, and regional routing. Use your own provider's admin screen as the source of truth.

A separate SEO check: AI search crawlability

MX records route email. Robots.txt controls which crawlers your website says may read pages.

If your deliverability guide, docs, or pricing page should appear in AI answers, check the crawler rules separately from DNS. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

Separate training and opt-out controls are GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a site's stated policy, not proof of crawler behavior. Perplexity-User and Bytespider have been reported to ignore it, so use logs carefully and avoid claiming a bot did something unless you can prove it from your own data. Only Googlebot documents JavaScript rendering. If key content exists only after client-side JavaScript runs, treat that as a risk for other AI crawlers. The safer pattern is server-rendered HTML. You can test the public page with the free AI visibility checker and compare related guidance at InboxRadar guides.