MX Lookup
See every mail server published for a domain, sorted by delivery priority, with null MX detection and the SPF and DMARC context that decides whether mail actually gets through.
Your browser queries these services directly, so the name you look up and your IP address are visible to them: Cloudflare DNS and Google Public DNS (both public recursive resolvers) for records and comparison, and rdap.org, a redirector that forwards to the registry's RDAP server, for registration data. DevDome does not proxy, see or store these lookups. Privacy policy.
The first check when email breaks
When mail stops arriving, the MX records are where debugging starts, because they are the only thing the whole internet consults to decide where your mail goes. The lookup above shows each record with its priority badge, sorted in true delivery order, and labels the response code so you can tell a missing record from a missing domain. A null MX record, the deliberate "this domain takes no mail" signal from RFC 7505, is called out explicitly instead of being displayed as a confusing "0 ." row.
The Email tab completes the picture: MX says where inbound mail goes, SPF and DMARC decide whether receivers trust mail claiming to come from you. After any mail migration, all three need to move together, and the most common outage we see is MX updated while an SPF include still points at the old provider.
MX record FAQ
How do I read MX record priority?
Each MX record has a priority number and a mail server hostname. Sending servers try the lowest number first and move to higher numbers only if delivery fails, so 10 is preferred over 20. Equal priorities are load-balanced at the sender’s choice. The lookup above sorts records by priority so the delivery order reads top to bottom.
Why does my domain have no MX records?
Three different situations produce that result and they need different fixes. If the answer is empty NOERROR, the domain exists but nobody configured mail: senders fall back to the A record, which almost never runs a mail server, so mail bounces. If the response is NXDOMAIN, the name itself does not exist. And a single record reading "0 ." is a deliberate null MX (RFC 7505): the owner is announcing the domain accepts no mail at all. This tool labels all three cases distinctly.
Mail is bouncing after a provider migration. What do I check?
Run the lookup and compare the MX hosts against what your new provider documents, exactly: a leftover record pointing at the old provider, a typo in the hostname, or a missing record are the usual causes. Then open the Resolver comparison tab and enter the expected MX host: if Cloudflare and Google both show it, resolver caches are picking up the change; if not, check the record at your DNS host and remember caches can hold the old value for up to the old TTL.
Do MX records affect whether my mail lands in spam?
Not directly: MX controls inbound routing, where mail TO your domain goes. Deliverability of mail FROM your domain is decided by SPF, DKIM and DMARC, which live in TXT records. The Email tab above analyzes SPF and DMARC alongside the MX records, because a migration that fixes MX but forgets to update SPF include entries is one of the most common ways outbound mail silently starts failing.
Is this MX lookup live or cached?
It queries Cloudflare’s public recursive resolver over DNS-over-HTTPS from your browser. Recursive resolvers answer from cache when they hold a fresh copy, and the TTL shown is the remaining cache lifetime. That is exactly what most of the internet sees when delivering your mail, which makes it the right view for debugging delivery, just not proof of what your zone file says this second.
More free tools: SPF Checker · DMARC Checker · TXT Lookup · DNS & WHOIS Lookup