What Does DMARC p=none Mean?

DMARC

Introduction

p=none is the most common — and most misunderstood — DMARC policy. It's the starting point of every rollout and the trap that most domains never escape. In one sentence: p=none is monitor mode. Receivers report what they saw but deliver everything as if no policy existed.

This article explains exactly what p=none does, why it provides no protection, and how to use it as the foundation it's meant to be rather than the destination it accidentally becomes.

Why this topic matters

A surprising number of domains publish p=none, watch the reports for a week, congratulate themselves, and never move on. Years later they're still at p=none — visible, monitored, and completely unprotected. Attackers can spoof the domain at will; the domain owner gets a daily XML report telling them it's happening.

The mistake is treating p=none as a security control. It isn't. It's a diagnostic stance — a way to learn what's happening so you can confidently move to p=quarantine or p=reject. Understanding the role of p=none is the difference between a DMARC rollout that completes and one that stalls indefinitely.

What p=none actually does

When a receiver gets mail claiming to be from your domain, it runs the DMARC check: did SPF or DKIM pass AND align with the From header? With p=none, the receiver:

• Delivers the message normally regardless of whether the check passed.
• Logs the result for inclusion in the daily aggregate report.
• Sends the aggregate report to the rua= address in your record.

That's it. No filtering, no spam folder, no rejection. Mail flows exactly as it would without a DMARC record published.

The instruction to receivers is essentially: "We're learning. Don't act on this yet. Just tell us what you see."

Why p=none is useful

Despite providing zero blocking, p=none is genuinely valuable — for the right duration. It does three things that no other policy state does:

1. Surfaces every sender. The aggregate reports build a per-sender table of who's sending as your domain. You'll find marketing tools you forgot about, billing platforms IT didn't know about, and the occasional attacker probing your domain.
2. Lets you measure pass rate. For each sender, you see how often DMARC passes. Anything below 100% is a remediation target before tightening policy.
3. Provides a baseline for moving up safely. When you can name every sender in the report and each is at ≥99% pass, you can move to p=quarantine with confidence.

Without that data, going straight to p=quarantine or p=reject is gambling. With it, the policy move is uneventful — which is exactly what you want.

What p=none does NOT do

A lot of subtle misconceptions cluster around p=none. Each one trips up a different team:

• It doesn't protect against spoofing. Anyone can still send mail claiming to be your domain, and it will be delivered. How attackers abuse unprotected domains applies just as much at p=none as at no DMARC record.
• It doesn't affect deliverability of your own mail. Some teams worry that publishing DMARC will hurt their newsletter. At p=none the answer is no — receivers don't act on failures.
• It doesn't satisfy security frameworks long-term. PCI DSS, insurance underwriting, and most compliance checklists treat p=none as "in progress" rather than "compliant."
• It doesn't satisfy the bulk-sender requirements technically — but it does satisfy them practically. Google, Yahoo, and Microsoft require a published policy; p=none qualifies. But it's not the protection those rules are really about.

Step-by-step approach: using p=none correctly

The right way to use p=none is as a measurement phase with a defined end date.

1. Publish the record. How to create a DMARC record covers the syntax.
2. Set up report parsing. Route rua= to a DMARC platform; raw XML isn't readable past a handful of senders.
3. Wait 2-4 weeks. Most providers send reports daily, but you need a couple of weeks of variation to capture all your senders.
4. Audit the sender list. For each row, decide: legitimate, illegitimate, or unknown. DMARC client discovery is the technique.
5. Remediate. Fix SPF and DKIM for every legitimate sender. The goal is ≥99% pass rate per sender.
6. Set a date to move to p=quarantine. That date should be on the calendar from day one. Without it, the rollout stalls.

The whole p=none phase should last 4-8 weeks for most domains. Longer than that means you've stopped doing the work.

Best practices

• Always pair p=none with a rua= destination. Publishing without reports is pointless.
• Set pct= to 100 (or omit it). pct= has no effect at p=none, so don't confuse readers by including it.
• Set sp=none explicitly. During monitoring you want subdomains in the same posture; setting it explicitly avoids inheritance surprises.
• Keep TTL low (300-3600 seconds). During the rollout you'll iterate on the record; low TTL means changes propagate fast.
• Treat p=none reports as the work plan. The senders that show up in week one are the work for weeks two through six.

When p=none is the right long-term answer

Rarely. A few legitimate cases:

• You're an external observer. A DMARC researcher monitoring others' mail isn't trying to block anything.
• You operate a parked domain. Even then, p=reject is usually a better choice.
• You're in an extended remediation cycle. A complex enterprise might spend 6-12 months at p=none while it fixes legacy senders. The intent is still to move up.

In every other case, p=none is a station, not a destination.

Recommended next step

If you're at p=none today, the question to answer is: can I name every sender in my reports and is each at ≥99% pass? If yes, set a date — within the next 30 days — to move to p=quarantine pct=10. The full progression is detailed in how to move from DMARC monitoring to enforcement safely.

If no, the work is the remediation. Common DMARC errors covers the typical failure modes.

FAQ

How long should I stay at p=none?

Long enough to be confident every legitimate sender is passing — typically 2-8 weeks. Longer than that means the rollout has stalled and needs to be re-energized, not extended.

Will p=none stop spoofing at all?

No. None. Spoofed mail will be delivered exactly as before. The only thing that changes is that you'll see evidence of the spoofing in your reports.

Can attackers see that I'm at p=none?

Yes. The DMARC record is public DNS — anyone can look it up. Some sophisticated phishing campaigns specifically target p=none domains because they know exact-domain spoofing will work.

Does p=none satisfy Google and Yahoo's sender requirements?

Technically yes — they require a published DMARC policy, and p=none counts. But the spirit of the requirement is protection, which p=none doesn't provide. Plan to move up.

What if I'm at p=none and don't see any reports?

The rua= address is wrong, the receiving mailbox is rejecting the reports, or your domain has effectively zero traffic to providers that send DMARC reports. Validate the record syntax and try a known-active receiver.

Final thoughts

p=none is the right starting policy and the wrong ending policy. Treated as a measurement phase with a defined exit date, it's the foundation of every clean DMARC rollout. Treated as a destination, it's the most common DMARC mistake there is — security theatre with daily XML email.

The signal that you're using p=none correctly is that your aggregate-report dashboard drives a stream of remediation actions and you have a calendar date for the next policy move. The signal that you're using it incorrectly is silence: reports arrive, no one reads them, and the record sits there for years providing nothing.

If your reports are silence, the work is the work — start by naming every sender. The next policy move follows from there.