MX Record Priority

MX record priority values determine which mail servers receive email and in what order. The system uses inverse numbering—lower numbers are tried first—which seems backwards until you understand what the number actually represents.

The Queue Position Mental Model

Forget "priority" as importance. Think of it as queue position.

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.
example.com.    IN  MX  30  mail3.example.com.

Priority 10 means "I'm 10th in line." Priority 20 means "I'm 20th in line." When the line starts at 10, being 10th means you're first.

Sending servers work through the queue in order:

1. Try mail1.example.com (position 10—first in line)
2. If that fails, try mail2.example.com (position 20)
3. If that fails, try mail3.example.com (position 30)

This design has a practical benefit: if you later need a server tried before mail1, assign it position 5. No renumbering required.

Common Configurations

Single server:

example.com.    IN  MX  10  mail.example.com.

Primary with backup:

example.com.    IN  MX  10  primary.example.com.
example.com.    IN  MX  20  backup.example.com.

The backup only receives mail when the primary is unreachable.

Load balanced cluster:

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  10  mail2.example.com.
example.com.    IN  MX  10  mail3.example.com.

All three share the same queue position. This triggers special behavior.

Tiered load balancing with failover:

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  10  mail2.example.com.
example.com.    IN  MX  20  backup1.example.com.
example.com.    IN  MX  20  backup2.example.com.

Two primaries share load. If both fail, two backups share the load.

Load Balancing Through Chaos

When multiple servers share the same priority, something elegant happens.

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  10  mail2.example.com.

Each sending server independently picks one at random. No coordination. No central load balancer. Just a million senders, each flipping a coin.

The result? Your mail distributes roughly evenly between mail1 and mail2. Emergent order from randomness.

This is receiver-side load balancing. You control it entirely through your MX records. Senders don't even know they're participating—they're just following the RFC.

When Failover Actually Happens

Sending servers don't failover on every error. The type of failure matters:

Connection failures → immediate failover: Server doesn't respond, connection times out, connection refused. The sending server immediately tries the next option.

Temporary SMTP errors → queue and retry: Server responds with 4xx codes (mailbox full, greylisting, try again later). The sending server queues the message and retries the same priority level later. It doesn't jump to backups.

Permanent SMTP errors → bounce or try next: Server responds with 5xx codes (user doesn't exist, message rejected). The sending server may try other servers at the same priority or generate a bounce.

This means backup MX servers primarily handle unreachable primaries, not overloaded ones. A primary returning "try again later" keeps receiving retry attempts.

Priority Gaps Are Conventional, Not Magical

Using 10, 20, 30 is tradition, not requirement. It leaves room for insertions:

# Original:
example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.

# After adding a server between them:
example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  15  mail-new.example.com.
example.com.    IN  MX  20  mail2.example.com.

Priorities 10, 20, 30 behave identically to 1, 2, 3 or 100, 200, 300. Only the relative order matters.

Backup MX and the Spam Problem

Backup servers with higher priority values accept mail when primaries fail:

example.com.    IN  MX  10  primary.example.com.
example.com.    IN  MX  50  backup.example.com.

The backup queues messages and forwards them when the primary recovers.

But there's a catch: spammers know backup servers exist. They intentionally target them, hoping for weaker filtering on the "rarely used" backup. This is called backscatter or backup MX exploitation.

Your backup servers need spam filtering as rigorous as your primaries. "It's just the backup" is exactly what attackers count on.

Spam Filtering Services

Cloud spam filters work by becoming your MX records:

example.com.    IN  MX  10  filter1.spamservice.com.
example.com.    IN  MX  20  filter2.spamservice.com.

Your actual mail servers aren't in DNS at all. The filtering service receives all mail, scans it, and forwards clean messages to your servers (configured in their admin panel).

Senders never connect directly to your infrastructure. Your servers are invisible to the Internet.

Testing Your Configuration

Verify MX records:

$ dig example.com MX

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail1.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.

Verify failover works: Temporarily disable your primary server's SMTP service. Send a test message. Check which server received it.

Examine Received headers: After receiving test messages, look at the Received headers to see which server accepted delivery.

Common Mistakes

Reversed priorities:

# Wrong—backup tried first:
example.com.    IN  MX  20  primary.example.com.
example.com.    IN  MX  10  backup.example.com.

# Right—primary tried first:
example.com.    IN  MX  10  primary.example.com.
example.com.    IN  MX  20  backup.example.com.

Expecting immediate failover on temporary errors: Sending servers retry the same priority for 4xx errors. Backups won't help with an overloaded primary returning "try again later."

Equal priority when you wanted failover: Two servers with priority 10 means load balancing, not failover. If you want failover, use different priorities.

Weak backup server security: Backup servers are targeted specifically because administrators assume they don't need full protection.