Q1 2026 data from DMARCeye shows more than a third of DMARC-engaged domains never reach enforcement. Here is what it costs and what you can do about it.
DMARC's whole point is enforcement. The record tells receiving mail servers what to do with messages that fail authentication: send them to spam with p=quarantine, or refuse them outright with p=reject. Until a domain reaches one of those policies, DMARC is just visibility. Useful, but not protection. Q1 2026 data from DMARCeye's monitoring platform shows that more than a third of DMARC-engaged domains never get there.
This article unpacks the policy-distribution finding from DMARCeye's Q1 2026 industry report. The full report, with all 12 chart views and methodology, is below.
Where DMARC-Engaged Domains Sit in Q1 2026
Among the thousands of domains DMARCeye actively monitors, the policy split looks like this:
- 36.7% at
p=none: monitor-only. A DMARC record exists, but receivers aren't being told to do anything when authentication fails. - 36.8% at
p=quarantine: failed messages go to spam. - 26.5% at
p=reject: full enforcement. Failed messages are refused.
About a third of monitored domains are still in the visibility phase. Only about a quarter have reached full enforcement. The middle tier, quarantine, is the largest single bucket.
Source: DMARCeye Q1 2026 industry report (research.dmarceye.com)
This picture is for domains already engaged with DMARC. The full report compares the engaged group to a separate scanner sample of public-facing internet domains. In that sample, 28% of domains have no DMARC record at all.
What "Monitor-Only" Actually Protects
A DMARC record at p=none tells receiving servers: "if a message fails SPF and DKIM alignment, deliver it anyway, but send a report." The domain owner gets visibility, both into legitimate mail from forgotten services and into impersonation attempts. But no blocking happens. A spoofed message reaches the inbox just like a legitimate one would.
Monitor-only is a fine starting point. You can't safely tighten policy without monitoring data first. But sitting at p=none indefinitely means you're collecting evidence of impersonation and never doing anything about it.
What Staying at p=none Actually Costs You
For most companies, the practical risk of staying at p=none shows up in three places:
- Spoofing reaches inboxes. A phishing campaign impersonating your domain lands in your customers' or employees' mailboxes because no policy is in force to stop it.
- Real mail moves toward the spam folder. Receiving servers don't punish monitor-only directly, but they track failed-authentication messages against your domain's reputation. Spoofed mail in your name fails authentication. Over weeks of attacker activity, that recorded pattern starts affecting where your legitimate mail lands.
- Bulk-sender requirements are minimally met. Google and Yahoo's February 2024 guidelines require a DMARC record for senders above 5,000 messages per day. Publishing at
p=nonewith reporting meets the minimum. Their filtering algorithms still factor DMARC posture into delivery decisions, and a record that publishes but never enforces sits in the "compliant on paper" tier.
For an e-commerce shop sending order confirmations and shipping updates, this looks like: legitimate transactional mail gets harder to deliver over time, while spoofed mail still hits your customers' inboxes. Damaged sender reputation is slow to repair once it tips.
Why Domains Stay at p=none
The Q1 report shows the what. It does not tell us why any specific domain remains at monitor-only. The reasons below are patterns we see across customers, not findings from the dataset. Treat them as informed guesses to check against your own situation:
- Fear of breaking legitimate mail. The most common reason teams stay put. Tightening policy could quarantine or reject mail from a third-party service the team forgot to document. The fix is documentation, not avoidance.
- No clear next-step guidance. Most monitoring tools show raw aggregate reports and leave interpretation to the team. Without a per-domain answer to "is it safe to move?", teams default to staying put.
- Forgotten ownership. The person who set up DMARC monitoring left. Nobody else has the authority, or the appetite, to flip the switch.
- Underestimating the upside. Until a spoofing incident lands, enforcement is one of many priorities competing for attention. After one lands, it becomes the only one. Most teams find out the hard way.
The report shows that the gap exists. The causes are worth investigating in your own setup.
Moving From Monitoring to Enforcement Safely
The path from p=none to p=reject is well-documented and does not require a leap of faith:
- Read your aggregate reports for at least 2 to 4 weeks. You need a stable picture of what's sending as your domain. Spikes from one-off campaigns will mislead you.
- Authenticate every legitimate sender. Your ESP, transactional service, marketing platform, billing system, and internal mail relay all need to be aligned for SPF or DKIM. Preferably both, since DKIM survives forwarding and SPF does not.
- Move to
p=quarantinefirst. Mail that fails goes to spam, not to/dev/null. Watch reports for a week or two. Confirm legitimate mail still passes. - Move to
p=reject. If you've done step 2 right, the shift is mostly invisible.
One related finding from the Q1 report: only about 6% of enforcing domains use DMARC's built-in pct= tag for staged percentage rollout. Most teams jump straight from p=none to full enforcement at 100%. The forthcoming DMARCbis revision of the standard removes pct= entirely, which makes "do the prep" the binary path.
If you want a worked walkthrough, our complete DMARC implementation guide covers the full process.