MX Lookup

A Mail Exchange (MX) record tells the rest of the internet which server accepts email on behalf of a domain. It does not send mail and does not affect a website's hosting - a domain can point its A record at one provider and its MX records at a completely different mail service. This is why moving web hosting never breaks email, and why moving to Google Workspace or Microsoft 365 only requires changing the MX records.

Each MX record pairs a mail server hostname (the "exchange") with a numeric priority. When a sending server wants to deliver a message, it queries the recipient domain's MX records, sorts them by priority, and tries the lowest number first. If that server refuses the connection or times out, delivery falls through to the next priority in line. RFC 5321 defines this behavior as part of the SMTP standard.

A domain with no MX record is not automatically unreachable: RFC 5321 permits falling back to the A record on port 25 if no MX exists. Almost no mail provider relies on this fallback in practice, so a missing MX record is still treated as "email is not configured" for most purposes.

• Lower priority number wins - 10 is tried before 20
• Multiple records at the same priority are used in round-robin fashion for load distribution
• The hostname in an MX record must resolve via an A or AAAA record - never a CNAME (RFC 2181, section 10.3)
• MX records carry no IP address directly; the resolver looks up the exchange hostname separately

A lookup for a working domain returns one row per mail server, each showing a priority and a hostname. The tool also resolves each hostname to confirm it has a valid A or AAAA record - an MX record pointing at a hostname with no address record is a configuration error, since the sending server has nothing to connect to.

Priority values are not standardized beyond "lower goes first" - one provider might use 1 and 10, another 5 and 20, another 0 and 50. The specific numbers only matter relative to each other within the same domain.

The most frequent break is a stale MX record left over after switching providers - mail still routes to a decommissioned server and either bounces or silently disappears, depending on what that old server does with unexpected connections.

A close second is pointing MX at a CNAME instead of an A/AAAA record. RFC 2181 explicitly forbids this, and while some resolvers tolerate it by following the CNAME chain anyway, many mail transfer agents reject the record outright and refuse to deliver.

A third common case: only one MX record with no backup. If that single server has an outage, incoming mail queues up on the sender's side (most well-behaved senders retry for several days per RFC 5321) but nothing gets delivered until the server returns - there is no redundancy to fall back on.

Priority ties are sometimes set unintentionally: two records both at priority 10 when the intent was a strict primary/backup order. Since same-priority records are used interchangeably, this silently defeats a failover design that assumed one server would always be preferred over the other.