What is an MX record, and how does mail priority work?

What does the priority number in an MX record mean?

Every MX record has two parts: a preference (priority) number and a hostname. RFC 5321 states plainly that "the lowest-numbered records are the most preferred." A record with preference 10 is tried before one with preference 20, and a record with preference 0 is tried before both. The number itself has no meaning beyond ordering; a domain could use 10 and 20, or 5 and 50, with identical behavior.

When two or more MX records share the same lowest preference, the sender does not pick one arbitrarily or always use the first one listed. RFC 5321 requires that "the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers." Two servers at preference 10 each receive roughly half of the connections over time, which is how a domain load-balances inbound mail across identical servers without any special configuration on the sending side.

How does a sending server pick which mail host to use?

A sending mail server looks up every MX record for the recipient's domain, sorts them by preference, and connects to the lowest-numbered host first. If several records tie at that lowest number, it picks one at random from that group. Only if every host at the current preference level fails to accept the connection does the sender move on to the next-highest preference group, and so on down the list.

This is why a common setup uses a low preference for a primary mail server and a higher preference for a backup: normal mail lands on the primary, and the backup is only contacted once the primary is unreachable.

What happens if the preferred mail server does not answer?

Nothing is delivered instantly to the next host on a single failed attempt in the way a web browser might retry a different server. A sending mail server that cannot connect to the top-preference host tries the next host at that same preference level, then moves down to hosts at the next preference number if none answer. If every listed mail exchanger is unreachable, the message is queued and the sending server retries later rather than bouncing immediately, since a mail outage is often temporary. Exactly how long a message stays queued before it is returned as undeliverable is a configuration choice each sending mail system makes for itself, not something the MX record controls.

Why must an MX record point to a hostname, never an IP address or a CNAME?

An MX record's value is always a domain name, never a bare IP address. That domain name then needs its own A or AAAA record so the sending server can resolve it to an address. RFC 2181, section 10.3, is explicit about the other restriction: "the domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias," meaning it must not be a CNAME.

The reason is how DNS resolvers optimize an MX lookup. When a resolver looks up MX records, it normally also fetches the address records for each exchange host in the same exchange, a step called additional section processing, so the sending server does not need a second round trip to resolve the hostname. That shortcut does not follow a CNAME, so an MX record pointing at an alias loses the speed benefit and, on some resolvers, can fail the lookup outright. The fix is always to point the MX record at the real hostname (the CNAME's target) directly.

What happens when a domain has no MX record at all?

SMTP has a defined fallback for this case. RFC 5321, section 5.1, says that if a domain returns no MX records, the address "is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host" - meaning the sender falls back to the domain's own A or AAAA record and tries to deliver mail directly to whatever server that address resolves to.

This fallback is a safety net for domains that never configured mail at all, not a substitute for a real MX record. A web server's IP address rarely runs a mail service, so mail to a domain with no MX record commonly just fails to connect. A domain that intentionally does not accept mail should not rely on silence; the standard way to say so explicitly is a single MX record with preference 0 and the target written as a lone dot, defined in RFC 7505 as a "null MX" precisely so mail senders can tell "no mail service configured" apart from "misconfigured."

How do you read a real MX lookup?

The command line output makes the priority-and-hostname structure concrete:

dig MX example.com +short
10 mail.example.com.
20 mail2.example.com.

Here, mail.example.com is tried first because 10 is lower than 20; mail2.example.com only gets a connection attempt if the first is unreachable. Two records at the same number, such as 10 mail.example.com. and 10 mail2.example.com., would instead be split roughly evenly between the two.

The free MX lookup tool queries a domain's MX records from HostTracker's own network of checkpoints at once and lists each distinct mail server hostname that comes back, along with which locations returned it - useful for confirming every location sees the same set of servers rather than a stale or partially propagated answer. It lists the mail server hostnames themselves rather than the numeric priority value, so treat each result as one of the domain's mail servers, not a ranked order; for the priority numbers, a command-line lookup like the one above is the direct source. An MX record only says where mail should go, not whether it will be accepted once it gets there - see what an SPF record is for the check that decides who is allowed to send it.

Frequently asked questions

Can a domain have more than one MX record?

Yes, and most production domains do. Multiple records let a sender fail over to a backup server, or split load across several equally-preferred servers when the preference values are tied.

Does an MX record affect outgoing mail?

No. An MX record only tells other servers where to deliver mail addressed to that domain. What server a domain uses to send mail out is a separate configuration on the sending system and has nothing to do with its own MX records.

Can I point an MX record directly at an IP address?

No. The DNS standard for MX records only allows a hostname as the target, and that hostname then needs its own A or AAAA record. Some DNS providers reject an IP address entered in an MX field outright.

What is a "null MX" record?

A single MX record with preference 0 and the target set to a lone dot, defined in RFC 7505. It tells sending servers explicitly that a domain accepts no mail at all, instead of leaving them to guess from an empty MX list.

Why do I see the same preference number on two different hostnames?

That is deliberate load balancing. Mail exchangers listed at an identical preference are meant to be interchangeable, and senders are required to pick among them at random rather than always favoring the one listed first.

Does changing an MX record take effect immediately?

No faster than the record's TTL allows. Like any DNS record, a changed MX value can keep resolving to the old answer at resolvers that already cached it until that cache entry expires.