DMARC Is Mainstream. Is Your Domain Actually Protected?

Executive takeaway

A DMARC record is a starting point, not proof that a domain is protected. In one 2026 scan of 5.5 million domains, 30.4% published DMARC but only 12.8% requested quarantine or rejpection of failing mail. Meanwhile, message pass rates near 89% reflect a different population: email traffic dominated by large senders. For security teams, the priority is to separate these measures, inventory legitimate sending services, verify reporting, and move toward enforcement without disrupting business email.

Even then, DMARC is a defense against domain spoofing—not a guarantee that every authenticated message is safe.

Your DMARC record may only be watching

In February 2026, DMARCguard’s scan found that 30.4% of 5,499,028 ranked domains published DMARC, but only 12.8% used an enforcement policy. Both percentages describe the same domain population—not email messages—and the gap exposes a common trap: having a record is not the same as asking receivers to act against spoofing.

DMARC helps check whether an email is authorized to use the domain people see in its From address. As NIST’s email authentication guide explains, it builds on SPF, which checks sending-server authorization, and DKIM, which verifies a digital signature attached to the message.

To pass DMARC, at least one of those checks must pass and align with the visible From domain. “Align” means the authenticated domain matches that domain, or shares the same organizational domain under relaxed rules—not simply that SPF or DKIM passed somewhere.

The domain owner publishes a DMARC record in DNS, the internet’s directory, specifying handling instructions and, optionally, reporting destinations. The three policy choices mean different things:

• p=none: Requests no special treatment for DMARC failures; useful for monitoring when reporting is configured.
• p=quarantine: Asks receivers to treat failures as suspicious, such as placing them in spam.
• p=reject: Asks receivers to refuse failing messages.

These are requests, not guarantees: receivers can apply their own handling rules. In particular, quarantine does not necessarily mean blocking delivery.

Measure	What it tells you	Denominator
Publication: 30.4%	A DMARC record exists	All 5,499,028 scanned domains
Enforcement: 12.8%	Policy requests quarantine or rejection	All 5,499,028 scanned domains—not just adopters
Message pass rate	Email passes authentication and alignment	Messages evaluated in the measured mail stream—not domains

Monitoring is a useful starting stage, allowing teams to identify legitimate senders and authentication problems before tightening policy. But publishing p=none completes a configuration step, not the security outcome of requesting action against mail that fails DMARC.

Source: DMARCguard, State of Email Authentication, 2026

Radial chart showing DMARC record publication, enforcement, and no-DMARC presence across DMARCguard’s 5.5M-domain Tranco scan, highlighting the gap between adoption and protection. Method: Percentages (30.4% DMARC adoption, 12.8% enforcement, 69.6% vulnerable) are taken from DMARCguard’s published metrics and plotted as three progress rings.

Why the adoption numbers seem to disagree

DMARC adoption can look like a minority practice or a mainstream standard, depending on which domains a study counts. Before comparing headlines, ask “What is the denominator?”—the full group behind the percentage—and whether “adoption” means publishing a record or requesting action against failing mail.

DMARCguard’s February 2026 scan covered 5,499,028 domains from the complete Tranco Top Sites list, a ranking of popular websites. It reported 30.4% publication versus 12.8% enforcement, with enforcement defined as p=quarantine or p=reject: policies asking receivers to quarantine or reject messages that fail DMARC.

DDMARC’s State of Email Security 2026 focused on the much narrower Tranco top-10,000 cohort, using 8,907 resolved domains for its reported results. In that measured population, publication reached 68.2%, while reported combined quarantine-and-reject enforcement was 49.9%.

That contrast matters: the very top of a website ranking is not interchangeable with its much longer tail. The results show substantially higher publication and enforcement in DDMARC’s narrower cohort, but they do not establish that the broader domain population has reached those levels.

A third snapshot, EasyDMARC’s research as summarized by DMARC Report, found valid DMARC records on 52.1% of 1.8 million top domains. That is a record-validity measure for another selected population—not an enforcement rate and not necessarily a measure weighted by email volume.

