What percentage of domains have DMARC enforcement?

In InboxGreen's analysis of 1,247 domains, only 62.9% had any form of DMARC enforcement (p=quarantine or p=reject). 43.4% had reached the strongest level: p=reject. The remaining 37.1% either had no DMARC record (13.5%) or were using p=none monitoring mode (23.6%), which provides no protection against domain spoofing.

Is DMARC p=none enough to protect my domain?

No. DMARC p=none is a monitoring-only policy. It does not instruct receiving servers to block or quarantine messages that fail authentication. Spoofed emails still reach recipients. p=none is the recommended starting point for collecting data, but protection only begins when you move to p=quarantine or p=reject.

What does DMARC p=none without rua mean?

A DMARC record at p=none without an rua tag means the domain has monitoring-only DMARC with no reporting destination. Without rua, aggregate reports are never sent, so the domain owner receives no data about who is sending on their behalf. This configuration provides neither protection nor visibility. Add an rua=mailto:your@email.com tag to start receiving reports.

How do I upgrade from DMARC p=none to p=reject?

The recommended process: first, confirm rua is set and you are receiving aggregate reports. Review the reports over two to four weeks to verify your legitimate senders pass DMARC alignment. Then change to p=quarantine with pct=10 (applies the quarantine policy to only 10% of failing messages). Monitor delivery for another two weeks. Increase pct to 50, then 100. Finally, move to p=reject once you are confident no legitimate senders are failing.

What happens if I have no DMARC record?

Without a DMARC record, receiving servers have no policy to follow when SPF or DKIM fails for email claiming to come from your domain. Anyone can send email that appears to be from your address, and mail providers have no automated mechanism to block it. Adding a DMARC record at p=none takes about five minutes and gives you immediate visibility into your email traffic.

DMARC Enforcement Report 2026: 1,247 Domains Analyzed

Published August 2026 · By The InboxGreen Team · Methodology

Using the same 1,247 domains checked for our SPF Mistakes Report 2026, we analyzed DMARC adoption and enforcement levels across all domains in the dataset. 37.1% of domains either have no DMARC record or use a monitoring-only policy that takes no action against spoofed messages. Only 43.4% have reached the strongest enforcement level: p=reject.

Key Findings

37.1%

of domains have no real DMARC protection: either no record or p=none monitoring mode

23.6%

had DMARC at p=none: a record exists, but receiving servers are told to take no action

13.5%

had no DMARC record at all, leaving their domain fully exposed to spoofing

25.5%

of p=none domains have no rua address: they collect no reports, gaining nothing from monitoring mode

DMARC Policy Across All 1,247 Domains

DMARC policy determines what a receiving server does when an email fails authentication. Without enforcement (at p=quarantine or p=reject), a DMARC record exists on paper but provides no real protection against spoofed messages from your domain.

p=reject (full enforcement) 541 domains (43.4%)

p=quarantine (partial enforcement) 243 domains (19.5%)

p=none (monitoring only, no action) 294 domains (23.6%)

No DMARC record 169 domains (13.5%)

Less than half of domains (43.4%) have reached p=reject, the policy level that instructs receiving servers to refuse delivery of messages that fail DMARC authentication. A further 19.5% are at p=quarantine, which sends failing mail to spam rather than blocking it. Together, these two groups represent the 62.9% of domains with any form of DMARC enforcement.

The remaining 37.1% are either at p=none (monitoring only) or have no DMARC record at all. For these domains, DMARC provides zero protection against someone spoofing the From address.

Finding 1: The p=none Trap (23.6% of all domains)

The most surprising finding is how many domains have DMARC configured but stuck in monitoring mode. p=none is the recommended starting point: it allows domain owners to collect aggregate reports and verify authentication is working before enabling enforcement. But it is intended as a temporary phase, not a permanent state.

Industry guidance consistently recommends moving from p=none to p=quarantine within four to eight weeks of adding DMARC, and then to p=reject once alignment is confirmed. The 23.6% of domains still at p=none suggests a large number of domain owners started the DMARC process and stopped.

p=none without rua: monitoring mode with no reports

Of the 294 domains at p=none, 75 (25.5%) had no rua tag in their DMARC record. Without rua, aggregate reports are never sent, meaning the domain owner receives no data about who is sending email on their behalf. A p=none policy without rua provides neither protection nor visibility.

p=none with rua (gets reports, no enforcement) 219 domains (74.5%)

p=none without rua (no reports, no enforcement) 75 domains (25.5%)

What to do: If your domain is at p=none, the first step is adding an rua tag so you can see who is sending email from your domain. Then, over four to eight weeks, review the reports and confirm your main sending sources pass alignment. Once they do, move to p=quarantine; pct=10 and increase the percentage gradually. See the complete guide to upgrading DMARC policy.

Finding 2: No DMARC Record (13.5% of all domains)

169 domains had no DMARC TXT record at _dmarc.yourdomain.com. Without DMARC, receiving servers have no policy to follow when SPF or DKIM fails. This is the most exposed state a domain can be in.

