MX record priority: the lowest number gets the mail first
· mx · dns · email · priority · mail-routing
mxdnsemailprioritymail-routingAn MX record's first field is its preference (commonly called priority), and the rule is simple: the lowest number is tried first. A sending mail server sorts your MX records in ascending order, attempts delivery to the most-preferred host, and only falls over to a higher number when a lower one is unreachable. When two records share the same number, the sender picks among them at random, spreading load across them. The number is purely an ordering hint — it is not a quality score and a higher number does not mean a "lesser" server.
How a sender reads your MX records
Suppose your domain publishes three records:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 20 mail3.example.com.
A sending MTA delivers like this:
- Sort by preference ascending:
10, then the20pair. - Try
mail1.example.com(preference10) first. - If
mail1refuses the connection or times out, fall over to the20group. - Within the
20group,mail2andmail3are tried in random order, so traffic is balanced across them roughly evenly over time.
The numbers themselves are arbitrary; only their relative order matters. 10/20/30 behaves identically to 1/2/3. The conventional gaps (10, 20, 30) just leave room to insert a host later without renumbering everything.
Equal numbers mean load balancing, not failover
When you want two servers to share inbound mail rather than one backing up the other, give them the same preference:
example.com. IN MX 10 mta-a.example.com.
example.com. IN MX 10 mta-b.example.com.
Each new connection lands on one or the other at random. This is the standard way large providers spread inbound load. Note this is best-effort distribution at the per-connection level, not a true balancer — a sender that fails on one will simply retry the other.
Debunking the "backup tier" myth
A persistent misconception is that the highest-numbered MX is a "backup" that applies weaker spam filtering, or that priority somehow reflects how good a server is. Neither is true.
- A higher-preference (larger-number) host is only ever reached when every lower-preference host is down. It is a failover target, not a second-class one.
- It must apply identical anti-spam and anti-relay policy to your primary, because attackers deliberately target the highest MX expecting it to be a soft underbelly.
- The preference value carries no information about hardware, capacity, or filtering quality. It only answers "in what order should I try these hosts?"
If you are running a separate failover host on purpose, treat it as a full peer of the primary, not a leaky backdoor.
Look up your MX records →Further reading
- Do I need a backup MX record? Usually not anymore
- No MX record found: what it means and how to fix it
- Google Workspace MX records are set but email isn't arriving
- RFC 5321 — Simple Mail Transfer Protocol (MX preference and delivery order)