What Is an MX Record and How Does MX Priority Work?

How MX routing works

An MX (mail exchanger) record tells other mail systems which hostnames a domain prefers for inbound SMTP delivery. A sending server looks up the recipient domain's MX records, then attempts the listed hosts in priority order. The number is often called preference or priority: a lower number is more preferred. MX 10 mail1.example.com is tried before MX 20 mail2.example.com.

Multiple MX records can provide resilience. A second host can accept mail when the preferred host is unavailable, provided both hosts are configured to receive mail for the domain. The hostname in an MX record is normally a fully qualified domain name; a trailing dot in zone-file notation simply marks it as absolute. The host itself needs usable A and/or AAAA address records.

For example, a domain might publish 10 mail.example.net. and 20 backup.example.net. A sender normally tries mail.example.net first, then backup.example.net if the first connection cannot be made. Equal priorities are possible and may be used for load distribution, but exact sender behavior varies.

MX is not A, CNAME, or TXT

An A or AAAA record maps a hostname to an address; an MX record points a domain to a mail host; a TXT record carries text-based policies such as SPF and DMARC. Publishing an A record for example.com does not by itself say where inbound mail belongs. Likewise, an MX record names a host rather than directly carrying an IP address.

Avoid pointing an MX record at a CNAME. DNS standards and mail software make this a poor and often incompatible configuration. Point the MX to a real hostname with address records instead. Also avoid a mail host that resolves only to an internal or private address from the public internet.

A domain with no MX may not accept mail. SMTP has historically allowed a sender to fall back to the domain's A or AAAA record when no MX exists, but relying on that behavior is rarely a good mail design and modern policy or provider settings can complicate it. A null MX record is an explicit way for a domain to say it does not accept email.

Common problems and a useful check order

Frequent issues include a misspelled target hostname, priorities that do not reflect the intended primary server, an MX target without address records, expired hosting configuration, and a change that is still cached. A mail host can also be reachable but reject mail because it is not configured for that recipient domain.

Start with an MX lookup and read the priorities from lowest to highest. Resolve each returned hostname, then test the mail provider's documented setup. Review SPF and DMARC for the sending side, but remember those records do not route inbound mail. If DNS answers differ after a change, check TTL and authoritative nameservers before assuming a delivery outage.

An MX record only describes intended routing. It does not prove that port 25 is reachable, that TLS works, that the server accepts recipients, or that messages avoid spam filtering. Reputation, mailbox existence, authentication, and receiver policy all affect real delivery.

When moving to a new mail provider, publish the new MX values exactly as the provider specifies and retain the old service only for the agreed transition period. Then check the public DNS answer, each target hostname, and a controlled end-to-end delivery test. Do not use a random external address as a test recipient: a provider can accept a TCP connection yet reject an unknown recipient or defer a message later. MX is one layer of a complete inbound-mail configuration.