MX Record Lookup
See which servers receive a domain's email, and in what order.
Free, no signup — the answer appears right here.Try:
How MX records work
MX records list the servers that accept inbound email for a domain, each with a priority number — lowest wins, higher values are fallbacks. 0 aspmx.l.google.com then 5 alt1.aspmx.l.google.com means deliver to the first, fail over to the second. No MX records at all, and senders fall back to the domain's A record, which almost never runs a mail server.
MX answers who receives mail; it says nothing about who may send it. That's SPF, DKIM and DMARC — which is why this lookup lands you on the full email report rather than an MX list in isolation.
Problems this catches
Missing MX records on a domain that's supposed to receive mail; stale records still pointing at a previous provider after a migration (mail silently splits between old and new); MX targets that are CNAMEs (forbidden by the spec and rejected by some senders); and leftover low-priority entries pointing at servers that no longer exist, which slow retries and create bounce noise.
Methodology & data sources
The lookup queries the domain's MX records live, resolves each exchange hostname to its IP addresses, and checks reverse DNS on those IPs — the same triage a deliverability engineer does by hand with dig, in one pass, with a checked-at timestamp on every result.
SPF, DKIM and DMARC are evaluated in the same request, because "mail is bouncing" is as often an outbound-authentication problem as an MX one.
Frequently asked questions
What does MX priority mean?
Senders try the lowest number first and walk upward on failure. Equal priorities are load-balanced. The numbers themselves are arbitrary — only their order matters.
Can an MX record point to an IP address?
No — MX must point to a hostname which then resolves via A/AAAA. Pointing MX at a raw IP or at a CNAME both violate the spec and will cost you mail from strict senders.
We migrated email providers — what should MX look like?
Only the new provider's records, exactly as they document them, with the old provider's entries deleted. The most common migration bug is leaving old MX entries in place, which keeps some inbound mail flowing to the dead provider for as long as caches and sender retries allow.
Why is mail bouncing even though MX records look right?
Receiving is only half the path. If your domain's SPF/DKIM/DMARC are broken, the replies and outbound side fails authentication; and if your mail server's IP is on a blocklist, delivery fails regardless of DNS. The report checks both alongside MX.