Why 37% of DMARC-Protected Domains Are Still at p=none and What That Means for Email Security

What the 37% statistic actually means

According to DMARCeye's Q1 2026 research, about 37% of domains with a published DMARC record are still running at p=none - the monitor-only setting that tells receiving mail servers to do nothing with unauthenticated mail. That makes p=none the single most common DMARC policy on the internet, even among organizations that have nominally adopted DMARC.

To understand what that means in practice, here's how the three policy levels differ:

• p=none means: "show me what's happening, don't act on anything." No emails get rejected or quarantined based on DMARC failures.
• p=quarantine means: "send suspicious mail to spam."
• p=reject means: "block mail that fails DMARC outright."

At p=none, a domain is essentially running email security in listen-only mode. It's collecting data, but it's not actually stopping anything. Spoofed emails that carry a forged version of your domain can still land in inboxes.

The 37% figure comes from DMARCeye's monitoring dataset - organizations actively watching their own DMARC posture. The broader public internet sample tells a different story: 28% of scanned domains had no DMARC record at all as of Q1 2026. The p=none problem exists on top of a larger "no DMARC at all" problem.

Why the gap between adoption and enforcement matters

The most common misconception about p=none domains is that organizations chose inaction. In practice, most of them got stuck - and the stuck state is where the real security risk lives.

Running at p=none means your domain is visible in DMARC reports, but spoofed emails can still reach inboxes. Any actor can send mail that appears to come from your domain and it gets delivered normally. The attack doesn't even require access to your infrastructure. A BEC attacker can set up their own mail server, forge your domain in the From header, and unless the receiving mail server has additional checks, the message lands.

This is not theoretical. BEC attacks using domain spoofing are a documented, ongoing problem. A p=none record does nothing to prevent them. Your DMARC data tells you it's happening, but the record itself doesn't block anything.

The real issue is execution, not awareness. Most organizations that publish DMARC intend to move to enforcement eventually. They get stuck because the discovery process - understanding every legitimate source sending on their behalf - takes longer than expected, and the organizational ownership for the enforcement decision is unclear.

Why organizations get stuck at monitor-only mode

Three things keep organizations at p=none:

The discovery problem. When an organization first publishes DMARC, it has no baseline for how many sending sources are active. Google Workspace alone can surface dozens of distinct sending IPs across regions. A single ESP customer can surface IPs from multiple network ranges. Until you've run at p=none long enough to see your full sending footprint, moving to enforcement means legitimate mail starts bouncing. Teams that skip the discovery phase tend to discover their mistake when customers call to ask why they're not receiving emails.

The SPF problem. DMARC requires SPF or DKIM (or both) to pass alignment. If your sending infrastructure includes providers you've never added to your SPF record, moving to p=reject rejects their mail. Most organizations find more SPF gaps than they expected. Fixing them requires vendor coordination and DNS changes that take time.

The organizational problem. Moving to p=reject requires someone to explicitly declare which sending sources are authorized for the domain. In practice, that decision often sits between IT, security, legal, and marketing - and none of them own it. So p=none stays.

DMARCeye's data shows this clearly: low-volume senders have the highest share of non-compliant mail, and high-volume senders run effectively perfect compliance. The organizations that have scaled their email infrastructure have almost all resolved the configuration issues. It's the organizations still in discovery mode that keep the 37% figure alive.

How to move from p=none to enforcement

Moving to p=reject safely requires completing three steps in order:

1. Run at p=none long enough to be sure. How long depends on how much mail you send and how varied your sending sources are. A small business with one ESP might need 30 days. A multinational with Google Workspace, Salesforce, and five marketing platforms might need six months. The goal is to see every legitimate source in your aggregate reports before enforcement starts rejecting mail.

2. Fix SPF and DKIM alignment for every legitimate source. Add all authorized sending IPs to your SPF record, confirm DKIM keys are published for each provider, and verify the From domain aligns with the RFC5321.MailFrom domain. If you've added a new vendor and haven't updated DNS, their mail fails DMARC the day you enforce.

3. Move to p=quarantine before p=reject. p=quarantine catches failures without immediately bouncing mail. If a legitimate source is misconfigured, mail goes to spam - embarrassing but recoverable. Once p=quarantine shows no unexpected false positives, move to p=reject.

The teams that move fastest treat the discovery phase as continuous, not a one-time audit. They monitor their aggregate reports weekly, not just when something breaks. DMARCFlow is built for that - it surfaces new sending sources automatically, flags misconfigurations before they cause rejections, and gives IT and security teams the data they need to make the enforcement call with confidence instead of guesswork.

FAQ

Why is p=none still so common?

Most organizations publish DMARC because a security framework or auditor required it, not because they planned to move to enforcement immediately. Setting up DMARC is easy. Executing a full sender audit and moving to enforcement takes months of work most teams aren't resourced for. The 37% figure reflects how hard the second part is.

Is p=none ever the right long-term choice?

Almost never. The only scenario where p=none makes sense permanently is if your domain genuinely never sends email. Even then, a p=reject record is a valid signal that spoofing your domain isn't worth an attacker's time. For any organization that sends mail, p=none is a temporary staging state.

How long does it take to move from p=none to p=reject?

It depends entirely on how complex your sending infrastructure is. A small organization with one or two providers might do it in 4-8 weeks. Larger organizations with multiple ESPs, cloud platforms, and legacy systems often take 6-12 months. The teams that move fastest start monitoring their DMARC data from day one - they know their baseline before they try to change it.

Does moving to p=reject guarantee no one can spoof my domain?

It guarantees that mail failing DMARC alignment gets rejected by receivers who honor the p=reject policy - that's the overwhelming majority of major mail providers. Some receivers may not honor it, and some targeted attacks may use infrastructure that passes alignment. p=reject is one layer of a broader email security posture, not a complete solution on its own.