Type a domain. This reads the public DNS records that decide whether a forged message claiming to be from you reaches an inbox — SPF, DKIM, DMARC and MTA-STS — walks your whole SPF include chain against the limit of 10 lookups, and tells you exactly what to change. No signup, nothing to install.
The spec caps an SPF record at 10 DNS lookups. Past that, receiving servers are required to return a permanent error and most treat it as no SPF at all. Nothing bounces. It happens gradually — Microsoft 365, then a CRM, then a marketing tool — and the day it tips over, nothing tells you.
p=none is a monitoring stage: it asks receivers to report on failing mail and deliver it anyway. A domain sitting there has a DMARC record and no protection, which is the most common state we find and the easiest to mistake for being done.
Signing is off by default on some tenants and gets skipped at migration. Without it, any mail that gets forwarded fails authentication — because forwarding breaks SPF and DKIM is the only thing left to carry the message.
The end of this road is invoice-redirection fraud: a message that looks like it came from a director or a supplier, landing in a real mailbox, asking for banking details to be updated. Every control above is DNS configuration, not a product you have to buy. Check the domain registration itself for the other half — expiry, transfer lock and delegation.
Email security FAQ
It reads the public DNS records that control who is allowed to send email as your domain: your MX records, your SPF record (including every include: it chains to), your DMARC policy at _dmarc, DKIM keys at the selectors your mail provider uses, and whether the zone is DNSSEC-signed. Everything it reports comes from public DNS — the same records any receiving mail server reads before deciding what to do with a message claiming to be from you.
No. There is nothing to install, no mailbox to connect, and no login. Every record checked is public by design — that is how email authentication works. You can run the check against any domain, including a competitor's or a supplier's.
The SPF specification caps a record at 10 DNS lookups. Go over and receiving servers are required to return a permanent error, which most treat as though you had no SPF record at all. Nothing bounces and nothing warns you — mail simply loses its authentication. It happens quietly to businesses that add sending services over time: Microsoft 365, then a CRM, then an email marketing tool, then a ticketing system. This tool walks the whole chain and shows which include is spending your budget.
Only if your provider issues fixed selector names. DKIM selectors cannot be listed from DNS; you can only test names you already know. Microsoft 365 always uses selector1 and selector2 and you cannot change them, so nothing there is conclusive evidence signing is off. Google Workspace, Proofpoint, Mimecast and Zoho all let you name the selector, so a miss on those means "not found at the common names" — which the result says explicitly rather than overstating.
They are the instruction your DMARC record gives receiving servers about mail that fails authentication. p=none means deliver it anyway and just report — it is a monitoring stage that blocks nothing. p=quarantine means send it to junk. p=reject means refuse it outright. Most domains that "have DMARC" are sitting on p=none, which is why publishing a record is not the same as being protected.
It means someone can send email that appears to come from your domain and have it delivered to a real inbox. In practice that is how invoice-redirection fraud starts: a message that looks like it is from a partner or a director, arriving in a staff mailbox, asking for banking details to be updated. The fix is DNS configuration rather than new software, and for most small offices it is an afternoon of work followed by a few weeks of watching reports before tightening the policy.
Yes. Email authentication is part of every managed IT engagement we run, and we also do it as a standalone piece for businesses who are otherwise happy with their IT. The work is publishing and consolidating the records, enabling DKIM at your provider, moving DMARC from monitoring to enforcement in stages, and reading the aggregate reports along the way so no legitimate sender gets caught.
No. The domain is not written to our analytics, not logged against a visitor, and not retained after the result is returned. Results are held briefly in a shared memory cache so that checking a popular domain twice does not repeat the lookups, and that cache holds only the public DNS answers — never who asked.