Find out why your email is failing authentication
Enter a domain. We read its public DNS records and tell you exactly what to publish to fix what's broken — not just that something is.
What this checks
- SPF, counted properly
-
SPF permits ten DNS lookups and no more. Past that, receivers give up and
your record stops working — silently, with no bounce and no warning. We walk
the whole
include:chain, followredirect=, and show you the count. If you're over, we generate a corrected record that flattens only the includes it has to. - DKIM, without inventing selectors
- Selectors can't be listed from DNS, so every checker guesses. The catch is that some domains answer every DNS query, which makes careless tools report keys that don't exist. We verify each hit is genuinely a signing key, and tell you plainly that a miss isn't proof DKIM is absent.
- DMARC, including where your reports actually go
- We check policy inheritance for subdomains, and whether third-party report addresses are authorised to receive your data. That last one catches a failure most tools miss entirely: a DMARC record that looks perfect while the reports go nowhere.
Why bother
Since February 2024, Google and Yahoo require SPF, DKIM and DMARC from anyone sending them bulk mail. Domains that don't comply get throttled or rejected, and the failure is usually invisible from the sending side — your mail simply stops arriving.
Authentication is three of the nine things they ask for. The Gmail and Yahoo compliance checker runs the whole list — and says plainly which requirements no domain-only check can confirm, instead of showing a green tick for something it never verified.
If a message failed DKIM and you do not know which selector signed it, the DKIM selector finder tests the names every major provider publishes and reports the key it finds — including whether it is revoked, in testing mode, or too small.
Our research
We scanned every company in the Y Combinator directory — 6,157 domains — to see how many can be email-spoofed, then did it again three weeks later. 60.5% can, and the rate has been flat since 2011: a company founded in 2025 is no more protected than one founded in 2013. The full dataset is published under CC BY 4.0.
Already have a failing message?
The header analyzer takes the raw headers from a message you received and shows the delivery path, where it was delayed, and why DMARC passed or failed — including the case where SPF passes but for the wrong domain, which is the reason most "we have SPF" domains still fail. It runs entirely in your browser; nothing is uploaded.
Guides
If you already know what is broken and want to understand it before you change DNS, these start from the problem and end with the record:
- Someone is sending email as my domain
- How to check if your domain can be spoofed
- SPF: too many DNS lookups
- Google and Yahoo sender requirements: a pass/fail checklist
- SPF: should it end in ~all or -all?
- 554 5.7.5 permanent error evaluating DMARC policy
Why a message bounced
A bounce quotes an SMTP code and a line of provider text, and the two rarely mean the same thing. These decode the ones we see most, each with the fix and who has to make it:
- Microsoft 5.7.606 — your sending IP is blocked
- Mimecast rejected your message
- Outlook S3150 — blocked by reputation
- Microsoft 5.7.23 — SPF validation failed
- 5.1.2 — the recipient domain does not resolve
- 550 5.1.1 — no such user
Common questions
- How do I check if my domain can be spoofed?
- Enter your domain above. It reads your public SPF, DKIM and DMARC records and tells you exactly which record to publish to close any gap that lets someone else send mail as your domain.
- Is it free, and is there a limit?
- Free, with no account and no ads. There is one limit and it is technical rather than commercial: 10 checks a minute from the same IP address, because each check makes around fifty DNS queries. No paid tier lifts it.
- Do you record the domains I check?
- No. A check is a read-only lookup of public DNS records, and the domain is not written down. Pasted email headers never leave your browser at all — the header analyzer parses them locally.
- Why does another checker say my DKIM is fine when this one does not?
- Usually wildcard DNS. Some domains answer every possible query, so a checker that treats any answer at selector._domainkey as proof will report keys that do not exist. This one verifies each hit is a genuine signing key, and says a miss is not proof DKIM is absent rather than guessing.
Try one of these
- lyft.com — SPF over the lookup limit
- paypal.com — a fully configured domain
- example.com — wildcard DNS that fools other checkers