The risk is not hypothetical. Domain spoofing (sending emails that appear to come from your domain using someone else's server) requires no access to your infrastructure and is trivially easy when DMARC is absent. Gmail, Outlook, and Yahoo require DMARC for bulk senders as of February 2024, but the requirement has not driven adoption to 100%.

Missing DMARC correlates with weak SPF

Of the 169 domains with no DMARC record, 71% also had SPF configured as softfail (~all) or had no SPF record at all. This pattern is consistent: domains that have not addressed DMARC tend to also have incomplete SPF configuration. The two gaps compound each other.

What to do: Adding a basic DMARC record takes about five minutes. The minimum safe starting record is v=DMARC1; p=none; rua=mailto:[email protected]. This gives you visibility without affecting delivery. See the step-by-step guide for adding a DMARC record in Cloudflare, Namecheap, and GoDaddy.

Finding 3: Partial Enforcement in 19.9% of Enforced Domains

Among the 784 domains at p=quarantine or p=reject, 19.9% (156 domains) had a pct tag set below 100. The pct tag controls what percentage of failing messages the policy is actually applied to. A domain at p=reject; pct=25 is only blocking roughly one quarter of spoofed messages, while three quarters pass through without enforcement.

pct=100 or not set (full enforcement) 628 domains (80.1%)

pct=1 to 99 (partial enforcement) 156 domains (19.9%)

pct below 100 is a valid and recommended way to roll out DMARC enforcement gradually. The concern is when it stays there. A domain that moved to p=quarantine; pct=10 six months ago and never increased the percentage has effectively stalled its rollout. Without a monitoring process that tracks delivery and checks alignment regularly, these partial-enforcement domains may never reach full protection.

Finding 4: DMARC Enforcement and SPF Strength Go Together

There is a clear pattern in the data: domains with strict DMARC enforcement also tend to have stricter SPF. Among domains at p=reject, 89% also used -all (hardfail) in their SPF record. Among domains at p=none, that figure drops to 34%. Among domains with no DMARC, it drops further to 22%.

Percentage with SPF hardfail (-all) by DMARC policy level

Domains at p=reject: SPF with -all 89%

Domains at p=quarantine: SPF with -all 61%

Domains at p=none: SPF with -all 34%

Domains with no DMARC: SPF with -all 22%

This correlation suggests that DMARC and SPF strength are not independent: domain owners who take one seriously tend to take the other seriously too. Fixing one is often a signal that the full authentication stack will get attention. The inverse is also true: domains with weak or missing DMARC are disproportionately likely to also have incomplete SPF.

DMARC Status Summary

DMARC status	Domains	% of total	Spoofing protection?	Reports collected?
`p=reject`	541	43.4%	FULL	Yes (if rua set)
`p=quarantine`	243	19.5%	PARTIAL	Yes (if rua set)
`p=none` with rua	219	17.6%	NONE	Yes
`p=none` without rua	75	6.0%	NONE	No
No DMARC record	169	13.5%	NONE	No

Why DMARC at p=none Is Not Enough in 2026

Publishing DMARC at p=none satisfies some compliance checkboxes. It meets the minimum threshold in Google and Yahoo's February 2024 bulk sender requirements. But it provides zero active protection against email spoofing.

A spoofed email sent from your domain passes right through a p=none policy. Receiving servers log the failure in aggregate reports (if rua is set), but they deliver the message normally. From the recipient's perspective, there is no visible difference between a spoofed email sent by an attacker and a legitimate email sent by you.

The path to enforcement is straightforward: add rua, confirm your legitimate senders appear in reports, verify they pass DMARC, then move to p=quarantine; pct=10. Increase the percentage over two to four weeks. Then move to p=reject. Most domains can complete this in under two months. The 23.6% of domains at p=none suggest the most common reason for not completing it is forgetting.

Check and Fix Your Own DMARC

DMARC Analyzer

Fetch your live DMARC record, see the parsed policy tags, and check enforcement level.

Fix: DMARC p=none

Step-by-step guide to upgrading from p=none to p=quarantine and then p=reject without breaking delivery.

Fix: No DMARC Record

How to add a DMARC record in Cloudflare, Namecheap, and GoDaddy, with the exact value to use.

Full Domain Check

Check SPF, DKIM, and DMARC alignment together. Shows your exact policy and any alignment issues.

Cite this report

InboxGreen Team. DMARC Enforcement Report 2026: 1,247 Domains Analyzed. InboxGreen.email, August 2026. Available at: https://inboxgreen.email/research/dmarc-enforcement-report-2026

Same dataset as the SPF Mistakes Report 2026. 1,247 unique domains. DMARC records queried May 1 to July 10, 2026.

Check your DMARC policy now

See your live DMARC record and whether it is actually enforced. Free, no signup required.

Analyze my DMARC Full domain check

Methodology

Dataset: The same 1,247 unique domains analyzed for the SPF Mistakes Report 2026. Domains were submitted to InboxGreen for checking between May 1 and July 10, 2026. Only unique apex domains are included. Subdomains and duplicate submissions are excluded.

DMARC lookup method: InboxGreen queries the TXT record at _dmarc.domain.com using PHP's dns_get_record() function against public DNS resolvers. The raw record is parsed to extract the policy tag (p=), percentage tag (pct=), and aggregate report address (rua=).

Policy classification: p=reject is classified as enforced (full). p=quarantine is classified as enforced (partial). p=none is classified as monitoring only. A missing or malformed DMARC record is classified as no DMARC.

rua detection: A domain is counted as having rua if the rua= tag is present in the DMARC record and contains at least one mailto: address.

pct analysis: Applied only to domains at p=quarantine or p=reject. A domain with no pct tag is treated as pct=100 per RFC 7489 defaults.

SPF correlation: SPF policy for each domain is taken from the same scan. The -all flag in the SPF record is used to classify a domain as using hardfail. ~all, missing, and other endings are counted as not using hardfail.

Limitations: DMARC records change over time. All data reflects the configuration at time of check. Domains at p=none at time of scanning may have since upgraded. The sample is self-selected: domains submitted to InboxGreen are more likely to have deliverability problems than a random sample of all email-sending domains, which may inflate the rate of weak or missing DMARC relative to the broader internet.