Skip to content
fixyour.page

MX Record Lookup

See which servers accept mail for a domain, in priority order.

Your data stays in your browser
Enter a domain to see its MX records in priority order. Queries go straight from your browser to Cloudflare's public DNS resolver, never to our servers.

Related Tools

SPF Checker

Check a domain's SPF record. Follows every include and counts the 10-lookup limit.

Use tool →

DMARC Checker

Check a domain's DMARC policy. Tags explained in plain English, reporting verified.

Use tool →

TXT Record Lookup

List every TXT record on a domain, classified: SPF, DKIM, DMARC, and verification tokens.

Use tool →

Email Header Analyzer

Parse raw email or message headers to trace delivery path, authentication, and delays.

Use tool →

How to Look Up MX Records

Type a domain and hit Check. The tool queries Cloudflare's public DNS resolver over HTTPS, straight from your browser, and lists every MX record in priority order. It then checks the A and AAAA records behind the first three exchanges, so you can see whether each mail server name points at a real address or at nothing.

The checklist flags the misconfigurations that actually break mail: a null MX mixed in with real records, exchanges that are bare IP addresses, targets that resolve through CNAMEs, and single-server setups with nothing to fail over to. MX records only cover the receiving side of email. To test the sending side, run the same domain through our SPF Checker and DMARC Checker.

How Mail Finds Your Server

When a server has a message for your domain, it asks DNS for your MX records, sorts them by priority, and tries the lowest number first. If that host doesn't answer, it moves up the list until something accepts the connection. Exchanges that share a priority get picked at random, which spreads the load across them.

A domain with no MX records isn't automatically unreachable. RFC 5321 §5.1 tells senders to fall back to the domain's A or AAAA record and attempt SMTP delivery there. That fallback dates from an era when your web server and your mail server were the same machine. They almost never are now, so treat a missing MX as an outage, not a quirk.

Common MX Record Mistakes

Pointing an MX at a CNAME is the classic. It usually works, which is exactly why it survives for years, but RFC 2181 §10.3 requires the MX target to be a hostname with its own address record, and some receivers enforce that. IP addresses in MX records are the blunter version of the same mistake: RFC 5321 requires a hostname, full stop, and an MX of 192.0.2.1 is invalid even where it happens to work.

The quieter failures are structural. A single MX record means one dead server stops your inbound mail. A stale exchange that no longer resolves makes senders burn time on a host that isn't there, and if it's your only record, delivery just fails. And a null MX pasted next to real records tells receivers you both accept and refuse mail. RFC 7505 says the null record stands alone. This tool checks for all four.

What is an MX record? +
An MX (mail exchange) record tells sending servers which host accepts email for your domain. When someone emails you@yourdomain.com, their mail server looks up your MX records, sorts them by priority, and connects to the lowest number over SMTP. No MX record means senders fall back to your domain's A record (RFC 5321 §5.1), which only helps if that host actually runs a mail server. Most don't, which is why a missing MX usually means missing mail.
What does MX priority mean? +
Priority sets the order senders try your mail servers. Lower numbers go first, so a server at priority 10 gets tried before one at priority 20, which only sees traffic when the first is down or refusing connections. Records that share a priority split the load: senders pick between them roughly at random. The numbers themselves don't matter, only the order. Priorities 0 and 10 behave exactly like 10 and 20.
What is a null MX record? +
A null MX is a single record with priority 0 and a bare dot as its target, defined in RFC 7505. It's a domain's way of saying it never accepts mail, so senders can reject messages immediately instead of retrying for days. Publish one on domains that don't do email at all, like parked domains and web-only subdomains. It has to be the only MX record. A null MX next to real records is invalid and confuses receivers.
How many MX records should I have? +
At least two. One MX record is a single point of failure: when that server goes down, inbound mail queues at the sender and starts bouncing after a few days. Big providers hand you redundancy out of the box. Google Workspace gives you five records, and Microsoft 365 uses one hostname backed by their own failover. If you run your own mail server, add a backup MX at a higher priority number, or let a relay service catch mail while you're down.
↑ Back to top