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.
42.5% of domains with a DMARC record are still at p=none, collecting reports but not requesting quarantine or rejection, as of our most recent observation window
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.
68.4% of all domains checked have no DMARC record, or have one that does not enforce a policy (no record: 45.1%; record present but p=none: 23.3% of the total)
The policy breakdown, in full
10,258
p=quarantine
15.2%
Share of all 67,336 domains checked, not just those with a record
| State | Domains | Share of all checked | Share of domains with a record |
|---|---|---|---|
| No DMARC record | 30,362 | 45.1% | n/a |
| p=none (monitor only) | 15,709 | 23.3% | 42.5% |
| p=quarantine | 10,258 | 15.2% | 27.7% |
| p=reject (full enforcement) | 10,963 | 16.3% | 29.7% |
Why p=none doesn't move
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.
10,268 distinct rua= reporting domains found across 26,179 reporting-address entries; 8,113 of them (79%) appear in our data exactly once
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.
That is a research task, not a configuration change, and it is the kind of task that gets deprioritised indefinitely. We think it is the largest single reason the p=none number above is as high as it is.
Who runs DMARC monitoring
We mapped the rua= reporting-address domains against a vendor dictionary covering the DMARC-monitoring and mail-infrastructure products we could confidently identify. This is a different, broader measurement than matching against a single fact type: it picks up 8,862 identified entities across 29 named destinations, versus 1,400 when only the pre-built vendor dictionary is used. It is still a floor, not a ceiling. It only counts domains we could confidently attribute; the 8,113 one-off destinations described above are excluded here because a single occurrence isn't enough to confidently name a vendor.
| Destination | Entities | Share of identified | What it is |
|---|---|---|---|
| Brevo | 1,297 | 14.6% | Transactional email platform (formerly Sendinblue); receives reports as a side effect of sending mail, not a DMARC product |
| Proofpoint | 1,094 | 12.3% | Secure email gateway; own reporting endpoint (emaildefense.proofpoint.com) |
| Valimail | 1,068 | 12.1% | DMARC monitoring / automation product |
| Cloudflare | 978 | 11.0% | DNS/CDN provider; reports arrive at their own domain via a hosted DMARC feature, not a dedicated DMARC product |
| DMARC Analyzer | 602 | 6.8% | DMARC monitoring product (Dutch-founded, part of Vade since 2020) |
| dmarcian | 584 | 6.6% | DMARC monitoring product, nine country-coded regional endpoints |
| DMARC Advisor | 407 | 4.6% | DMARC monitoring product |
| EasyDMARC | 377 | 4.3% | DMARC monitoring product |
| Postmark | 348 | 3.9% | Transactional email platform; reports arrive as a side effect of sending mail |
| MxToolbox | 321 | 3.6% | DNS diagnostics vendor offering a DMARC report reader |
| Barracuda | 267 | 3.0% | Email security / gateway vendor |
| Red Sift (OnDMARC) | 248 | 2.8% | DMARC monitoring product |
| PowerDMARC | 184 | 2.1% | DMARC monitoring product |
| Fortra (Agari) | 149 | 1.7% | Email security / DMARC monitoring product |
| Others (15 vendors) | 938 | 10.6% | dmarcly, GoDaddy, sDMARC, Red Sift (separate endpoint), CheckPoint, Mailgun, Mailhardener, Everest, HornetSecurity, Kevlarr, LetsDMARC, report-uri, GlockApps, Cisco, UK NCSC |
Reading this table needs a caveat the table itself can't carry: Brevo, Cloudflare, and Postmark are not "DMARC monitoring vendors" in the way Valimail, dmarcian, or Red Sift are. They receive aggregate reports because a domain owner pointed rua= at a mailbox on their platform, often because that platform is also the domain's outbound sending or DNS provider, not because the domain owner bought a dedicated monitoring product from them. Restricting the table to vendors whose core product is DMARC monitoring, Valimail, DMARC Analyzer, dmarcian, DMARC Advisor, EasyDMARC, Red Sift, PowerDMARC, and Fortra (Agari) together account for 3,619 of the 8,862 identified entities, 40.8%. Within that narrower base, Valimail is the largest single vendor at 29.5%, with DMARC Analyzer (16.6%) and dmarcian (16.1%) some way behind; no vendor holds a majority, but the market is not evenly split either.
Country breakdown
Enforcement stage varies by country. Poland has the largest share of domains with no DMARC record at all in this cohort; the UK has the smallest share of domains with no record, but a correspondingly higher enforcement rate once a record exists.
| Country | Domains checked | No record | p=none | p=quarantine | p=reject |
|---|---|---|---|---|---|
| Poland | 7,039 | 64.6% | 16.3% | 11.3% | 7.7% |
| Netherlands | 5,598 | 51.1% | 21.1% | 14.2% | 13.6% |
| Germany | 12,152 | 45.7% | 26.3% | 12.9% | 15.0% |
| United States | 13,292 | 42.1% | 19.0% | 16.7% | 22.2% |
| Italy | 4,545 | 40.9% | 36.8% | 11.7% | 10.5% |
| United Kingdom | 1,493 | 37.0% | 19.2% | 18.3% | 25.5% |
| Spain | 2,697 | 36.9% | 29.5% | 18.1% | 15.5% |
| France | 5,125 | 43.0% | 29.1% | 12.8% | 15.1% |
The US and UK have the highest p=reject shares in this table (22.2% and 25.5%). Italy stands out for a different reason: it has one of the lower no-record rates (40.9%) but also the highest p=none share of any country here (36.8%), an observed difference consistent with more Italian domains in this cohort having started the DMARC process and stopped at the reporting-only stage, though the data here doesn't establish why. This is a snapshot of CipherCue's tracked cohort, not a national census; see the method note for how that cohort is built.
What else is missing alongside DMARC
DMARC doesn't operate alone. SPF and DKIM are the two authentication mechanisms DMARC builds on top of; MTA-STS, DNSSEC, and BIMI are three adjacent DNS-based controls that address related but separate problems. We checked all five against the same 67,336-domain cohort.
| Control | What it does | Present | Share |
|---|---|---|---|
| SPF | Authorises which mail servers can send for a domain | 48,962 | 72.7% |
| DMARC | Sets policy for mail that fails authentication, plus reporting | 36,974 | 54.9% |
| BIMI | Displays a verified brand logo in supporting inboxes | 1,726 | 2.6% |
| MTA-STS | Forces TLS encryption in transit between mail servers | 957 | 1.4% |
| DNSSEC | Cryptographically signs DNS responses so they can't be forged | 0 | 0.0% |
SPF is the most widely adopted control here, which tracks with it being the oldest and simplest to configure (a single DNS TXT record with no reporting infrastructure required). Of the 48,962 domains with SPF, 25,657 (52.4%) use a hard fail (-all) and 21,103 (43.1%) use a soft fail (~all), the difference between "reject" and "flag but accept" for mail that fails the SPF check.
MTA-STS and BIMI both sit under 3%. DNSSEC shows zero validated domains in this cohort, which we're flagging as a measurement caveat rather than a finding: CipherCue's current DNSSEC check validates the full signing chain, and a stricter check will show fewer passes than a looser one that only checks for the presence of DNSKEY or RRSIG records. We would not present 0.0% as a claim that no domain in the cohort has DNSSEC configured at all; we can say confidently that none passed full chain validation in our check, and we're treating the true adoption rate as an open question until we've audited the check itself.
The RFCs behind this, and what changed recently
DMARC's core specification changed in 2026. RFC 7489, the original DMARC specification published in March 2015 as an informational, industry-authored document, has been obsoleted by three new IETF documents published in May 2026:
- RFC 9989: the core DMARC protocol
- RFC 9990: aggregate reporting (the
rua=reports this article is about) - RFC 9991: failure reporting (
ruf=)
The practical significance is less about new tags in your DNS record and more about standing. RFC 7489 was published on the Independent Submission stream as Informational, meaning it was never put through IETF working-group consensus. RFC 9989 is Standards Track (Proposed Standard), the first time DMARC has had formal IETF standard status. The tags you already use, v=, p=, sp=, rua=, ruf=, adkim=, aspf=, and fo=, keep their existing meaning; nothing you would need to change today.
The one substantive mechanism change is how a receiver finds the "organisational domain" for a subdomain that has no DMARC record of its own. RFC 7489 used the Public Suffix List, a community-maintained file of which domain suffixes count as registrable (for example, knowing that co.uk is a suffix, not a company). RFC 9989 replaces this with a DNS Tree Walk: the receiver checks for a DMARC record at the exact sending domain, then walks up the domain tree checking each parent, until it finds one or runs out of labels. This removes the dependency on an externally maintained list that isn't itself part of the DNS.
Two adjacent standards referenced in this article, for context on maturity: RFC 8461 (MTA-STS) has been a full IETF Internet Standard since September 2018. BIMI, by contrast, has never been adopted by an IETF working group; as of this article the latest version is an individual Internet-Draft (version 14, dated May 2026) that explicitly carries "no formal standing in the IETF standards process." That gap in standing is one plausible reason BIMI sits at 2.6% adoption in our data versus SPF's 72.7%: implementing a control with no finished specification and an added certification cost (BIMI requires a Verified Mark Certificate from a small number of authorities) is a harder sell than a DNS TXT record against a ratified standard.
Does SOC 2 or ISO 27001 require this?
Neither SOC 2 nor ISO 27001 universally requires DMARC as a specifically named control. An organisation may still implement DMARC as part of its risk-based controls for email authentication, impersonation, and domain abuse.
SOC 2 is built around the AICPA's Trust Services Criteria, not a fixed technical checklist. An auditor evaluates whether the controls a company has chosen satisfy the criteria (most commonly Security, sometimes also Availability, Confidentiality, Processing Integrity, or Privacy); the company picks its own controls, and DMARC is not one of the named examples in the criteria document.
ISO 27001:2022 works the same way. Annex A control 5.14, Information Transfer, requires "rules, procedures, or agreements" governing how information moves within an organisation and with third parties, which is broad enough to cover email authentication without naming it. The 2022 revision consolidated what used to be four separate controls in the 2013 version (old clauses 8.7.1 through 8.7.4) into this single control.
What this looks like for one domain
Cranswick, the UK food producer (cranswick.co.uk), is a real example from the dataset. Its DMARC record is p=none and lists three separate rua= addresses: dmarc_agg@vali.email, a self-registered mailbox at eu.cp-dmarc.com, and a hashed address at rua.easydmarc.eu. Three different destinations, at least two different DMARC-monitoring vendors, for one domain. This is a public DNS record; anyone can look it up with dig TXT _dmarc.cranswick.co.uk. It is not unusual in the dataset, which is the point: reconciling three separate report streams into "who is actually sending mail for us" is exactly the kind of work that has to happen before a domain owner can move off p=none.
Method note
Source and cohort: CipherCue's own DNS observations (direct queries for DMARC, SPF, MTA-STS, BIMI, and DNSSEC), not a third-party dataset. 67,336 domains, observed 2026-04-14 to 2026-07-28. This is a domain count, not a deduplicated-organisation count: a large company can own several domains at different enforcement stages, so the same company can appear more than once.
Vendor mapping ("Who runs DMARC monitoring") uses a manually maintained dictionary of 40 known rua= reporting-endpoint domains and identifies 8,862 entities; it's a floor, not a census, since a name only appears if the destination matched a known pattern.
DNSSEC shows 0.0% because CipherCue's check requires full signing-chain validation; read that as "none passed our validation," not "none have DNSSEC configured."
External references: RFC 7489, RFC 9989, RFC 9990, RFC 9991 (IETF Datatracker), RFC 8461 (IETF Datatracker), draft-brand-indicators-for-message-identification version 14 (IETF Datatracker). SOC 2 Trust Services Criteria (AICPA), ISO/IEC 27001:2022 Annex A control 5.14.
Finding this in your own market
CipherCue's entity directory carries this same DNS compliance data (DMARC, SPF, MTA-STS, BIMI, DNSSEC) as a filterable score band per tracked domain, alongside country. If you want the domains in this article's low-scoring band for a specific country or sector, that's a filter on the entities index, not a custom pull.
Separately, if you're the one staring at your own rua= reports trying to work out who's actually sending mail on your behalf before you flip to enforcement: we built SenderLedger for exactly this problem. It takes the anonymous IPs and mailbox strings in your DMARC aggregate reports and groups them into named sender entities, vendor or system name, source IPs, first seen, last seen, volume, and an authorisation status. It's in early access; there's a waitlist at senderledger.com if you want in.