MX Record Lookup

What an MX record is

An MX (mail exchanger) record tells sending mail servers where to deliver email for a domain. Each record holds two things: a priority number and the hostname of a mail server, for example 10 mx1.example.com. A domain can publish several. The hostname must have its own A or AAAA record: an MX may not contain an IP address, and it should not point at a CNAME alias. This lookup reads the MX set, sorts it the way a sender does, and then resolves every mail host to its addresses, so you see in one place whether mail for the domain has somewhere to go.

How MX priority works

Lower numbers win. A sender sorts the MX records by priority and tries the lowest number first; only when every host at that priority refuses or cannot be reached does it move to the next number. Hosts that share a priority are tried in random order, which spreads the load between them (RFC 5321 section 5.1). The numbers are only relative: 10 and 20 behave exactly like 1 and 2. Be careful with backup MX hosts that you do not run yourself. Spammers deliberately deliver to the highest-numbered MX because backups often filter less strictly than the primary, so a backup should apply the same filtering and recipient checks.

How to read the result

The table lists the MX records in the order senders try them, with the IPv4 and IPv6 addresses each mail host resolves to. A host with no address at all is a hard failure: mail routed to it cannot be delivered, and senders fall through to the next priority or queue the message. An empty IPv6 column is normal; many mail hosts are IPv4 only. The "mail handled by" fact names the service when the hostnames belong to a well-known provider such as Google Workspace or Microsoft 365. The TTL shows how long resolvers may keep using the current MX set after you change it.

Common MX problems and how to fix them

A missing trailing dot in a zone file turns mx.example.com into mx.example.com.example.com, which resolves to nothing; write the full name with a final dot, or use your DNS panel's hostname field as intended. After a move to a new mail provider, old MX records left in place make senders split mail between the old and new system, so delete the previous provider's records when you add the new ones. An MX that points at a CNAME works with most senders but breaks with some; point it at the real hostname. An MX that contains an IP address is invalid and is ignored. And a domain with no MX at all still receives mail at its A record address, which is rarely what you want: publish real MX records, or a null MX if the domain never receives mail.

Changing mail provider without losing mail

Read the TTL on your MX records a day before the switch and lower it to a few minutes, so resolvers forget the old set quickly. Create the mailboxes at the new provider first, then replace the MX records. Keep the old mailboxes running until the old TTL has passed, because some senders still deliver there for that long. Then update the rest of the mail setup that names the provider: the SPF include, the DKIM selector records, and the mx patterns in an MTA-STS policy if you publish one. Finish by testing the new hosts with the SMTP TLS checker.

Primary sources

• RFC 5321 section 5.1: locating the target host
• RFC 7505: the null MX record
• RFC 2181 section 10.3: MX and NS records must not point to an alias