Zoom out further and the headline changes again: Red Sift’s global adoption guide reports 14.9% publication across 73.3 million domains in December 2025, with 2.5% using p=reject. That second number is reject-only, so it should not be compared as though it includes quarantine, as the DMARCguard and DDMARC enforcement figures do.

Broad DNS zone scans—large inventories of domain names—can include parked, defensive, or minimally active domains alongside active businesses. Ranked-domain samples select for website prominence instead, so the populations answer different questions; neither should automatically be described as representing active email senders.

Nor does “popular domains” mean “mail-volume weighted.” Counting each domain once is fundamentally different from weighting results by how many messages it sends, and website rank alone does not establish email volume.

The useful reading habit is to check three labels: population, measurement, and date. These studies are separate snapshots, not a time series; their percentages cannot be stitched together into a rise or fall in adoption, and a publication headline cannot substitute for an enforcement measure.

Comparison of record-level DMARC adoption and enforcement rates across DMARCguard’s 5.5M Tranco study, DDMarc’s top-10,000 measurement, and Red Sift’s 73.3M-domain zone scan, illustrating how different domain universes produce different topline rates. Method: Values are taken directly from each study’s reported adoption and enforcement percentages and reframed into a qualitative table contrasting DMARC record presence and protection posture.

An 89% pass rate is not an 89% safety score

Cloudflare Radar telemetry, as summarized by TechnologyChecker, puts the reported DMARC pass rate at 88.99% in Q1 2026, up from 86.42% in Q1 2025. The same summary reports 89.12% for Q3 2026—but these are message-level authentication results, not percentages of domains protected or messages proven safe.

The apparent paradox comes from what gets counted: high-volume, well-authenticated senders can dominate the observed mail stream, while low-traffic domains barely affect the result. Many domains can therefore remain without enforcement even when nearly nine in ten messages pass; a domain with a monitoring-only policy can still send mail that passes DMARC consistently.

Keep three questions separate: publication asks whether a domain has a DMARC record; enforcement asks whether its policy requests quarantine or rejection of failing mail; pass rate asks how much observed traffic authenticates with domain alignment. Improvement in the third measure does not establish equivalent progress in the first two, because messages and domains are different denominators.

There is also an important label to decode: the telemetry’s NONE category means no published DMARC policy, not a published policy set to p=none. The latter is a real DMARC record that requests no DMARC-specific action against failing messages; it is not the same as having no policy at all.

Authentication also has a narrower job than detecting phishing: a DMARC pass means SPF or DKIM authentication succeeded with a domain aligned to the visible From address. In separate UC San Diego enterprise-email research, 10.4% of phishing messages passed DMARC—a finding specific to that dataset, not an estimate for Cloudflare’s traffic or all phishing.

Passing establishes domain alignment, not benign content or intent. Conversely, forwarding can disrupt authentication or alignment for legitimate messages, and differences in receiver validation and policy handling mean outcomes are not identical everywhere.

Ecosystem telemetry is useful context, but it cannot reveal whether your organization’s domains enforce, which legitimate sending services are misaligned, or where forwarding causes failures. That requires your own domain inventory and sender-level assessment, with accountable owners and reporting that measures alignment and progress toward enforcement separately. Line chart plotting DMARC pass rates in Cloudflare Radar’s telemetry from Q1 2025 through Q3 2026, showing steady improvement toward roughly 89% pass. Method: Quarterly DMARC pass percentages are drawn from TechnologyChecker’s summary of Cloudflare Radar data and plotted chronologically.

The rules got senders started—not necessarily finished

Gmail and Yahoo gave bulk senders a compelling reason to adopt DMARC in 2024: meeting mailbox-provider requirements helps keep business email flowing. But their minimum DMARC requirements accept p=none, so organizations can clear that particular hurdle without asking receivers to quarantine or reject messages that fail DMARC.

