Over half a million domains are still at p=none. Is yours one of them?

Do the subtraction on the 2026 DMARC adoption numbers and one figure stands out more than the headline percentages: of the 937,931 domains EasyDMARC found with a valid DMARC record, only 411,935 have reached an enforcement-level policy (p=quarantine or p=reject). That leaves roughly 526,000 domains — more than half of everyone who bothered to publish a record at all — sitting at p=none.

Most discussion of p=none treats it as a recipient problem: those domains aren’t protecting the mailbox providers filtering their mail, or the people who might get phished. Both true. But if your own domain is one of the 526,000, the more immediate risk is to you, not to some abstract third party.

What p=none actually exposes for the sender

p=none means: authenticate my mail if you want, tell me what you saw, but take no action either way. It’s a monitoring mode, and for a brand-new domain that’s genuinely correct — see p=none vs. p=quarantine vs. p=reject for why you start there. The problem is a domain that never leaves it, because indefinite p=none is functionally the same as having no DMARC record at all, from an attacker’s perspective:

• Anyone can send mail that appears to be from your domain, and it will be delivered. SPF or DKIM might fail on the forged message, but because the policy says “take no action,” most receiving servers deliver it anyway — exactly as if DMARC weren’t published.
• Your customers, prospects, and partners are the ones who get spoofed. A p=none domain doesn’t protect its own outbound mail from a fake invoice, a fake password-reset link, or a fake “urgent wire transfer” request built on your exact domain name. The people who trust your brand are the ones exposed, not you directly — but the fallout (support tickets, lost trust, a customer who actually got defrauded) lands on you.
• You’re accumulating false credit. Every scanner, security questionnaire, and vendor-risk tool that checks “does this domain have DMARC” will mark you as compliant. You get the appearance of the control without the control. That gap tends to surface at the worst time — during a security review, after an incident, or when a customer’s security team asks to see your enforcement policy specifically, not just whether a record exists.

What it looks like when someone actually exploits it

A p=none domain being spoofed doesn’t look dramatic from the inside. There’s no alert, no bounce, nothing in your own mail logs — because the forged message never touches your sending infrastructure. It goes straight from the attacker’s server to the victim’s inbox, authenticated well enough (or simply undefended enough) to land. The first sign is usually a support ticket: someone asking why “your” invoice looks different, or a customer reporting a phishing email that used your exact domain in the From: field. By the time that happens, the damage — a defrauded customer, a support team’s afternoon, a dent in trust — is already done. DMARC aggregate reports would have shown the spoofing attempt in progress, if anyone was reading them; enforcement would have stopped the message from being delivered at all.

Why so many domains get stuck there

p=none isn’t usually a decision anyone makes twice. It’s almost always a decision made once — by whoever set up DMARC in the first place, often years ago, often as a single line item on a security checklist or a vendor’s onboarding guide — and then never revisited by anyone, because nothing about it demands revisiting. The record exists. Scanners see it and report “DMARC: present.” The person who published it moves on to the next task, and the domain quietly stays at p=none indefinitely, not because enforcement was rejected as too risky, but because nobody was ever assigned to come back and finish the job.

That’s compounded by a real, structural reason p=none is the correct starting policy: moving straight to enforcement without reading the aggregate reports first can break a company’s own legitimate mail — a marketing platform, an old CRM integration, an invoicing tool someone connected years ago and forgot exists. So the caution that makes p=none the right first step is also what makes it easy to stall on indefinitely: reading DMARC aggregate reports is unglamorous, technical work that produces no visible payoff until the day it prevents an incident, and it competes for attention against work with an obvious deadline. A security control that silently keeps working (or silently keeps not working) rarely gets prioritized over one that’s actively on fire. The 526,000-domain figure isn’t 526,000 deliberate risk tolerances — it’s mostly 526,000 instances of a task that got marked “done” the moment the record went live, when the record going live was actually the beginning of the work, not the end of it.

Ownership gaps make this worse at any organization past a certain size. DNS records tend to outlive the person who created them — a marketing hire sets up DMARC alongside a new email tool, leaves the company eighteen months later, and the record becomes nobody’s explicit responsibility. IT owns the DNS zone but doesn’t necessarily own the decision of when a policy is ready to tighten; marketing or growth owns the sending platforms but often doesn’t have DNS access at all. p=none survives in that gap because it’s nobody’s job to move it, even though moving it is usually a genuinely small amount of work once someone actually reads the reports.

Moving off p=none without breaking your own mail

The risk of p=none is real, but the fix isn’t “switch to p=reject today.” A domain that jumps straight to full enforcement before it knows its own sending sources can block its own legitimate mail — the CRM, the invoicing tool, the marketing platform someone connected two years ago and forgot about. The safe sequence:

1. Read your aggregate reports for a full cycle first. You need to see every legitimate source sending as your domain before you can safely block anything. How to read DMARC reports walks through the raw data — or, on Norbelys, the DMARC monitoring dashboard surfaces the same per-source breakdown automatically, without hand-parsing raw aggregate XML.
2. Fix what’s failing before you tighten anything. A legitimate sender failing SPF or DKIM alignment needs to be corrected, not grandfathered around with a permissive policy.
3. Move to p=quarantine with a pct= ramp, not straight to p=reject — p=quarantine; pct=25 applies the new policy to a quarter of failing mail first, so a misconfiguration costs you a quarter of your traffic instead of all of it.
4. Hold each rung long enough to catch infrequent senders — quarterly invoicing tools, annual renewal emails — before moving to the next one.

The honest version of this timeline runs months, not days, in a large organization. That’s fine. What isn’t fine is treating p=none as a permanent resting state because the record technically exists and nobody’s complained yet.

The takeaway from this year’s numbers

Roughly 526,000 domains being stuck at p=none isn’t 526,000 organizations making a considered risk decision — it’s mostly 526,000 organizations that published a record once, satisfied a checklist item, and never came back. If your domain is one of them, the 2026 data is as good a prompt as any to go check: pull your own DMARC record right now and see what the policy tag actually says. If it’s still p=none after more than a few months of watching, the reports are the thing that tells you it’s safe to move — and Norbelys DMARC monitoring keeps reading them continuously so the decision to climb isn’t a guess.

p=none — quick answers

Is p=none the same as having no DMARC record at all?+

For enforcement purposes, effectively yes — a p=none policy tells receiving servers to take no action on a failing message, so a forged email authenticates or fails exactly the same way it would with no record published. The one real difference is visibility: p=none still generates aggregate reports, which is what makes it useful as a temporary monitoring step rather than a permanent state.

How long should a domain realistically stay at p=none?+

Long enough to see a full reporting cycle — typically several weeks — with every legitimate sending source identified and passing authentication. For an established domain with several connected tools, that can stretch to a few months. There's no fixed deadline, but months of clean reports with no action taken is the pattern worth fixing.

Will moving to p=quarantine or p=reject break email from tools we forgot we'd connected?+

It can, if you skip the report-reading step. That's exactly why the safe sequence is report first, fix failing sources second, and ramp the policy gradually with a pct= value rather than jumping straight to full enforcement — a partial rollout limits the blast radius of anything the reports missed.

Who should own the decision to move off p=none inside a company?+

Whoever has both DNS access and visibility into every tool sending as the domain — often IT or a deliverability-focused role, working with marketing and sales ops to confirm every legitimate sending source before anything gets blocked. The record itself is a DNS change; the judgment call about when it's safe to tighten needs input from everyone actually sending mail.