MX Priority Explained

An MX record has two parts: a 16-bit preference value and the hostname of a mail server. The preference is not a weight, a percentage, or a quality score — it is purely an ordering. RFC 5321 defines the behaviour precisely: a sender collects all MX records for the domain, sorts them by preference ascending, and tries them in that order, falling through to the next only when delivery to the current one fails at the connection level.

dig +short gmail.com MX

# 5   gmail-smtp-in.l.google.com.
# 10  alt1.gmail-smtp-in.l.google.com.
# 20  alt2.gmail-smtp-in.l.google.com.
# 30  alt3.gmail-smtp-in.l.google.com.
# 40  alt4.gmail-smtp-in.l.google.com.

That last point catches people out constantly. dig +short prints records in whatever order the nameserver returned them, which is frequently shuffled. The record listed first is not the one that gets tried first — the record with the *lowest number* is. Use the MX Lookup if you want them presented in the order a sending server would actually use them.

How does a sending server actually choose?

1. Look up MX records for the recipient domain.
2. If there are none, fall back to the domain's A or AAAA record and deliver there — the "implicit MX" rule. This is why mail sometimes lands on a web server that was never meant to receive it.
3. Sort the MX records by preference, lowest first. Group records that share a preference value.
4. Within each group, try the hosts in random order so load spreads evenly across equal-preference servers.
5. Connect to the first host. If the connection fails — refused, timed out, no route, or the TLS handshake collapses — move to the next host in the list.
6. If a host *accepts* the connection and then rejects the message with a permanent error (5xx), stop. The message bounces. Higher-preference records are not tried, because the domain's mail system has given an answer.
7. If a host answers with a temporary error (4xx), the sender queues the message and retries later, typically starting the whole MX selection over on the next attempt.

How do you read the numbers?

The values are unsigned 16-bit integers — 0 through 65535 — and only their relative order carries meaning. 1, 2, 3 behaves exactly like 10, 20, 30, which behaves exactly like 5, 500, 5000. The convention of stepping in tens exists only so you can insert a server between two existing ones later without renumbering everything.

The single-record pattern is worth noting because it looks wrong to anyone trained on the 10/20/30 convention. A provider running a global anycast mail fleet does its own failover inside one hostname, so a second MX would add nothing. google.com itself publishes one record, 10 smtp.google.com.; Microsoft 365 tenants publish a single 10 <tenant>.mail.protection.outlook.com.. Check your provider's current documentation for the exact hostname before publishing, and verify with the MX Lookup afterwards.

The backup MX that makes things worse

The classic mistake is adding a second MX at a higher number "for redundancy" without configuring that host to relay for your domain. It fails in one of two ways, and both are worse than having no backup at all.

• The backup rejects the mail. It has no idea it is supposed to accept @example.com, so it answers 550 relay not permitted. Because that is a permanent rejection from a host that accepted the connection, the sender bounces the message immediately. Without the backup record, the sender would simply have queued and retried until the primary came back.
• The backup accepts the mail and cannot deliver it. It queues messages for a destination it has no route to. They sit until the queue lifetime expires — often days — and then bounce, long after the primary recovered. Meanwhile the sender was told delivery succeeded.
• The backup becomes a spam target. Sending directly to the highest-numbered MX is an old spammer habit, on the assumption that backup hosts run weaker filtering. If your backup does not apply the same filtering and recipient verification as the primary, it becomes the soft way in.
• Backscatter. A backup that accepts mail for nonexistent recipients and only discovers this when relaying will generate bounces to forged senders, which is a fast route onto blocklists. Check yours with the Email Blacklist Check.

A backup MX is only worth having if it genuinely stores and forwards for your domain, knows your valid recipients, and filters as aggressively as the primary. If it does not, remove it — sending servers already retry for days on their own, which is exactly the resilience a backup was meant to provide.

Rules that make an MX record invalid

• The target must not be a CNAME. RFC 2181 section 10.3 requires the MX exchange field to name a host with address records. Pointing MX at an alias produces inconsistent behaviour across senders — some deliver, some refuse. See CNAME vs A Record.
• The target must not be an IP address. MX 10 203.0.113.10 is malformed. Create a hostname with an A record and point the MX at that.
• The target must resolve. An MX pointing at a hostname with no address record is a dead end; senders will fall through or bounce.
• Duplicate preferences are legal, duplicate records are not useful. Two identical MX records for the same host at the same preference are redundant, not doubled capacity.
• A null MX must stand alone. MX 0 . declares the domain accepts no mail and must be the only MX record present.

# Verify each MX target is a real host, not an alias
for h in $(dig +short example.com MX | awk '{print $2}'); do
  echo "== $h"
  dig +short "$h" A
  dig +short "$h" CNAME    # any output here means the MX is invalid
done

Priority is not deliverability

MX records govern mail coming *in*. They have no effect on whether your outbound mail is accepted, which is decided by SPF, DKIM, DMARC, and your sending IP's reputation. The major mailbox providers expect bulk senders to publish SPF and DKIM with DMARC alignment, to have valid reverse DNS on the sending IP, to offer one-click unsubscribe on bulk mail, and to keep spam complaint rates low. None of that is influenced by an MX preference number.

Check the outbound side separately: SPF Checker, DKIM Checker, DMARC Checker, and Reverse DNS Lookup for the PTR record. The Email Deliverability Test runs all of them at once. If your mail broke immediately after a DNS change rather than gradually, start with Mail Bouncing After a DNS Change?.

When you do change MX records, treat the cutover carefully. Sending servers cache MX answers for the record TTL, and a queued message may not retry for hours — so keep the old mail host accepting and forwarding for days after the switch. The lead-in procedure is in Lower Your TTL Before a DNS Migration.