Is your own zone asking receivers to throw your mail away?

What this actually does

It reads three things out of public DNS the way a receiving mail server would: your SPF record, a DKIM key under nine common selectors, and your DMARC policy. DMARC passes when SPF aligns or DKIM aligns, so a domain with neither published fails everything it sends — and under p=reject or p=quarantine, its own zone is what asks receivers to act on that.

Six domains in this estate were in exactly that state for months, and nothing anywhere was red. That is why this page exists rather than a blog post about it.

What it does not do

• It records nothing. No row, no analytics event, no counter keyed by a domain. The endpoint is public — you can call it with curl and read what it does, which is the only reason that sentence is worth anything.
• It cannot prove a DKIM key is absent. A key is only findable by name, and this asks nine common selectors. “No key found” means none of those.
• It cannot tell you whether your SPF record covers the host actually sending. That needs every nested include resolved and the provider’s current egress. A DKIM key on the apex is provable from outside; SPF alone is not, and it is reported as its own state rather than counted as authentication.
• It is a reading, not a standing fact. A zone can be edited a minute after you check it.

Run it yourself

The same check, with no toolchain and no relationship with us — one file, no dependencies:

npx @flashyos/mail check yourcompany.com

It is the same implementation this page calls, and the same one our own control plane runs — a differential test fails the build if the two ever disagree about a verdict. A checker whose public answer and private answer could differ is worse than no checker.