That creates an incentive gap between deliverability and protection: publishing a record addresses the immediate compliance task, while enforcement requires additional work. Passing the minimum DMARC requirement is not the same as meeting every sender requirement—nor does it mean the domain’s policy instructs receivers to stop spoofed mail.

Some government rules set a higher bar, making enforcement part of the requirement rather than an optional next step. As summarized in Red Sift’s mandates and guidance overview, the U.S. Binding Operational Directive 18-01 requires covered federal agencies to reach p=reject, while the UK’s Minimum Cyber Security Standard requires central government departments to use p=quarantine or p=reject.

These are scoped requirements, not evidence that every regulated organization faces an identical DMARC mandate; recommendations elsewhere should not be presented as binding obligations.

New Zealand illustrates the distance between setting a standard and reaching it. Reported Proofpoint research in 2026, covering more than 200 primary state entities, found 50% had reached p=reject, while 35% remained at p=none. Another 12% used quarantine and 3% had no DMARC record, leaving half short of the Secure Government Email framework’s rejection standard ahead of its reported October 2026 deadline.

The hesitation is not necessarily indifference: legitimate email often comes from marketing systems, CRM platforms, ticketing tools, and other services outside the main mail platform. Before tightening policy, organizations need to discover those senders and check alignment—whether a passing SPF or DKIM authentication result uses a domain that matches the visible From domain under DMARC’s rules.

Without that preparation, enforcement can disrupt genuine customer messages.

That is why visibility into sending services and alignment failures matters to the decision, not just the technical implementation. The operational challenge is to establish who owns each sender and resolve legitimate failures, so a temporary monitoring policy does not become the permanent finish line.

Reliable reports are the bridge to enforcement

RUA aggregate reports are DMARC’s feedback channel: summaries from receiving mail systems sent to the addresses listed in a domain’s rua tag. They show sending IP addresses, message counts, and authentication results, helping teams identify sending services and investigate failures before tightening policy.

That visibility is not automatic. In Ashiq and colleagues’ 2023 study, 49% of domains with DMARC records configured RUA reporting, and 70% of those reporting-enabled domains directed reports to external domains—historical measurements, not estimates of 2026 prevalence.

A reporting address can be present but ineffective: an incorrect address or broken destination configuration can prevent delivery. External destination verification adds another dependency: when reports go to another domain, that destination must publish DNS authorization indicating that it accepts them.

Missing reports therefore deserve investigation, rather than an assumption that no suspicious mail exists. Address errors, absent authorization, and receivers that do not generate reports can all leave teams with an incomplete picture of their email traffic.

Delivered reports can also create processing problems. A 2024 reporting-compliance study found that 94.93% of more than 40,000 aggregate reports collected at a European university failed the specified XML-syntax requirements—the rules governing their machine-readable structure.

That finding does not mean every affected report was unusable, nor does one university’s corpus establish how every provider behaves. It does show why strict parsers can encounter problems, and why teams should distinguish recoverable formatting defects from missing or unreliable data.

Analyzers, including DMARC Report, help turn raw report data into understandable views of senders and authentication failures. Their value is making evidence usable—not automatically proving that a domain is ready for enforcement.

When evaluating an analyzer, ask for demonstrations of four capabilities:

• Sender identification: Can it connect sending IPs and patterns to recognizable services while clearly marking uncertain matches?
• Parsing resilience: Can it recover useful information from imperfect reports, flag errors, and disclose what it could not process?
• Reporting-destination checks: Does it check reporting addresses and external authorization, rather than merely confirm that a rua tag exists?
• Clear alignment diagnostics: Does it distinguish authentication success from alignment—whether the authenticated domain matches the visible From domain under DMARC’s rules?

A useful dashboard should make both failures and visibility gaps apparent. Teams still need to confirm which services are legitimate and resolve unexplained failures; a reassuring chart cannot substitute for that review.

Source: Ashiq et al., USENIX Security, 2023

Move from a published record to a managed defense

Make DMARC a shared operating responsibility, not a completed DNS ticket. Security should set enforcement goals, IT should manage authentication and DNS, and marketing and business-service owners should account for the platforms sending on their behalf.

