How it works
Enter a domain (for example example.com) and the tool queries public DNS for that domain's MX (Mail Exchanger) records, the records that tell the internet which servers accept inbound email for the domain. Results come back sorted by priority, lowest number first, with the top entry flagged as the Primary mail server. Each row shows three things: the priority value, the mail server's hostname, and the record's TTL in seconds (how long resolvers may cache it).
To read the output, start at the top. The lowest-priority host is where senders will try to deliver first. If two or more hosts share the same priority number, they are treated as equals and mail is spread across them, a common load-balancing and redundancy pattern. Higher numbers are fallbacks: a sender only moves to them if every lower-priority host refuses or times out.
Use it to confirm which provider actually runs a domain's mail (the hostnames usually reveal it, for example a Microsoft 365 or Google Workspace endpoint), to check that a migration's new records have propagated, or to diagnose delivery failures. If the tool reports no MX records, the domain has none published; per RFC 5321 some senders will fall back to the domain's A/AAAA address ("implicit MX"), but relying on that is fragile and generally means the domain is not set up to receive mail.
MX priority and how it relates to SPF & DMARC
MX records govern where mail arrives. They say nothing about whether outbound mail claiming to be from the domain is legitimate, that is the job of SPF, DKIM and DMARC, which are separate DNS records. The table below summarises the four and how they fit together.
| Record | DNS location | Direction | What it controls |
|---|---|---|---|
| MX | domain (apex/sub) | Inbound | Which servers accept mail, in priority order (lowest number = most preferred). |
| SPF | TXT on the domain | Outbound | Which IPs/hosts may send as the domain; declared as v=spf1 … ending in -all or ~all. |
| DKIM | TXT at selector._domainkey | Outbound | Public key used to verify a cryptographic signature on each message. |
| DMARC | TXT at _dmarc.domain | Policy | What receivers do when SPF/DKIM fail alignment (p=none, quarantine, or reject) plus reporting. |
Priority values are relative, not absolute, 10 and 20 behave the same as 1 and 2. Equal values mean "load-balance between us." A healthy MX setup plus valid SPF, DKIM and a DMARC policy is what keeps a domain both able to receive mail and trusted when it sends.
Frequently asked questions
What does the priority number in an MX record mean?
It sets delivery preference, and the lowest number wins. Senders attempt the lowest-priority host first and only fall back to higher numbers if it is unreachable. The absolute values do not matter, only their order relative to each other.
Can a domain have more than one MX record?
Yes, and most production domains do. Multiple records at different priorities provide failover, while multiple records sharing the same priority provide load balancing. This tool lists every record it finds and marks the lowest-priority one as the primary.
Why does a domain show no MX records?
It has none published, so it is not configured to accept email in the normal way. Some senders will fall back to the domain's A/AAAA record under the "implicit MX" rule, but this is unreliable and usually indicates the domain is send-only or misconfigured.
Do MX records affect whether my email lands in spam?
Not directly, MX only controls inbound routing. Deliverability of your outbound mail depends on SPF, DKIM and DMARC being correctly aligned, along with sending-IP reputation. Check those separately with an email-security analyzer.
I changed my MX records but the tool shows the old ones. Why?
DNS results are cached for the length of the record's TTL, shown in the TTL column in seconds. Resolvers may keep serving the previous values until that timer expires, so changes can take from minutes to hours to appear everywhere.