MX Lookup
Enter a domain to check its MX records plus SPF, DKIM and DMARC, with the SPF lookup count against the limit of ten.
What each record actually proves
- SPF authorises sending hosts by address. It checks the envelope sender domain, not the From header a person sees, which is why SPF alone does not stop visible spoofing.
- DKIM signs selected headers and the body with a key published in DNS. It proves the message was authorised by the signing domain and was not modified in the signed parts.
- DMARC ties either of those to the visible From header through alignment, and states what a receiver should do when neither aligns. Without DMARC, a receiver has no instruction and no reporting channel.
All three are needed for the visible From address to be protected. Two of the three is a partial answer.
Reading the SPF lookup count
The count shown includes nested includes, resolved recursively, and is the number receivers will compute. A record at eight or nine is not comfortable; adding one vendor breaks it. If you are close to the limit, remove vendors you no longer use before flattening, since a flattened record has to be regenerated whenever a provider changes their ranges.
Limits
We evaluate the records as published. We do not send test mail, so we cannot tell you whether a specific message from a specific sender would pass. For that, send a message to a receiver that reports authentication results and read them in the headers, which is what /email-headers is for.
About this tool
Enter a domain and this checks the DNS settings that control its email. It fetches the MX records with their preferences, parses the SPF record and counts how many DNS lookups it costs against the limit of ten, reads the DMARC policy at _dmarc, and probes a DKIM selector if you supply one. Each record gets its own verdict with a reason, because the failures are different in kind.
How to read the result
- MX records and preference
- The hostnames that accept mail for the domain, each with a preference value, where senders try the lowest preference first and fall back on failure. A null MX, a single record of preference 0 pointing at a dot, declares that the domain sends no mail and accepts none (RFC 7505).
- SPF record and lookup count
- A TXT record starting with v=spf1 that lists which hosts may send for the domain. The mechanisms that trigger DNS queries, which are include, a, mx, ptr, exists, and redirect, are capped at ten in total (RFC 7208 section 4.6.4), and going over produces a permerror that breaks the record completely.
- SPF qualifier ending
- The last part of the record says what to do with mail from a server that is not listed. -all means fail, ~all means softfail, ?all is neutral and asserts nothing, and +all permits any sender and is always a misconfiguration.
- DMARC policy
- A TXT record at _dmarc that tells receivers what to do with mail failing the checks: p=none reports only, quarantine marks the mail, and reject throws it away. The record can also carry pct, the rua and ruf reporting addresses, and the alignment modes adkim and aspf.
- DKIM selector probe
- We query selector._domainkey.domain and report the key type, the flags, and whether the key was revoked with an empty p= tag. You have to supply the selector, because selectors are arbitrary and cannot be enumerated from DNS, and google, selector1 and selector2 are the common ones.
- Per-record verdict
- Each of MX, SPF, DMARC, and DKIM gets pass, warning, or fail with the reason stated. We do not combine them into one grade, because the failures are different in kind and you fix them separately.
Questions people ask
- What does the SPF ten-lookup limit mean in practice?
- Every include, a, mx, ptr, exists, and redirect in your record costs at least one DNS query, and includes nest, so one include of a large provider can consume four or five. Past ten, RFC 7208 requires a permerror, and receivers treat that as SPF failure. Flattening the record or removing unused vendors is the fix.
- Do I need DKIM if I already have SPF?
- Yes, if you want DMARC to survive forwarding. SPF breaks when a message is forwarded, because the forwarding server is not in your SPF record. DKIM signatures survive forwarding as long as the body and signed headers are unchanged, so DKIM is what keeps DMARC passing for mailing lists and forwarders.
- Is p=none good enough?
- It protects nobody. It only asks receivers to send you reports. It is the right first step, because the reports tell you which legitimate senders would break under enforcement, but leaving a domain at p=none for years means anyone can still spoof it.
- Why can you not list my DKIM records automatically?
- DKIM keys live at selector._domainkey.domain, and the selector is chosen freely by the sender. DNS has no way to list the names under a node without a zone transfer, which no public zone allows. So a selector has to be supplied or guessed from a common list.
- My domain sends no mail. What should I publish?
- A null MX record (preference 0, target a single dot) per RFC 7505, an SPF record of v=spf1 -all, and a DMARC record with p=reject. Together those tell receivers that no mail should ever come from the domain, which closes it off as a spoofing target.
Related
Last reviewed 2026-09-05.