MX Record Priority and Failover: How Mail Servers Actually Choose Between Multiple MX Records

A domain with five MX records doesn't send email through five servers simultaneously — the priority number determines a strict order, and understanding that order explains both normal failover and some confusing delivery delays

MX (Mail Exchange) records can include a priority value (sometimes called "preference") alongside each mail server hostname. Multiple MX records for a domain aren't load-balanced in the way some people assume — they represent an ordered list of servers that sending mail systems should attempt, in order, with specific rules about what happens when the preferred server doesn't respond.

How MX priority actually works

Each MX record has a priority number — lower numbers indicate higher priority (this trips people up, since "lower = more preferred" is the opposite of how priority often works in other contexts).

Example MX record set:

example.com.  MX  10  mail1.example.com.
example.com.  MX  20  mail2.example.com.
example.com.  MX  30  mail3.backup-provider.com.

The sending mail server's behaviour:

1. Attempt delivery to mail1.example.com (priority 10, the lowest number = highest priority) first
2. If mail1.example.com is unreachable, or refuses the connection, or times out, the sending server tries mail2.example.com (priority 20)
3. If that also fails, try mail3.backup-provider.com (priority 30)
4. If all listed servers fail, the sending mail server typically queues the message and retries later (the retry schedule and duration depend on the sending server's configuration — commonly retrying over a period of hours to days before eventually bouncing, though specifics vary by mail server software)

Equal priority values: this is where load distribution happens

If multiple MX records share the same priority value, this is the actual mechanism for distributing load across multiple servers — sending mail servers are expected to choose randomly among MX records with the same (lowest) priority value.

example.com.  MX  10  mail1.example.com.
example.com.  MX  10  mail2.example.com.
example.com.  MX  20  mail3.backup-provider.com.

In this configuration, incoming mail is distributed (roughly evenly, assuming many sending servers each making independent random choices) between mail1 and mail2, with mail3 only used if both priority-10 servers are unreachable.

This is meaningfully different from the first example — where mail2 would only receive mail if mail1 were down. Domain owners sometimes intend "these two servers should share the load" but configure different priority values (10 and 20), which actually creates a primary/backup relationship rather than load distribution — or conversely, intend "this is my backup, only use it if primary is down" but give both the same priority, creating unintended load distribution to a server that wasn't provisioned to handle a full share of traffic.

What "the server is down" actually means for MX fallback purposes

The fallback to a lower-priority MX record isn't triggered by any failure — specifically, it's triggered by:

• Connection failures — the sending server can't establish a TCP connection to the mail server on port 25 (or whichever port is relevant) at all (host unreachable, connection refused, connection timeout)
• Certain SMTP-level temporary failures — some SMTP error codes (4xx temporary failure codes) might cause a sending server to try the next MX record for that delivery attempt, though the exact behaviour can depend on the sending server's implementation

What does NOT typically trigger fallback to the next MX record: a permanent failure (5xx SMTP error) from the highest-priority server that successfully accepted the connection — if mail1.example.com accepts the connection and then responds with "550 No such user" for a specific recipient address, this is telling the sending server "this recipient doesn't exist on this domain" — trying mail2.example.com wouldn't help, because the recipient doesn't exist, not because this particular server is unavailable. The sending server would bounce the message back to the sender as undeliverable, rather than trying lower-priority MX records for what is fundamentally a "this address doesn't exist" response.

The "null MX" record: explicitly indicating a domain doesn't accept email

RFC 7505 defines a specific convention for domains that should never receive email — a single MX record pointing to . (the root domain) with priority 0:

example.com.  MX  0  .

What this signals: "this domain explicitly does not accept email — don't bother trying, and don't treat the absence of MX records as potentially a misconfiguration that you should work around via fallback-to-A-record behaviour" (the fallback behaviour is discussed next).

This is useful for domains that exist for other purposes (e.g., a domain used only for a website, with no associated email) — explicitly declaring "no email here" via the null MX convention is clearer than simply having no MX records at all, which some sending systems might (or might not) interpret in fallback ways.

What happens with no MX record at all: the A/AAAA record fallback

Historically (and still specified in the relevant standards, though its practical relevance has decreased), if a domain has no MX records at all, some sending mail servers will fall back to attempting delivery directly to the domain's A or AAAA record (i.e., treating the domain's regular IP address, normally used for web traffic or other purposes, as if it were also a mail server).

Why this matters: a domain with a website (A record pointing to a web server) but no MX records and no null MX record might, in principle, receive connection attempts on port 25 directed at its web server's IP — which the web server (not being configured to handle SMTP) would simply refuse or fail to respond to in a meaningful way, but this still represents some mail systems attempting delivery in a way the domain owner likely didn't intend or expect. This is part of why the null MX convention (explicitly declaring "no email") is considered better practice than simply omitting MX records for domains that genuinely don't use email, even though in practice many domains do simply omit MX records without using the null MX convention, and this rarely causes visible issues given how sending server implementations have evolved.

Practical MX configuration patterns

Single provider, single MX (most common for smaller domains):

example.com.  MX  10  mail.provider.com.

Simple — all mail goes to the provider's mail server. Reliability depends entirely on that provider's infrastructure (which, for major email providers, typically includes their own internal redundancy, even if it appears as a single MX record from the domain's perspective).

Primary provider + backup MX service:

example.com.  MX  10  mail.primaryprovider.com.
example.com.  MX  20  mail.backupmxservice.com.

A "backup MX" service receives and queues mail if the primary is unreachable, then relays it to the primary once it's back — this pattern was historically more common when individual organisations ran their own mail servers with less inherent redundancy than modern cloud email providers offer; its relevance for domains using major cloud email providers (which have their own robust infrastructure) is more limited, though backup MX services are still used in some configurations.

How to use the MX Lookup tool on sadiqbd.com

1. Check the priority values of all MX records — understand whether multiple records represent primary/backup or load-distribution configurations (same priority = distribution, different priorities = primary/backup ordering)
2. Verify backup MX configurations point to services that are actually configured to handle your mail — a backup MX record pointing to a server that isn't set up to accept/relay mail for your domain would cause delivery failures if the primary ever becomes unreachable and fallback is attempted
3. Check for null MX configuration on domains that don't use email — verify whether MX 0 . is configured, or whether MX records are simply absent

Frequently Asked Questions

If I have two MX records with the same priority, will exactly half my email go to each server? Approximately, over a large enough volume — but it depends on how many different sending mail servers are delivering to you, and each sending server's specific random-selection implementation. For a domain receiving email from many different senders, the practical distribution tends toward roughly even over time; for a domain receiving only occasional email from a small number of senders, the distribution for any given period could be uneven simply due to small sample size, not because the mechanism is broken.

Can I use MX priority to send different types of email to different servers (e.g., marketing email to one server, transactional to another)? No — MX records and their priorities operate at the domain level for incoming mail routing, based on the recipient's domain (the right-hand side of the email address) — they have no awareness of email type, content, or which sending system originated a message. Routing different types of outbound email through different systems is a sending-side configuration (different sending infrastructure/IPs for different email categories, a common practice for reputation management), entirely separate from the receiving domain's MX configuration.

Is the MX Lookup tool free? Yes — completely free, no sign-up required.

Try the MX Lookup tool free at sadiqbd.com — check any domain's MX records, priorities, and configuration instantly.