Check your domain’s email health

This page reads a domain’s email setup exactly as it is published in DNS and tells you what is missing or weak. You type a domain, say yourdomain.com, and in a few seconds you see the state of SPF, DKIM, DMARC, the mail servers, encryption in transit and whether the domain shows up on any blacklist. No sign-up, nothing to install.

Before you type anything, the part that matters: you are not entering something of yours here, you are entering a domain. The lookup is made by my server against public DNS and against the domain’s mail servers, the same way any system about to send it mail would. Nothing you check is stored.

Check your domain

Type the domain and hit analyze. Below I explain what each check looks at and how to read the result, because some warnings are easy to misread.

What each check looks at

The first three are the ones that decide whether your mail arrives and whether anyone can forge it:

• SPF says which servers are allowed to send on behalf of your domain. The tool also counts the lookups it chains, because SPF has a limit of ten and going over it breaks the whole thing, a very common and silent failure.
• DKIM is the signature that travels with every message. Since that signature lives under a selector only the sender knows, the tool probes the most common selectors. If you use your own and it does not show up, it does not mean it is missing: it means it is not among the common ones.
• DMARC is the rule that tells the receiver what to do when a message claims to come from your domain but passes neither SPF nor DKIM. It is the piece that actually stops spoofing, and the one most people leave half done.

The rest are reinforcing layers the analysis also flags: the MX records and whether their servers answer, TLS encryption on delivery, MTA-STS and DNSSEC so that encryption cannot be downgraded, CAA to control who can issue certificates for your domain, and reputation blacklists.

The DMARC warning worth not ignoring

If the result flags DMARC at p=none, it means the record exists but asks the receiver to do nothing: mail spoofing your domain still gets through. none is the first rung, not the destination. The full path is none to observe, quarantine to send what fails to spam, and reject to turn it away at the door, and you climb each rung by reading the reports DMARC itself sends you.

That gap is not theoretical. I wrote up a real case where a message spoofing a company’s own domain got through despite MFA, and the only thing standing between it and being blocked was that one line in DNS. If this tool hands you p=none, that article explains exactly what you are looking at and how to climb the rungs without cutting off your legitimate mail.

What to do with the result

1. Start with whatever is red. An SPF that blows past the ten-lookup limit or a DMARC at none weigh far more than a missing BIMI.
2. Fix one thing and analyze again. DNS changes take time to propagate, so do not expect to see them instantly: give it a few minutes and re-run the check.
3. With DMARC, go one rung at a time. Do not jump from none straight to reject. Pass through quarantine first and read the reports for a few weeks so you do not knock out legitimate mail.

What happens to what you type here

The analysis is anonymous: you type a domain, it is checked on the spot and nothing is stored. No email, no sign-up.

Below the result there is an optional extra: an AI-written summary that also arrives as a PDF. That one does ask for your email and sends you a code to verify it, because the report is emailed to you. That address is kept only to send it and deleted after 90 days. If you just want the diagnosis, leave that part alone: the analysis above already gives you everything and leaves no trace.

And if you would rather not type anything into a tool that is not yours, everything you see comes from DNS queries and a connection to port 25: you can reproduce it from any terminal with dig and openssl s_client.