111 of 275 domains fail a check that no single-record tool performs
On 6 September 2026 this company read the SPF and DMARC records of 275 organisation domains, live, on two independent resolvers, and compared the two records against each other rather than grading each one on its own. 111 of the 275, or 40.4 per cent, carry at least one defect that is invisible unless the two records are read together. Every count on this page came out of our own instrument in a single pass; 275 of 275 reads returned and none errored.
What was counted
| Finding | Domains of 275 | Why it matters |
|---|---|---|
dmarc_policy_is_monitor_only | 95 (34.5%) | A DMARC record is published at p=none while an SPF record is also published. p=none asks receivers to take no action on a failure, so the SPF record is being used for observation, not enforcement. Normal during a rollout; a defect only where enforcement was intended. RFC 7489 section 6.3. |
dmarc_without_aggregate_reporting | 93 (33.8%) | A DMARC record is published with no rua tag, so the domain owner is sent no aggregate reports and nothing tells them which of their own mail streams fail authentication, or what a policy change would break before they make it. RFC 7489 section 7.2. |
spf_over_lookup_limit_under_enforcing_dmarc | 2 (0.7%) | The SPF record costs more than ten DNS lookups while DMARC is published at quarantine or reject. An over-limit evaluation returns permerror, which is not a pass, so SPF cannot supply the aligned pass and the mail rests on DKIM alone under a policy that acts on failure. RFC 7208 sections 4.6.4 and 2.6.7, with RFC 7489 section 4.2. |
enforcing_dmarc_with_no_spf | 2 (0.7%) | DMARC is published at reject and no SPF record is published at all. There is no SPF result to align, so every message the domain sends must carry an aligned DKIM signature or be rejected by any receiver that honours the policy. RFC 7489 section 4.2, with RFC 7208 section 4.3. |
The two records the population publishes
| DMARC | Domains |
|---|---|
| no DMARC record at all | 139 |
| p=none | 98 |
| p=quarantine | 23 |
| p=reject | 15 |
| SPF | Domains |
|---|---|
| a single record, inside the lookup limit | 188 |
| no SPF record published | 52 |
| at eight or more of the ten permitted lookups | 22 |
| over the ten-lookup limit | 9 |
| more than one SPF record published | 3 |
| the two resolvers did not agree | 1 |
How it was read
Each domain was read once through the email_auth_check tool on this company's own MCP server. That tool queries the SPF record at the domain and the DMARC record at _dmarc.<domain> on Cloudflare 1.1.1.1 and Google 8.8.8.8 and claims nothing where the two resolvers disagree. The cross-record findings are computed from those two readings and from nothing else. The same reading is free for any domain, with no account and no key.
What this does not claim
- This is not a sample of the web. The 275 are US chamber-of-commerce and local-association domains that this company already publishes readings for, chosen before any of these findings existed. A different population would give different numbers.
- DKIM was not read here, so nothing on this page can say whether a domain that has no usable SPF is nonetheless signing its mail and passing DMARC that way. That is the single most important limit on the two severe findings.
- No organisation is named. The records are public and every one of the 275 has its own reading on this site, but a page listing live defects beside the names of the organisations that have them would be a wall of shame, not a measurement.
- DNS changes. Each number is what was published on 6 September 2026 and nothing here has been re-read since.
Read your own domain
The same cross-record analysis runs on any domain, free: the whole SPF and DMARC reading on one page, the lookup counter, the record check. If a reading finds something and you want it written up against the clauses it breaks, the written audit of one domain is $29.