Work through the portfolio in this order:

1. Inventory domains before changing policies. List active domains, subdomains, and domains that should never send email, with an accountable owner for each. Non-sending domains also need defensive policies: government-focused DMARC guidance recommends rejecting unauthorized mail and publishing an SPF record that authorizes no senders, such as v=spf1 -all.
2. Map legitimate senders to business owners. Identify employee mail systems, marketing platforms, billing services, support tools, and other approved senders. Ask each owner to confirm the service’s purpose and sending domains; investigate unfamiliar sources rather than assuming every authentication failure is an attack.
3. Verify reporting works end to end. Check that the rua destination—the address for aggregate reports—is controlled, monitored, and actually receiving usable data. Where reports go to an external domain, verify its authorization; the USENIX reporting study documents configuration problems that can prevent delivery, so a published address alone is not proof of visibility.
4. Fix authentication and alignment. Correct SPF authorization and DKIM signing for approved services, then verify that legitimate messages pass DMARC. As NIST’s email-authentication guidance explains, DMARC needs a passing SPF or DKIM result whose authenticated domain aligns with the visible From domain—not merely an authentication pass for an unrelated vendor domain.
5. Advance policy when evidence supports it. Move from monitoring to p=quarantine, then toward p=reject, after resolving legitimate-sender failures and reviewing the remaining failures. Reporting-driven enforcement guidance emphasizes this staged approach; continue monitoring after every policy change and whenever a new sender is introduced.

Use this decision guide to separate domains ready for stronger policy from those needing investigation:

Evidence for the domain	Next action
Reports missing, unusable, or unexpectedly silent	Investigate reporting before judging readiness
Sender ownership unclear or legitimate mail misaligned	Identify owners and repair configuration
Approved senders aligned; remaining failures understood	Progress through quarantine toward reject
Confirmed non-sending domain	Apply defensive rejection and monitor for misuse

p=reject plus working RUA reporting is a useful operational benchmark, not comprehensive phishing protection. It addresses unauthorized use of your domain, not every deceptive message or attacker-controlled domain.

Keep the dashboard equally explicit, with a defined domain inventory and reporting period:

• Record coverage: Domains covered by valid DMARC records; missing coverage.
• Policy posture: Domains at none, quarantine, or reject, including effective subdomain policies.
• Legitimate-message alignment: Pass rates for approved senders, with failures assigned to owners.
• Reporting health: Destination validity, external authorization, report freshness, and processing failures.

A practical decision tree for domain owners moving from DMARC record publication through reporting to enforcement, reflecting mainstream adoption but persistent protection gaps. Method: The decision tree synthesizes enforcement best practices from NIST’s DMARC technical note, DMARC Report’s policy-progression guidance, and DMARCguard’s empirical insights on adoption and enforcement rates.

Limitations

• The studies cover different domain populations and dates; their percentages are not interchangeable or a single global trend.
• Some raw figures, denominators, and source references conflict. Check the originals before publication and omit unresolved claims.
• Several findings come through vendor summaries; associations with mandates or lower spoofing do not establish causation.
• Published enforcement policies and message pass rates do not prove complete protection against phishing or consistent receiver behavior.

References

1. State of Email Security 2026 — DMARC Adoption Data | DDMARC
2. DMARC Adoption 2026: 30.4%, DKIM 22.7% of 5.5M
3. The State of DMARC Adoption in 2026:938000 Domains Have …
4. DMARC adoption statistics 2026: 89% of emails pass DMARC but …
5. DMARC Report Analyzers in 2026: Why They Matter More Than …
6. Red Sift’s guide to global DMARC adoption
7. How can the government and public sector agencies …
8. Global mandates and guidance for DMARC in 2026 - Red Sift
9. Half of New Zealand agencies still have an email security …
10. Measurement and Security Implications of DMARC Reporting
11. Email Authentication Mechanisms: DMARC, SPF and DKIM
12. UC San Diego
13. Stress Testing the DMARC Reporting System: Compliance with …