2026-07-24 · RESEARCH · The Offensive Technology team

Is p=none Enough? Why Publishing DMARC Isn't the Same as Enforcing It

Is DMARC p=none enough? No. p=none does not stop spoofing. It only monitors. If your domain sits at p=none, receivers send you reports but still deliver forged mail bearing your name, so your domain can still be spoofed. We resolved 300 top domains over public DNS and read their email-authentication records to see how common this mistake is. Publishing looks healthy: 84.7% publish a DMARC record. Enforcement is where it falls apart. Only 67.3% actually enforce DMARC with a policy of quarantine or reject. Among the 261 domains that receive mail, about 30% enforce nothing, because they sit at p=none, publish no usable policy tag, or publish no DMARC at all. If you inherited a DMARC record and assumed it protects you, this is the gap you are standing in.

Publishing DMARC is not the same as enforcing it

Email authentication is three records people tend to treat as one checkbox. SPF (RFC 7208) lists which servers may send for a domain. DKIM (RFC 6376) signs a message so a receiver can verify it was not altered. DMARC (RFC 7489) ties those checks to the visible From address and tells receivers what to do when they fail.

That last clause is where publishing versus enforcing DMARC parts ways. A record can exist and still instruct receivers to do nothing. The policy lives in the p= tag, and it has three settings. This is the whole of p=none vs reject:

• p=reject tells receivers to refuse mail that fails. This is what actually stops someone forging your domain.
• p=quarantine tells receivers to treat failing mail as suspicious, usually routing it to spam. Enforcing, if weaker than reject.
• p=none tells receivers to send reports and otherwise deliver failing mail normally. Forged mail still lands. This is monitoring, not defense.

So the honest question is not "does this domain have DMARC" but "does its DMARC enforce." What does DMARC enforcement mean in practice? It means the receiver is told to act on a failure rather than log it. In our sample, the two numbers diverge by nearly eighteen points: 84.7% publish a record, 67.3% enforce one. That eighteen-point gap is domains that did the visible work, edited their DNS, put a record in place, and stopped one step short of the part that blocks anything.

The data: published versus enforcing

Here is the full sample. Publishing controls run high, enforcement and the transport layers run low.

Now the policy distribution. This is the table that answers the question directly: of the domains that actually take mail, how many are at p=none or worse.

Read the bottom three rows together. That is 29.9% of mail-receiving domains where forged mail bearing their name is not stopped by DMARC. These are domains that actively receive mail, so this is not a technicality about parked or non-sending zones. It is the same impersonation opener we described in our guide to what attackers can see about your company, still open on nearly a third of live mail domains near the top of the web. If you have a DMARC record but are still getting spoofed, the p=none row is almost certainly where you sit.

The enforcement gap

We call the space between 84.7% published and 67.3% enforcing the DMARC enforcement gap, and it is the whole point of this measurement. Publishing a record is cheap and visible, so it happens. Turning that record into something that blocks mail requires an organization to know its own senders well enough to reject the rest without breaking real business email. That second step is where domains stall, and the stall is measurable.

Frame it from the attacker's chair, because that chair decides whether a control matters. You want to send mail that appears to come from a target's own domain, to that target's finance team or to one of its customers, asking to move a payment or reset a credential. You check the target's DNS first, the same way we did. If the domain publishes p=reject, your forged mail is refused at the receiving side and never reaches the inbox. That plan is dead. If the domain publishes p=none, nothing changes for you. The receiver notes the failure in a report that goes to the domain owner, not to your victim, and delivers your message anyway. So can my domain be spoofed at p=none? Yes, exactly as easily as with no DMARC at all.

What makes our number worth citing is how we got it. This is independent passive measurement, not vendor telemetry. We are not reporting mail our own product filtered, and we are not extrapolating from one provider's inbound stream. We read the public policy that every receiver on the internet reads, the record itself, for a fixed sample on a fixed date. That is a different and more neutral vantage point than a security vendor reporting on the traffic it happens to see.

How to check your own domain

You do not need a tool or a signup for this. Read your own public DNS and look at one tag. Anyone can run these lookups against any domain, because a DNS query is a passive read of records that are already public.

• Check the DMARC policy. Run dig TXT _dmarc.yourdomain.com +short and read the p= tag. p=reject or p=quarantine means you are enforcing. p=none, or no p= tag, or no record at all, means you are not enforced and your domain can be spoofed.
• Check SPF. Run dig TXT yourdomain.com +short and look for a record starting v=spf1. Missing SPF weakens the alignment DMARC depends on.
• Check the transport and integrity layers. Run dig DS yourdomain.com +short for DNSSEC and dig TXT _mta-sts.yourdomain.com +short for an MTA-STS announcement. Both are usually absent, as the data above shows.

