Public-data research, published with its limits.
Vendor research is usually marketing with a chart in it. Ours might be too — you have no way to know from the outside, which is why the rules below matter more than the findings. Six commitments, what each one costs us, and the research we have ruled out no matter how good the numbers would look.
Six rules, and what each one costs.
A commitment with no cost attached is not a commitment. Each rule below makes this research less impressive than it could be — that is rather the point.
We will never publish research derived from customer data.
The commercial cost of this is real. Our customer base is the richest email-authentication dataset we will ever touch, and it would produce more interesting findings than a public DNS scan ever can. We scan the public internet instead, which is slower, less granular, and available to anyone who wants to check our work — including our competitors.
Everything we have published.
One edition, which is not much of an index yet. We are not going to inflate it with blog posts relabeled as research — when the second scan runs this becomes a trend line, and that is worth waiting for.
One email when the next edition publishes, with the trend line. It joins the field-notes list the footer offers — twice a month, one unsubscribe link — and gates nothing: the report and the dataset stay open either way.
DMARC field notes, twice a month, from PlatOps Security, LLC (Bethesda, MD). We use your address only to send it. Unsubscribe with one click in any issue. Privacy policy.
Things we want to measure and cannot yet.
These are the method’s own limits, published alongside the findings, not footnoted under them. If you know how to solve one from public data, we would like to hear from you.
DKIM under-counts: selector discovery from DNS alone is unsolved. We probed only common selectors (default, google, selector1, selector2, k1, s1), which gives a lower-bound ~51% signal — not a real adoption number, and kept out of every headline stat.
p=none reflects a state, not an intent: a domain could be newly monitoring or permanently parked at p=none. We report what is published, not why.
MTA-STS and BIMI are checked at the DNS layer for every domain; the HTTPS policy fetch (enforce/testing mode, VMC/SVG validity) only ran for the subset of domains that already publish the DNS record.
This is a single snapshot (Tranco JZ2VY, 2026-07-01), not a trend line. We plan to re-run this scan annually to track change over time.
8,907 of the top 10,000 domains resolved (89.1%). The remaining 10.9% timed out, had no DNS records, or were parked/unregistered at scan time and are excluded from every percentage.
SPF's real deliverability impact depends on mail-flow telemetry we do not have from public DNS alone — we report record presence and qualifier strength, not pass/fail rates.
Use it without asking.
The full aggregate dataset behind the 2026-07-01 snapshot is public. Cite it, chart it, or reproduce our numbers — attribution to DDMARC is all we ask, and there is no form between you and the file.
- Population
- Tranco top 10,000
- Resolved
- 8,907 / 10,000 (89.1%)
- Snapshot
- Tranco JZ2VY
- Pinned
- 2026-07-01
Retrieve the same list and the scan is reproducible. That is the point of naming it.
Your own domain is one of the numbers above.
68.2% of the top 10,000 publish DMARC and 0.7% run the complete stack. The free checker tells you which side of both numbers you are on.