Why DMARC p=none is not protecting you

There is a particular false comfort in checking your domain's DNS, seeing a DMARC record, and ticking the box. "Yes, we have DMARC." On security questionnaires, in board updates, at insurance renewal - box ticked.

But if that record says p=none, here is the uncomfortable truth: nothing is being blocked. Anyone, anywhere, can still send email that claims to be from your domain, and it will be handled exactly as it would be if your DMARC record did not exist. The lock is fitted; the door is open.

This is not a niche problem. Sitting permanently at p=none is one of the most widespread misconfigurations in UK email security - common enough that the National Cyber Security Centre's (NCSC) guidance explicitly frames p=none as a starting point to progress from, not a destination.

What p=none actually means, technically

A DMARC (Domain-based Message Authentication, Reporting and Conformance) record tells receiving mail servers what to do with email that claims to come from your domain but fails authentication - that is, mail that cannot pass an aligned SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) check.

The p= tag carries your instruction:

• p=none - take no action. Deliver the mail as normal.
• p=quarantine - treat it as suspicious, typically delivering to spam.
• p=reject - refuse it outright.

At p=none, a spoofed email fails every authentication check, the receiving server duly notes the failure - and delivers it to your client's inbox anyway, because that is precisely what you have instructed it to do.

The one thing p=none does deliver is reporting. If your record includes a rua= address, receiving providers send daily aggregate reports describing everything they saw. That is genuinely valuable - but only if someone is actually receiving and reading those reports. A p=none record with no reporting address, or with reports flowing to an unmonitored mailbox or a retired service, accomplishes nothing whatsoever.

Why p=none exists - and why starting there is correct

It would be reckless to publish p=reject on day one. Most organisations send email from more places than they realise: the mail provider, yes, but also the accounting package that emails invoices, the newsletter platform, the CRM, the booking system, the multifunction printer in the corner. Many of these were set up years ago by people who have since left.

If any of those legitimate senders is not correctly authorised in your SPF record or signing with DKIM, a jump straight to p=reject blocks your own email. Invoices stop arriving. Appointment confirmations vanish. And because rejected mail produces no bounce to you in many configurations, you may not find out until a customer phones to ask where their invoice is.

p=none is the monitoring phase that prevents this. You publish the record, collect reports for a few weeks, and build a complete picture of every legitimate source - then fix each one's authentication before tightening the policy. Monitoring at p=none is necessary. It is just not the end of the journey, and the danger is mistaking the first step for the last.

The progression, done safely

1. Publish DMARC at p=none with a working reporting address. Visibility first.
2. Identify every legitimate sender from the aggregate reports - typically two to six weeks of data gives a reliable picture, including monthly senders like payroll runs.
3. Fix authentication for each legitimate source: add missing senders to SPF (watching the 10-lookup limit), enable DKIM signing wherever the platform supports it.
4. Move to p=quarantine, ideally staged - DMARC supports a pct= tag to apply the policy to a percentage of mail first.
5. Watch the reports. Any legitimate source you missed now shows up being quarantined; fix it.
6. Move to p=reject, and keep monitoring permanently. New senders get added by well-meaning colleagues all the time; keys rotate; configurations drift. The reports are how you find out before your customers do.

The NCSC recommends p=reject as the goal for all domains - including parked domains you do not send from at all, which are otherwise free ammunition for fraudsters.

The honest summary

• p=none is the right place to start and the wrong place to stay.
• p=none with nobody reading the reports is indistinguishable from having no DMARC at all.
• Jumping to p=reject without a monitoring period risks blocking your own legitimate email.
• The entire journey is driven by aggregate reports - which is why the question "who reads our DMARC reports?" matters more than "do we have a DMARC record?".

If you are not sure what those reports even look like, we have unpacked one in What does a DMARC report actually show? - and if you are starting from scratch, begin with What is DMARC?.

Find out where your domain stands

SealedMail's Free Domain Health Check tells you, among other things, exactly what your current DMARC policy is and whether your reporting addresses are pointing somewhere that still exists. It covers SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and blacklist status, delivered as a scored certificate by email - free, no sign-up, no sales call.

And if your organisation is at p=none and wants to make the journey to enforcement with someone reading the reports each week and explaining them in plain English, that is precisely the service SealedMail provides, at £49 per domain per month.