About

A free set of email authentication tools, built because the existing free checkers tell you what is broken and stop there.

What we found when we measured it

In August 2026 we scanned every domain in the Y Combinator company directory — 6,157 domains — reading each one's public DNS records directly, and repeated the whole scan on 3 September. 60.5% of them can be email-spoofed today: they publish no DMARC record, or one set to p=none, which asks receivers to do nothing. Nearly a third are at p=none specifically, which means somebody set DMARC up and stopped one setting short of the one that protects them.

The finding we did not expect is that it has not improved. A company founded in 2025 is as likely to be spoofable as one founded in 2013, and the newest arrivals are worse than the population they join. Enforcement is not something organisations grow into; it happens when somebody decides to do it.

Both runs are published in full, with the method, the exclusions and every row we corrected by hand: the study, and the raw CSVs under CC BY 4.0. Failed lookups are reported as unknown and excluded from the percentages rather than counted as absent — that single distinction moved the headline figure by four and a half points, which is roughly the size of the error in a scan that treats a DNS timeout as a missing record.

Why it exists

Since February 2024, Google and Yahoo have required SPF, DKIM and DMARC from anyone sending them mail in volume. A lot of organisations discovered at that point that they had no idea what any of those were.

There is no shortage of tools that will tell you your SPF record exceeds the ten-lookup limit. There are very few that hand you a corrected record. That gap is the whole reason this exists: every finding here ends in something you can publish or a specific action, not a description of the problem.

What it checks

• Domain checker — SPF (with full include-chain evaluation and lookup counting), DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and DNSSEC.
• Header analyzer — the delivery path and hop delays of a specific message, and why DMARC passed or failed. Runs entirely in your browser.
• Sending IP checker — 8 blocklists and forward-confirmed reverse DNS.
• JSON API — all of the above, no key required.

What it deliberately will not tell you

Overclaiming is how tools in this space lose trust, so these limits are stated here as well as in the results:

“No DKIM found” is not proof that DKIM is missing

Selectors cannot be listed from DNS. We try 50 common ones and say so. Some providers — Amazon SES among them — use random selectors that are unguessable by construction.

SPF lookup counts are worst-case

A real evaluator stops at the first match, so a sender listed early may never reach term eleven. We count the full walk, because the sender that breaks is the one in the last include.

SPF macros are counted but not resolved

Terms like exists:%{i}… expand using the connecting server's address. There is no honest static answer, so they are reported as unevaluable rather than guessed.

A refused blocklist query is never reported as “not listed”

Some lists decline queries under certain conditions. When that happens you get “unknown”, because a false all-clear on a tool people reach for mid-incident is worse than no answer.

A clean result is not a guarantee of delivery

Dozens of private blocklists exist, and every mailbox provider runs internal reputation scoring that is invisible from outside. This checks configuration, which is necessary but not sufficient.

What it records about you

No cookies, no third-party scripts, no advertising, no accounts. The pages load no JavaScript at all except the header analyzer, which needs it to parse in your browser.

The domains, headers and addresses you check are never stored. Header analysis never leaves your browser at all, and the domain you type into the checker is used to make DNS queries and then discarded — it is not written to any log, counter or database, and it is not sent to the analytics described below.

Two things do get written down, and both live on this same server.

Daily counters. How many times each page was viewed and how many checks ran, as running totals per day. No addresses, no identifiers, nothing per visitor. Kept for 90 days.

A self-hosted Umami instance for a more detailed breakdown than a counter can give. It runs on this server, not a third party's — no data goes to Google, Cloudflare or anyone else — and because this site loads no analytics script, the page view is reported by the server rather than by your browser. That is why there is no cookie and nothing to consent to. For each page view it records:

• the page, and campaign tags (utm_source and similar) if the link you followed had them
• the site you arrived from, and its path — never its query string
• your browser, operating system and device type
• your approximate location, derived from your IP: country, and usually region and city
• a visit identifier, which is a hash of your IP address and browser string

Your IP address itself is not stored. It is used to work out the country and to compute that hash, and then dropped — there is no column for it. But the hash is stable rather than rotating, so two visits from the same network and browser are recognisable as the same visitor over time. That is a pseudonym, not anonymity, and it would be dishonest to describe it as the latter.

You do not have to take any of this on trust. The whole site is open source under the MIT licence. The counters are in stats.ts and everything sent to Umami is in umami.ts — two files, both short. What no public repository can prove is that the running server matches the published code. It does mean the claim is specific enough to be checked, and wrong enough to be called out if it were false.

That is not a hypothetical. Referrer URLs were being forwarded to Umami complete with their query strings, so a visitor who moved from a result page to a guide handed over the domain they had just checked — contradicting the promise at the top of this section. It was found on 3 August 2026, fixed the same day, and the affected rows were deleted. It is written up here rather than quietly corrected because a privacy page that only ever reports good news is not worth reading.

Reporting a wrong result

Please do. Correctness is the entire value here, and a checker that is confidently wrong is worse than no checker. Several bugs have already been found by pointing the tools at domains whose real configuration was known.

Email hello@notspoofed.com with:

• the domain, IP or headers you checked;
• what the tool said;
• what you believe the correct answer is, and how you know.

That last line matters most — the useful reports are the ones that say “the record actually reads X, here is the dig output”.

Who runs it

One person — Jose Pollman — independently, on a single server. It is not backed by a vendor and does not sell your results to one. There is no upsell in the findings: where a commercial product genuinely is the right answer — DMARC report monitoring, for instance — it says so plainly rather than steering you somewhere.

The checks are built directly against the RFCs (7208 for SPF, 6376 for DKIM, 9989 and 9990 for DMARC, 8461 for MTA-STS) and tested against a corpus of real domains whose configuration is verified independently. DMARC moved to 9989 in May 2026, which deprecated pct=, added np= and t=, and replaced the Public Suffix List with a DNS tree walk — the checks follow it rather than the superseded RFC 7489.

Written elsewhere

Two pieces that cover the reasoning behind the tools at more length than a results page can:

• How to Check If Your Domain Can Be Spoofed (SPF, DKIM, DMARC) — what each record actually proves, and the order to fix them in.
• The DMARC Check That Only Asks Whether a Record Parses — why most free checkers report a green tick for a record that protects nothing.

Contact

hello@notspoofed.com — bug reports, corrections, and requests for a higher API rate limit if you are building something.