My DMARC is set to p=none — is that enough?
Scott Anderson · Last reviewed
Short answer
No. p=none is monitoring mode: it asks receiving servers to report on mail that fails authentication, but instructs them to take no action. It satisfies the letter of Gmail's and Microsoft's requirements and stops no spoofing at all. It is the correct first step and the wrong place to stop.
Key facts
DMARC defines three policies: none, quarantine and reject. Only the last two change what receivers do with failing mail. RFC 7489 §6.3 ↗
Google accepts p=none as satisfying the DMARC requirement for bulk senders. Google sender guidelines ↗
Without a rua= tag, a p=none record produces no reports — it neither blocks anything nor tells you anything. RFC 7489 §6.3 ↗
A great many domains published DMARC in early 2024, set it to p=none because that was what the guides said to do first, ticked the box, and never touched it again. Two years later they are still in monitoring mode, still fully spoofable, and under the impression they are protected.
That is the single most common finding in this work. It's worth understanding exactly what the setting does before deciding whether it's where you want to stay.
What the policies actually instruct
p=none
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Deliver failing mail as normal, but send me reports about it.
p=quarantine
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
Put failing mail in the junk folder.
p=reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Refuse failing mail outright. It never reaches the recipient.
What p=none is genuinely good for
Monitoring mode exists for an excellent reason. Before you can safely tell the world's mail servers to refuse anything that fails, you need to know everything that legitimately sends as you — and almost nobody has that list written down.
With rua= configured, receiving servers send daily aggregate reports naming every source that sent mail claiming to be your domain, and whether it passed. Two or three weeks of those reports typically surfaces two or three systems the business had entirely forgotten: an old CRM, a website form relaying through the web host, a booking tool set up by someone who has since left.
What it costs you to stay there
While you're at p=none, anyone can send email that appears to come from your business, and receiving servers have been explicitly instructed not to interfere. That's the mechanism behind the invoice-redirection fraud that hits Australian small businesses: a convincing message from your address, to your customer, with different bank details.
The reputational damage lands on your domain, and the financial damage lands on your customer, who will remember which of you it appeared to come from.
Moving from none to reject without breaking anything
Staged, monitored, and reversible at every point.
- 01
Weeks 1–3: read the reports
Stay at p=none with rua= set. Collect reports until you recognise every sending source in them. Aggregate reports are XML; a free parser or a monitoring service makes them readable.
- 02
Authenticate everything legitimate you found
Add each real sender to SPF and enable DKIM for it. This is the actual work — the policy change at the end is a one-line edit.
- 03
Move to quarantine, partially
Set p=quarantine with pct=25, then raise it. Failing mail goes to junk rather than vanishing, so mistakes are recoverable and visible.
- 04
Go to full quarantine, then reject
Once a fortnight at 100% quarantine passes without complaints, move to p=reject. This is the setting that ends spoofing of your domain.
- 05
Keep reading the reports
New tools get added, staff change, records get edited by someone helpful. Enforcement without monitoring drifts back into failure.
A note on pct=
The pct tag applies your policy to a percentage of failing mail, and it's the standard way to ease into enforcement. It's also a common place to find a rollout that stalled: a record reading p=reject; pct=10 looks strict at a glance while ninety percent of failing mail sails straight through.
If you see a percentage below 100 in your own record, the question to ask is whether it was left there deliberately or simply forgotten.
Frequently asked
Will p=reject block my own legitimate email?
Only mail that fails both SPF and DKIM alignment, which should be nothing once every legitimate sender is authenticated. That's precisely why the staged rollout exists: you enforce after the reports are clean, not before. And if something does go wrong, reverting is a one-line DNS change that takes effect in minutes.
What about forwarded mail — doesn't that always fail?
Forwarding breaks SPF by design, but DKIM signatures usually survive it, and DMARC only needs one of the two to pass. This is the practical reason DKIM is not optional. Mailing lists that rewrite message bodies are the genuinely awkward case, and ARC exists to help with them.
How do I read the aggregate reports?
They arrive as compressed XML, which is unreadable by design rather than by accident. Use a free parser, a monitoring service, or have someone summarise them for you. Ongoing Watch does exactly that if you'd rather not think about it monthly.
How long does the whole rollout take?
Typically four to six weeks, most of which is waiting on reports rather than doing anything. The work itself is an afternoon of DNS changes plus enabling DKIM in each platform.
Find out where your domain actually stands.
The checker reads your real records in a few seconds. The review works out whether they cover everything you send.