If the DMARC lookup comes back with p=none, you have your answer: the record is publishing, not enforcing, and you are in monitoring mode only.

Moving from p=none to enforcement

The path from none to reject is well worn, and the honest part is that the DNS edit is the easy bit. The work is confirming you will not break legitimate mail when receivers start acting on failures. Here is how to move DMARC from none to reject without cutting off your own senders:

• Stay at p=none only long enough to inventory. Point the rua= tag at a mailbox or a report parser and read the aggregate reports until you can account for every source sending mail as your domain, including marketing platforms, ticketing systems, and third parties.
• Move to p=quarantine, ramping with pct if you want to be cautious. A pct= value applies the policy to a fraction of failing mail so you can watch for legitimate senders failing alignment before it applies to everything. Fix any real sender that fails SPF or DKIM alignment before you widen it.
• Move to p=reject once the reports are clean. When no legitimate source is failing, reject is the setting that stops forgery outright. This is the only state where the answer to "is p=none enough" becomes moot, because you have left p=none behind.

While you are in the DNS anyway, announce MTA-STS so inbound mail cannot be quietly downgraded to cleartext, and sign your zone with DNSSEC so the lookups that fetch your policy cannot be spoofed. MTA-STS adoption sits at just 4.7% in our sample, so doing it puts you ahead of almost everyone. DNSSEC also gates stronger schemes such as DANE, and its scarcity at 20.0% caps how far mail security can go for four in five of these domains. The judgment behind enforcing without breakage is the same one behind knowing which of your certificate-issuance controls and exposed surfaces actually matter and which are noise.

What this does not prove

Honest limits, because a number without its caveats is marketing.

• Majestic ranks by backlinks, not traffic. The Majestic Million orders sites by referring subnets and links, which favors long-established and heavily-cited domains. That is a different population than a traffic-ranked list, so read these as one honest slice, not the whole internet.
• It is a 300-domain sample. Every percentage carries sampling error. A figure like 67.3% enforcing means 202 of 300 domains, and a different 300 would shift it a few points.
• It is a snapshot. DNS changes daily. These figures describe 24 July 2026, not a trend. A domain at p=none today may be mid-rollout and enforcing next month.
• It is a DNS-only view. A published p=reject is not proof that a domain's SPF and DKIM are correctly aligned for its real senders. We read the policy that receivers act on, not the delivered mail. It is a statement about published intent, not about a flawless deployment.
• Enforcement is coarse. We count p=quarantine and p=reject as enforcing. In the field, a quarantine policy with a low pct or lax alignment mode still lets some forged mail through, so the enforcing figure is, if anything, generous.

Frequently asked questions

Is p=none enough to stop email spoofing?

No. p=none is monitoring only. Receivers report failures but deliver forged mail as normal, so mail bearing your domain still reaches inboxes. It is a fine first stage while you inventory senders, but it blocks nothing until the policy moves to quarantine or reject.

Can my domain still be spoofed if I have a DMARC record?

Yes, if that record is at p=none. Having a record is not the same as being protected. Only p=quarantine or p=reject tells receivers to act on mail that fails authentication.

What is the difference between publishing and enforcing DMARC?

Publishing means a _dmarc record exists. Enforcing means its policy is p=quarantine or p=reject. A record at p=none blocks nothing. In our July 2026 sample, 84.7% published a record but only 67.3% enforced one.

What percentage of domains actually enforce DMARC?

In our 300-domain sample, 84.7% published DMARC and 67.3% enforced it. Among the 261 mail-receiving domains, roughly 30% enforce nothing.

Is p=none the same as having no DMARC?

For stopping spoofing, effectively yes. To an attacker the outcome is identical: forged mail is delivered. The difference is that p=none produces reports you can use to reach enforcement.

How do I move DMARC from none to reject?

Read your aggregate reports at p=none until every legitimate sender is accounted for, move to p=quarantine (optionally ramping with a pct tag), fix any real sender failing alignment, then set p=reject.

Why am I still getting spoofed with DMARC set up?

Almost always because the policy is at p=none, or because SPF and DKIM are not aligned for your senders so an enforcing policy cannot pass. Check the p= tag on your _dmarc record first.

Related reading

• How exposed are the world's busiest domains to email spoofing? The presence question this post builds on.
• How many top domains restrict who can issue their certificates? The same passive-DNS method, applied to CAA records.
• What can attackers actually see about your company?