How we test
What each check looks at, the standards behind it, how results are graded, and the limits of a DNS-only check. If you think a result is wrong, we want to know.
Last reviewed 7 October 2026
How a check runs
Every check runs in your browser. Your browser sends ordinary DNS queries over HTTPS (RFC 8484) to Google Public DNS, with Cloudflare DNS as a backup, and our code interprets the answers on your device. Nothing is sent to our servers, so we can’t see or store the domains you check. Because the answers come from the same public resolvers most of the internet uses, you see what receiving mail servers are likely to see.
What we check, and the standards we follow
The references below are RFCs (“Requests for Comments”): the official technical standards for the internet, published by the Internet Engineering Task Force (IETF) and followed by every major email provider. Each one links to the full, free text.
| Area | What we test | Standard |
|---|---|---|
| Mail servers (MX) | MX records exist and resolve to addresses; no records point at raw IP addresses; backup servers; IPv6; reverse DNS names; “null MX” for domains that don’t receive email | RFC 5321, RFC 7505 |
| SPF | Exactly one record; valid syntax; every include resolves; the 10-lookup limit, counted through nested includes and redirects; empty (“void”) lookups; loops and duplicates; the ending (-all, ~all, ?all, +all) | RFC 7208 |
| DKIM | Public keys at common selectors for the detected provider, or a selector you enter; keys reached through CNAME records; key type and approximate length; revoked or broken key records | RFC 6376, RFC 8463 |
| DMARC | Exactly one record; a valid policy; percentage and subdomain policies; inheritance from the parent domain; report addresses, including permission for reports sent to another domain; alignment settings | RFC 7489 |
| DNSSEC | Whether the domain is signed (a DS record at the registry) and whether answers validate | RFC 4033–4035 |
| Secure delivery | MTA-STS and TLS reporting records, and an optional BIMI brand logo record | RFC 8461, RFC 8460 |
| Header analyser | Authentication results recorded by the receiving server, DMARC alignment between the From address and the SPF or DKIM domain, forwarding (ARC), spam scores and delivery delays | RFC 8601, RFC 8617 |
We also reflect the published sender requirements of Gmail, Yahoo and Outlook.com, which expect SPF, DKIM and a DMARC record from anyone sending email to their users at volume.
How results are graded
- Problem: something that stops email working or leaves the domain open to spoofing, such as no DMARC record, a broken SPF record or no working mail servers.
- Needs attention: it works today but carries a real risk, such as DMARC on monitor only, an SPF record close to the lookup limit or a weak signing key.
- Not confirmed: we couldn’t verify something from outside, usually a DKIM key under a custom name. We say so rather than guess.
- Information: optional improvements, such as DNSSEC or MTA-STS. These never lower your verdict.
The headline verdict reflects the most serious finding, and the “Fix this first” list puts the changes with the biggest effect at the top. DNS housekeeping details (name servers, SOA values) are shown to IT teams but never affect the verdict, because they rarely affect email.
What a DNS-only check can’t see
- Your mail servers in action. We don’t connect to mail servers, so we don’t test SMTP banners, TLS certificates or open relays.
- Blocklists. The major blocklists restrict commercial use and refuse queries from public DNS resolvers, so a browser-based check would give unreliable answers. We don’t show blocklist results rather than show misleading ones.
- Custom DKIM selectors. They can’t be listed from outside. If yours isn’t found, enter it in the selector box.
- Registry delegation. We see the name servers your DNS host publishes, not a direct query to the registry.
- Delivery itself. Inboxes also judge reputation and content. A clean report means your setup is right, not that every message will reach the inbox.
Keeping it accurate
Every change to the checks is tested against a library of real-world configurations, including broken ones, before it goes live. Fix guides show the date they were last reviewed, and we update them when providers change their admin screens or requirements.
Report a problem
If a result looks wrong, email hello@mailhealthreport.com with the domain and what you expected to see. Results from public DNS are public information, so sharing the domain is safe.