DMARC enforcement gap 2026: 68% of company domains still non‑enforcing
DMARC enforcement gap 2026: 68% of company domains still non‑enforcing
DMARC enforcement remains low 14 years after its introduction
68 % of the 67 k company domains surveyed either lack a DMARC record or publish a p=none policy, meaning they do not request quarantine or rejection of unauthenticated mail. This matters because without enforcement, DMARC cannot stop domain‑spoofing attacks, even though the standard has been publicly available since 2012.
Most domains still do not enforce DMARC
- 45 % (30 362) of the domains have no DMARC record at all.
- 23 % (15 709) publish
p=none, which only collects reports. - Only 16 % (10 963) enforce
p=rejectand 15 % (10 258) enforcep=quarantine. - Combined, 68 % (46 071) of all domains either lack a record or use
p=none, the non‑enforcing state.
"Publishing a DMARC record is no longer the main adoption gap; moving from monitoring to enforcement is." – CipherCue analysis
Why the large p=none share persists
The primary obstacle is report‑address fragmentation. Every domain that enables DMARC reporting (rua=) receives daily aggregate reports listing every source that claims to send mail for that domain. To move to enforcement, administrators must review each source and decide whether it is legitimate.
- We extracted 26 179
rua=entries from 36 974 DMARC records and identified 10 268 distinct reporting domains. - 79 % (8 113) of those appear only once, often as obscure, hashed mailbox names (e.g.,
a.8hyzr404@sdmarc.net). - The long tail of one‑off addresses forces admins to manually match IPs and sender strings to real services, a research‑level task that is frequently deprioritised.
"An administrator staring at a week of these reports is not looking at a vendor list; they are looking at a pile of IP addresses and sender strings with no obvious owner." – CipherCue analysis
Who runs the DMARC monitoring ecosystem?
Mapping rua= destinations to known vendors reveals a fragmented market:
| Vendor | Identified entities | Share of identified reporting destinations |
|---|---|---|
| Brevo (Sendinblue) | 1 297 | 14.6 % |
| Proofpoint | 1 094 | 12.3 % |
| Valimail | 1 068 | 12.1 % |
| Cloudflare | 978 | 11.0 % |
| DMARC Analyzer | 602 | 6.8 % |
| dmarcian | 584 | 6.6 % |
| … | … | … |
When limited to vendors whose core product is DMARC monitoring (Valimail, DMARC Analyzer, dmarcian, DMARC Advisor, EasyDMARC, Red Sift, PowerDMARC, Fortra/Agari), they account for 3 619 of the 8 862 identified entities (40.8 %). Valimail is the single largest player at 29.5 % of that subset, but no vendor holds a majority.
Enforcement varies by country
| Country | No DMARC record | p=none |
p=quarantine |
p=reject |
|---|---|---|---|---|
| Poland | 64.6 % | 16.3 % | 11.3 % | 7.7 % |
| Netherlands | 51.1 % | 21.1 % | 14.2 % | 13.6 % |
| Germany | 45.7 % | 26.3 % | 12.9 % | 15.0 % |
| United States | 42.1 % | 19.0 % | 16.7 % | 22.2 % |
| United Kingdom | 37.0 % | 19.2 % | 18.3 % | 25.5 % |
| Italy | 40.9 % | 36.8 % | 11.7 % | 10.5 % |
The US and UK have the highest enforcement (p=reject) rates, while Italy shows the largest p=none share, suggesting many Italian domains have begun monitoring but have not progressed to enforcement.
DMARC in the broader email‑security landscape
| Control | Presence in the 67 336‑domain cohort |
|---|---|
| SPF | 48 962 (72.7 %) |
| DMARC | 36 974 (54.9 %) |
| BIMI | 1 726 (2.6 %) |
| MTA‑STS | 957 (1.4 %) |
| DNSSEC (full‑chain validated) | 0 (0 %) |
SPF is the most common because it requires only a single TXT record. DMARC adoption lags behind, and advanced controls like BIMI and MTA‑STS remain under 3 %.
Recent RFC changes do not affect adoption barriers
In May 2026 three RFCs replaced the original RFC 7489:
- RFC 9989 – core DMARC protocol (Standards Track).
- RFC 9990 – aggregate reporting (
rua=). - RFC 9991 – failure reporting (
ruf=).
The new specs keep all existing tags (v=, p=, sp=, rua=, etc.) unchanged. The only substantive change is how receivers locate the organisational domain: a DNS‑tree walk replaces the Public‑Suffix‑List lookup. These changes do not impose new configuration steps for domain owners.
Compliance frameworks do not mandate DMARC
- SOC 2: Trust Services Criteria are risk‑based; DMARC is not listed as a required control.
- ISO 27001:2022: Annex A control 5.14 (Information Transfer) is broad enough to cover email authentication, but does not specifically name DMARC.
Thus, many organisations may skip enforcement because it is not a formal audit requirement.
Real‑world example: a multi‑vendor rua= setup
The UK food producer cranswick.co.uk publishes a DMARC record with p=none and three distinct rua= destinations:
dmarc_agg@vali.email(Valimail)eu.cp-dmarc.com(self‑hosted mailbox)rua@easydmarc.eu(hashed address)
Reconciling three separate report streams illustrates the manual effort required before a domain can safely move to p=quarantine or p=reject.
Practical steps for organisations stuck at p=none
- Consolidate reporting – Use a service like SenderLedger to aggregate and label senders from raw DMARC reports.
- Identify legitimate sources – Map IPs and mailbox identifiers to known vendors or internal systems.
- Iteratively tighten policy – Start with
p=quarantinefor a subset of senders, monitor false positives, then expand top=reject. - Document the process – Treat the analysis as a risk‑assessment activity, which can satisfy SOC 2 or ISO 27001 auditors.
Community reactions on Hacker News
- @smartmic wonders about the benefit of DMARC on top of SPF/DKIM, highlighting a knowledge gap.
- @tgv points out that small orgs often copy‑paste DNS records without understanding, leading to default
p=nonepolicies. - @jwr argues that major providers (Google, Microsoft) ignore abuse reports, making enforcement feel futile.
- @rft notes that many surveyed domains may not even host mail (no MX record), suggesting a more relevant metric would be “domains that actually send/receive mail”.
- @datakan expresses surprise at the high 68 % non‑enforcement figure.
- @cheema33 shares a success story where an LLM (Claude) automated DMARC deployment via Terraform, hinting at emerging tooling to lower the adoption barrier.
These comments reinforce the article’s conclusion: the technical hurdle of interpreting DMARC reports, not mere ignorance, is the dominant factor keeping most domains in a non‑enforcing state.
Methodology snapshot
- Data source: Direct DNS queries performed by CipherCue between 2026‑04‑14 and 2026‑07‑28.
- Cohort: 67 336 domains associated with tracked corporate entities (not a random global sample).
- Vendor mapping: Manual dictionary of 40 known
rua=domains; identified 8 862 reporting entities (floor estimate). - DNSSEC check: Requires full signing‑chain validation; zero domains passed this strict test.
The numbers represent a snapshot of CipherCue’s observed cohort, not a definitive global census.
Takeaway: Even after 14 years, the majority of corporate domains either lack DMARC or remain in the monitoring‑only phase because the effort to parse and act on aggregate reports is non‑trivial. Consolidating reporting, automating sender identification, and treating policy tightening as a risk‑management activity are essential to bridge the enforcement gap.
References
- RFC 9989, RFC 9990, RFC 9991 (2026) – core DMARC specifications.
- RFC 7489 (2015) – original DMARC informational RFC.
- RFC 8461 (2018) – MTA‑STS standard.
- ISO 27001:2022 Annex A control 5.14.
- AICPA Trust Services Criteria (SOC 2).