Blog · Dmarc
Is DMARC at p=none Just Security Theater?
TL;DR
p=none is monitoring-only. It does not reject, quarantine, or block anything. It only asks receiving servers to send you reports about your email traffic.
What Does DMARC at p=none Actually Do?
When you publish a DMARC record with p=none, you are telling receiving mail servers: "Do not change how you handle my mail based on my DMARC policy. Just send me reports."
That is all it does.
The three DMARC policy levels in plain terms:
- p=none - keep handling my mail as you normally would, and send me aggregate reports
- p=quarantine - treat my mail as suspicious and route it to the spam or quarantine folder, but do not reject it outright
- p=reject - refuse to accept mail that fails DMARC checks from your domain
p=none is the starting point. It is the policy level you publish while you are still learning what your email ecosystem looks like before you start enforcing rules that could break legitimate mail flow.
If you see p=none in a dashboard and it is marked as "protected" or "compliant," that is a interpretation that deserves scrutiny.
What p=none Does NOT Protect Against
This is where the security theater argument has real teeth.
p=none does not:
- Block spoofed emails - a attacker can forge your domain in the From address and any receiving server running p=none will deliver it normally, because p=none says "do not change anything"
- Prevent lookalike domain attacks - attackers who register dmarcflows.com instead of dmarcflow.com are not affected by your DMARC policy at all; your DMARC record only covers your exact domain
- Stop third-party senders from breaking your email reputation - if a vendor, newsletter service, or marketing platform sends mail "from" your domain without proper authentication, p=none will not stop that mail from being delivered
Here is a concrete scenario. An attacker sends a phishing email to your CFO, forging your domain in the From header. The CFO's mail server checks DMARC and sees p=none. It delivers the email. Your DMARC policy had no effect on that delivery. You will get a report about it after the fact, if the receiving server chose to send one, but the mail was not stopped.
That is the gap p=none leaves wide open.
What You Can Actually See with p=none
Here is the other side of the argument. p=none is not useless if you actually use the reports it generates.
A DMARC aggregate report (sent to your rua address) tells you:
- Which mail servers are sending email on behalf of your domain
- Whether those servers are passing SPF, DKIM, both, or neither
- Which receiving servers are accepting or rejecting your mail
- Whether any third parties are sending mail that appears to come from your domain without passing authentication
This data is genuinely useful. You can use it to:
- Find legitimate senders you did not know were using your domain
- Catch vendors who are misconfiguring their email and causing authentication failures
- Identify external services that are sending unauthenticated mail "from" your domain
- Track whether your own email infrastructure is consistently passing alignment checks
The problem is that almost nobody reads these reports. They are XML files, often delivered in compressed archives, and they are not designed to be human-readable. p=none without active report monitoring is like installing security cameras and never watching the footage.
Is It Security Theater?
The honest answer is: it depends on what you do with it.
If p=none is published and the reports are never opened, analyzed, or acted upon, then yes, it is largely theater. You have the appearance of email authentication without the substance. An attacker spoofing your domain will not be stopped. A vendor sending mail incorrectly will not be flagged. Your DMARC record exists but changes nothing about your actual risk.
If p=none is published and the aggregate reports are actively monitored, it becomes a detection layer. You will know within hours or days when something suspicious is happening with your domain. You will see third-party senders you did not authorize. You will catch authentication misconfigurations before they cause major deliverability problems.
The difference between these two outcomes is entirely in the monitoring.
Most practitioners who publish p=none are in the first category. They set it and forget it. The dashboard turns green. The compliance checkbox gets ticked. And the reports pile up in an inbox nobody checks.
When to Move from p=none to p=quarantine or p=reject
The common advice is to move to p=reject "as soon as you are ready." That advice is vague and has caused real email outages.
The practical readiness criteria for moving to p=reject:
1. You have reviewed at least 4 to 8 weeks of aggregate reports
2. Every legitimate sender using your domain is passing SPF or DKIM alignment
3. You have identified and resolved any third-party senders that are not properly authenticated
4. You have a process for adding new legitimate senders to your SPF record or DKIM signing before they cause authentication failures
5. You have a monitoring alert that fires when your authentication pass rate drops below a threshold you define
If criterion 2 sounds like a lot of work, that is because it often is. Many organizations discover dozens of services they did not know were sending "from" their domain once they start reading reports at p=none.
Moving to p=quarantine before p=reject is a valid intermediate step. It will not block mail outright, but it will cause failing mail to land in spam, which usually generates complaints that surface the problem faster than aggregate reports alone.
How DMARCFlow Helps at p=none
p=none is only as useful as your ability to read and act on what the reports tell you.
DMARCFlow connects to your aggregate report endpoint and converts those XML files into plain-language summaries. It tells you which servers are sending mail for your domain, which are failing authentication, and when something unusual is happening.
The practical value at p=none: you catch problems faster than you would by manually reviewing XML archives. If a new third-party sender starts sending mail from your domain without proper DKIM signing, DMARCFlow alerts you to it rather than waiting for a complaint or a deliverability problem to surface.
At p=none, DMARCFlow is the layer that turns monitoring into something you actually do.
FAQ
Does p=none protect against spoofing?
No. p=none tells receiving servers to handle your mail normally. It does not instruct them to reject or filter anything. Spoofed emails that pass SPF or DKIM alignment checks will be delivered normally under a p=none policy.
Does p=none mean my email is authenticated?
Your domain is authenticated when your sending servers pass SPF or DKIM checks. p=none is the policy you apply to mail that fails those checks. A p=none policy on a domain that is not properly configured for SPF and DKIM provides no authentication assurance at all.
How do I move from p=none to p=reject safely?
Start by reviewing aggregate reports for 4 to 8 weeks. Identify every legitimate sender. Ensure each one is passing SPF or DKIM alignment. Add any missing senders to your SPF record or configure DKIM signing for them. Then update your DMARC policy from p=none to p=reject in small steps, monitoring the reports for any sudden drop in authentication pass rates.
What happens if I move to p=reject too early?
If a legitimate sender is not yet authenticated and you move to p=reject, their mail will be rejected. This commonly happens with marketing platforms, legacy CRMs, or internal tools that were set up before email authentication was considered. The fix is to identify the sender in the aggregate reports and add them to your SPF record or configure DKIM signing before enforcing reject.
Is p=quarantine safer than p=none?
Yes, in one specific way: mail that fails DMARC checks will be treated as suspicious and routed to spam rather than delivered to the inbox. This reduces the blast radius of a spoofing attack, though it does not prevent it. p=quarantine is a useful intermediate step if p=reject feels too aggressive given your current senders.