Free MX Record Lookup

What MX records are and how mail routing works

An MX (Mail eXchange) record is the DNS entry that answers one question: where should email for this domain be delivered? When someone sends to name@company.com, their mail server asks DNS for the MX records of company.com, gets back one or more hostnames, and opens an SMTP connection to the first of them. No web server, no website, no guesswork — the MX record is the routing table for email.

Each record carries a priority number, and lower wins. A typical setup looks like 10 mx1.example.com and 20 mx2.example.com: senders try the priority-10 host first, and only fall back to priority 20 if it's unreachable. That's failover, and it's why serious mail setups publish more than one MX. Records with equal priority share the load. A domain with a single MX still works — it just has no backup route if that one host goes down.

How to read your results

When you run the lookup in the product, the results table shows every MX record found, sorted by priority — the top row is where mail goes first. Next to each hostname is a resolved IP address, so you can see that the MX target actually points somewhere real. A hostname with no IP behind it is a broken route.

The provider badge is often the most useful part. MX hostnames follow recognizable patterns: aspmx.l.google.com means Google Workspace, *.mail.protection.outlook.com means Microsoft 365, *.pphosted.com means a Proofpoint security gateway is filtering inbound mail, and so on. From one lookup you learn what a company runs its email on, whether a filtering gateway sits in front of the mailboxes (which affects how aggressively your mail is screened), and whether the domain merely forwards mail elsewhere rather than hosting real inboxes.

Null MX and the A-record fallback

Two edge cases trip people up. The first is the null MX (RFC 7505): a single MX record with priority 0 pointing at the DNS root, written as 0 .. It isn't broken DNS — it's a deliberate declaration that the domain accepts no mail, ever. Domains used only for websites or for sending publish it so that mail to them fails fast instead of queueing for days. Every address at a null-MX domain is undeliverable by design.

The second is the A-record fallback (RFC 5321): if a domain has no MX records at all but does have an A or AAAA record, senders are supposed to attempt delivery to that IP directly. It's a relic from email's early days, and it only works if a mail server happens to be listening there — on a modern web host it almost never is. When the check finds the fallback, it says "routable with caveats" rather than pretending the domain is healthy, because in practice most mail to MX-less domains bounces.

Why MX presence matters for list hygiene

Every address on your list whose domain has no working MX is a guaranteed bounce — and mailbox providers judge you by your bounce rate. That makes the MX check one of the cheapest, highest-value filters in email verification: it costs one DNS query and eliminates a whole class of dead addresses before you ever send. It's exactly one stage of the pipeline the free email checker and the full email verifier run: syntax, domain, MX, disposable/role flags, and then — where DNS can't reach — the SMTP conversation that confirms the individual mailbox exists.

The honest limit works both ways: a domain with perfect MX records can still be full of dead mailboxes, and only an SMTP-level check can tell you that. MX answers "can this domain receive mail?" — not "does this person exist?"

Common MX problems

• Missing MX after a DNS migration — the classic. A site moves registrars or nameservers, the web records get copied, and the MX records quietly don't. The website works, so nobody notices until inbound mail has been bouncing for days. Check MX first after any DNS move.
• MX pointing at a CNAME — RFC 2181 requires MX targets to be hostnames with their own address records, not aliases. Most senders cope, some reject; either way it's an easy fix. The MX check flags hosts that resolve through a CNAME.
• Typos in the target hostname — aspmx.l.google.com misspelled by one character resolves to nothing, and mail to the domain fails even though "the MX record exists." The IP column in your results exists precisely to catch this: a hostname with no IP is a route to nowhere.
• Only one MX host — not an error, but no redundancy. If that single server is down for longer than senders are willing to retry (typically a few days at most), mail starts bouncing.