MX records explained: how mail finds its way to a domain

An MX record (mail exchanger record) is the DNS entry that tells the world which servers accept email for a domain. When you send to someone@example.com, your mail server asks DNS for example.com's MX records, picks the exchange with the lowest priority number and connects to it on port 25. A domain with no working MX record cannot receive mail, which is why every serious email verifier checks MX before it does anything else.

What does an MX record contain?

Each MX record has three parts that matter:

• The domain it belongs to, such as example.com.
• A priority, also called preference: a number from 0 to 65535 where lower means "try me first".
• The exchange: the hostname of a mail server. It must be a hostname with its own A or AAAA record, never a bare IP address, and it should not be a CNAME.

A domain usually publishes between one and five MX records. The sending server sorts them by priority, tries the lowest number first and only moves to the next one if the connection fails or times out. Records that share a priority are used in rotation, which is how large providers spread load across a pool of servers.

Priority is relative. 1 and 10 behave exactly like 5 and 50; only the order matters.

What does a dig MX query look like?

The quickest way to see a domain's MX records is dig, which ships with macOS and most Linux distributions:

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

$ dig MX example.com

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.

Reading the full answer left to right: the domain, the TTL in seconds (how long resolvers may cache the answer), the class, the record type, the priority and the exchange hostname. The trailing full stop means the hostname is fully qualified. On Windows the equivalent is nslookup -type=MX example.com. If you would rather not open a terminal, the MX lookup tool shows the same answer with the provider identified.

What do common providers' MX records look like?

You can usually tell who hosts a domain's mail from the exchange hostnames alone, and that is exactly how the email provider finder works.

One caveat: a domain behind a third-party filter (Mimecast, Proofpoint, Barracuda) shows the filter's hostnames, not the mailbox provider's, so the MX tells you where mail enters, not necessarily where it ends up.

What happens when a domain has no MX record?

RFC 5321 includes a fallback: if a domain has no MX records at all, the sender treats the domain's A record as an implicit MX with priority 0 and tries to deliver there directly. This is why some very old or very small domains receive mail without ever publishing an MX record.

In practice the fallback is unreliable. The A record usually points at a web server that is not listening on port 25, so the connection is refused or times out. A verifier will report the address as undeliverable or unknown depending on what the server does, and most bulk mail platforms refuse to send to a domain with no MX at all. If you run a domain that receives mail, publish an MX record and do not rely on the fallback.

What is a null MX?

A null MX is a deliberate statement that a domain does not accept email. It is a single MX record with priority 0 and a lone full stop as the exchange:

example.net.    3600    IN    MX    0 .

Defined in RFC 7505, it is the correct way to mark a web-only domain, a parked domain or a subdomain used only for sending. A sending server that sees a null MX gives up immediately with a permanent failure rather than retrying for days. Verifiers treat an address at a null MX domain as undeliverable, which is the right answer: the owner has told you it cannot receive mail.

What do missing or broken MX records mean for verification?

When Verifyre checks an address, the DNS stage runs before any SMTP conversation, and the result is reported in the checks.mx field and the mx array of the response. The outcomes are:

1. MX records found and resolving. The check continues to the SMTP handshake described in how SMTP verification works.
2. No MX, A record fallback present. We attempt port 25 on the A record. Most of these time out and end as unknown or undeliverable.
3. No MX and no A record, or the domain does not exist. Undeliverable, with the cause spelled out in reason_text (the full list is on the status codes page), and no connection attempted.
4. Null MX. Undeliverable, immediately.
5. MX present but the exchange does not resolve. A dangling record left behind after a migration. Undeliverable in practice, because nothing can connect.

On a typical list that has not been cleaned for a year, somewhere between 2% and 5% of addresses fail at this stage: expired domains, companies that folded, and typos like gmial.com that resolve to nothing useful. Catching them here costs no SMTP connection, and no time is wasted on deeper checks.

How do you check your own MX records?

If you send or receive mail on a domain, check it from time to time, especially after any change to hosting or DNS:

1. Run dig MX yourdomain.com +short or paste the domain into the lookup tool above.
2. Confirm every exchange hostname resolves to an IP address. A record that points at a decommissioned server is the most common silent failure.
3. Check the priorities make sense: your primary should be the lowest number, and backups should actually accept mail for the domain.
4. If you have changed providers, make sure the old provider's records are gone. Two providers' records mixed together will route some mail to the wrong place.

MX is only the receiving half of the picture. The sending half, which decides whether your own mail gets delivered, lives in SPF, DKIM and DMARC records on the same domain, and we walk through those in SPF, DKIM and DMARC setup for senders.

Key takeaways

• An MX record names the servers that accept mail for a domain; the lowest priority number is tried first.
• The exchange hostnames usually reveal the provider: Google, Microsoft 365, Proton, Zoho or a self-hosted server.
• No MX means the sender falls back to the A record, which rarely works; a null MX (priority 0, exchange ".") means the domain refuses mail outright.
• Verifiers check MX before SMTP, and 2% to 5% of an uncleaned list typically fails here.
• Check your own records after any DNS or hosting change.

Frequently asked questions

Can an MX record point to an IP address?

No. The exchange must be a hostname that itself resolves through an A or AAAA record. Some servers tolerate an IP, but many reject it, and RFC 2181 also says the target should not be a CNAME.

Does a lower or higher priority number win?

Lower wins. A record with priority 10 is tried before one with priority 20. Equal priorities are used in rotation to share load.

Why does a domain with a valid MX still bounce my mail?

The MX only tells you a server is willing to accept mail for the domain. The specific mailbox may not exist, the server may be a catch-all that bounces later, or the domain may filter at the edge. Only an SMTP check against the mailbox answers that, which is what the email checker does.