Guide
How mail finds a domain: MX records, priorities and fallbacks
Email is delivered by looking up the mail exchangers of the recipient’s domain. If those records are missing or wrong, messages bounce or vanish, and the first sign is often a user who cannot receive anything after a change of provider. The page shows the MX records of a domain in the order a sender would use them, with the addresses behind each server.
How a sender uses the records
A mail server that wants to deliver to [email protected] asks DNS for the MX records of example.com. Each record has a priority number and a host name. The sender sorts by priority and connects to the lowest number first. If that server is down or refuses the connection, it tries the next. When several records share a priority, the sender chooses among them at random, which spreads the load. The record format and the fallback rules are described in RFC 5321, which also says that without any MX record, the sender uses the domain’s own A or AAAA record.
What the table shows
The columns are priority, mail server, addresses, hosted by, and TTL. The addresses column is the result of looking up each server name, IPv4 and IPv6 together, so you can see at once whether a server actually resolves. “Hosted by” recognises common providers from the server names, such as Google Workspace or Microsoft 365, which is useful when you inherit a domain and do not know where its mail lives. The line beneath the table reports the resolver, response time and DNS status.
Mistakes the page makes visible
An MX target without an address record shows up as a server with no addresses. A target that is an IP address or a CNAME is invalid by the standard, even if some servers tolerate it. Priorities that all differ in unusual ways, a missing backup, or servers at a former provider are visible at a glance. For a domain that should not receive mail at all, the right answer is a null MX (RFC 7505): a single record with priority 0 and the target .. The page recognises it, and a null MX is also what stops senders falling back to the A record.
A worked example
Press Sample to look up gmail.com. The table lists five mail servers with priorities 5, 10, 20, 30 and 40: gmail-smtp-in.l.google.com first, then alt1 to alt4 of the same name. Each row shows an IPv4 and an IPv6 address and the TTL, and the first is the target every sender tries before the others. When this guide was reviewed the TTL was about an hour; addresses change but the pattern is stable. In contrast, example.com returns a single record 0 ., a null MX, which is the correct declaration for a domain with no mail.
Limits
DNS records say where mail should go, not whether the server accepts it. The page does not connect to port 25, test TLS, or check blocklists. The hosted-by label depends on recognisable server names, so a provider behind your own custom name is not detected. To judge whether mail from the domain can be forged, continue with the SPF Record Checker and DMARC Checker.
Related tools
- SPF Record Checker tests which servers may send for the domain.
- DMARC Checker reads the policy for mail that fails authentication.
- Email Spoofing Test scores the whole email setup.
- NS Lookup shows who hosts the domain’s DNS.
Checked against the current version of the MX Lookup on .