Article URL: https://ciphercue.com/blog/dmarc-enforcement-gap-rua-fragmentation-2026 Comments URL: https://news.ycombinator.com/item?id=49081783 Points: 9 # Comments: 3

DMARC has existed since 2012. It is a free DNS record that tells receiving mail servers what to do with email that fails to authenticate as coming from your domain: report it, quarantine it, or reject it outright. It is primarily concerned with unauthorised use of a domain in the visible From address; it doesn't stop lookalike-domain registrations, display-name spoofing, or a phishing email sent from a compromised legitimate account. Fourteen years on, we checked the DNS records for 67,336 domains in CipherCue's tracked entity set between 2026-04-14 and 2026-07-28. This is a snapshot of CipherCue's dataset, not a statistically representative sample of every company worldwide; the method note below covers how the cohort is built. 30,362 of them (45.1%) still don't have a record. The domains that do have a record are not much further along. Only 10,963 (29.7% of domains with a record) actually enforce anything: p=reject, mail that fails authentication gets dropped. 10,258 (27.7%) sit at p=quarantine, junk folder but not blocked. The largest single group, 15,709 domains (42.5%), is set to p=none. A p=none policy collects authentication data and aggregate reports but does not ask receiving mail systems to quarantine or reject messages that fail DMARC. In this analysis, enforcement means a published policy of p=quarantine or p=reject; domains using p=none are counted as non-enforcing. p=none is meant to be a temporary monitoring phase before you move to enforcement, typically a few weeks. Fourteen years after the standard shipped, for the largest single group of domains in our data, it looks like the permanent state. Put the two together and the picture is starker than either number alone: of all 67,336 domains we checked, 46,071 (68.4%) either have no DMARC record or have one that doesn't enforce a policy. Publishing a DMARC record is no longer the main adoption gap in this dataset; moving from monitoring to enforcement is. The usual explanation is inertia or ignorance. Our data points at a more specific, more mechanical cause: nobody can tell what's actually sending the mail. Every domain with DMARC's reporting flag on gets daily aggregate reports (rua=) listing every source that sent mail claiming to be from that domain, whether it passed authentication or not. Moving to enforcement means going through that list and deciding, source by source, "yes, that's meant to be us" or "no, block it." We pulled the raw rua= addresses out of 36,974 DMARC records and counted where the reports actually go. Some of that concentrates in a few obvious places: Proofpoint's own reporting endpoint appears 1,605 times, Cloudflare's 1,273 times, dmarcian's various regional endpoints (ag.eu.dmarcian.com, ag.us.dmarcian.com, and eight more country-coded variants) add up to over 1,000 between them, and Brevo, Postmark, Barracuda, and a scatter of DMARC-as-a-service vendors (EasyDMARC, PowerDMARC, dmarcian, Red Sift, DMARC Analyzer, dmarcly, sdmarc.net, hornetdmarc.com) fill out most of the rest. But the long tail is the finding. Once you get past roughly the top 60 domains, the addresses stop being recognisable vendors and start being one-off, often hashed, mailbox names: ivrejeuw@ag.c1.dmarcian.com, a.8hyzr404@sdmarc.net, 2fa9a7572f@rua.easydmarc.eu, a company self-hosting reports at its own domain (dmarc@axa.com, rua@lseg.com), or a mailbox that gives no clue at all (watchdog@watchdog.kevlarr.io). 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, and deciding whether to enforce means identifying every one of them first.