What p=none actually does
p=none is DMARC's monitoring policy: it explicitly asks receivers not to change how they handle a message on the basis of DMARC. It gives you aggregate reports — visibility into who is sending as your domain and whether they align — but it provides no protection against spoofing. It is the correct first stage of a deployment and the wrong place to stop.
v=DMARC1; p=none; rua=mailto:[email protected]
What you gain
Aggregate reports. Receivers send you XML summarising the mail they saw claiming to be from your domain: source IP, volume, whether SPF and DKIM passed, and crucially whether they aligned. This is the only practical way to inventory your own senders — and almost every organisation discovers at least one it had forgotten.
What you do not gain
Protection. This is the part that gets glossed over. p=none is not a weak
enforcement setting; it is an explicit instruction not to enforce. A phisher spoofing
your domain is delivered exactly as they would be if you had no DMARC record at all. You will see
them in your reports. Nothing will stop them.
From: is your domain, SPF does not align, and it contributes nothing to
DMARC. Alignment is where most "but I set everything up!" failures actually live.
Before you raise enforcement
- Collect reports across normal and infrequent sending cycles. The quarterly invoice run is the one that bites.
- Classify every source. Anything you cannot identify is either a sender you forgot or an attacker, and you need to know which.
- Get aligned DKIM working wherever possible — it survives forwarding, SPF does not.
- Check forwarding, mailing lists, support desks, and vendor workflows specifically. These are where enforcement breaks legitimate mail.
- Move to
quarantine, thenreject, reading reports after each step. Usesp=to hold subdomains back if they are not ready.
pct= to stage this. It was removed from the DMARC
specification by RFC 9989 in May 2026. A lot of otherwise
good tutorials still recommend it.
Check your record
We parse the live record and report policy, alignment mode and reporting addresses.
Frequently asked
Does DMARC p=none protect against spoofing?
No. p=none explicitly asks receivers not to alter message handling based on DMARC. Someone spoofing your domain will still have their mail delivered exactly as it would have been without a DMARC record. What p=none gives you is reporting, so you can see the spoofing — not stop it.
Is p=none enough for Gmail's bulk sender requirements?
Yes, for that specific requirement. Google requires bulk senders to publish a DMARC record and accepts p=none as the minimum policy. It satisfies the checkbox. It does not protect your domain, and you should treat it as a starting line rather than a finish line.
How long should I stay at p=none?
Long enough to see a full sending cycle — including the infrequent stuff. Invoicing, annual renewals, the HR system, the ticketing tool, the one marketing blast a quarter. If you enforce before you have observed a rare-but-legitimate sender, you will reject your own mail. For most organisations that is several weeks to a few months, not days.
Related
- DMARC has a new RFC — and pct is gone — RFC 9989 (May 2026) obsoletes RFC 7489 and RFC 9091.
- Every DMARC tag, explained — A complete reference for DMARC record tags as of RFC 9989 — what each one does, which are required, which are safe to omit, and which no longer exist.
- DMARC aggregate reports, and how to actually read one — The rua tag gets you XML reports from receivers showing who is sending as your domain.
- SPF vs DKIM vs DMARC — Three records, three different jobs.
Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.