Introduction
The p= tag in a DMARC record is the policy instruction your domain sends to every mailbox provider on the internet. It answers a single question: "When mail claiming to be from this domain fails authentication, what do you want us to do with it?"
There are exactly three valid answers — none, quarantine, and reject — and they correspond to monitoring, soft-blocking, and hard-blocking respectively. Choosing the right one isn't a question of which sounds strictest; it's a question of where you are in the rollout from monitoring to enforcement. The wrong policy at the wrong time either provides no protection or blocks legitimate mail. The right policy at the right time produces a domain that cannot be exact-spoofed.
This article walks through each option, what receivers actually do with it, and how to move from one to the next without an incident. If you haven't yet, the beginner's guide to DMARC covers the framing.
What each policy actually instructs receivers to do
DMARC policies are receiver hints, not hard rules — a receiver can always choose to ignore your policy — but in practice every major mailbox provider honours them.
p=none — monitor mode. The receiver delivers the message exactly as it would without DMARC, but sends you an XML aggregate report once per day showing what they saw. This is the right starting point and the wrong endpoint. No protection is in place; you're listening.
p=quarantine — soft-fail mode. The receiver delivers failing mail to the spam folder rather than the inbox. The user can still find it. Some providers (Gmail in particular) hedge with a pct= percentage or only apply quarantine if the message is otherwise suspicious. Quarantine is useful as a stepping stone but it's a half-measure: phishing emails in the spam folder are still phishing emails, and any user who searches their spam folder for "invoice" can still be tricked. Why enforcement matters more than monitoring makes the broader case.
p=reject — hard-fail mode. The receiver bounces the message at the SMTP gate. The sending IP gets a 5xx error; the message never enters the user's mailbox in any folder. This is the endpoint. At p=reject, exact-domain spoofing of your brand becomes operationally impossible — the attacker can send the message, but no recipient on the major mailbox providers will ever see it.
Why this matters
The default state of a domain on the internet is spoofable. Without a DMARC record, anyone can write your domain in the From header and the receiving server has no instruction from you on whether to trust it. They'll usually deliver it — that's exactly how attackers abuse unprotected domains.
p=none doesn't change that — it just tells you it's happening. p=quarantine reduces the impact. p=reject eliminates the attack vector entirely. Every additional week spent at p=none is a week where a phishing wave can still hit your customers' inboxes from your domain.
The flip side: jumping to p=reject while a legitimate sender is misconfigured will instantly bounce that sender's mail at every major provider. That's how DMARC rollouts get rolled back in panic. The whole challenge of moving from none to reject is sequencing it so legitimate mail is at 100% pass before the policy tightens — covered in detail in common DMARC errors and how to fix them.
Step-by-step approach: moving safely between policies
The progression none → quarantine → reject is the textbook path, but the speed of progression is what determines whether you ship safely.
- Publish
p=nonewith reporting.v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]. Therua(aggregate) address gets daily XML summaries;ruf(forensic) gets individual failure copies where supported. - Wait for two weeks of reports. A DMARC platform will turn the XML into a per-sender table with volume, pass rate, and source IPs. Until you can name every sender in that table, you cannot move to quarantine. DMARC client discovery walks through the inventory process.
- Remediate every legitimate sender that's failing. Most failures fall into three buckets: SPF doesn't include the sender's IPs, DKIM isn't configured on that platform, or DKIM is configured but the d= domain doesn't align with the From domain. Each is fixable; each takes a configuration change at the sending platform.
- Move to
p=quarantinewithpct=10. Thepct=tag tells receivers to apply the policy to only that percentage of failing mail. Starting at 10% gives you a controlled experiment. Watch reports for two more weeks. - Ratchet
pct=upward.pct=25,pct=50,pct=100. At each step, watch for new sources you didn't expect — these are usually internal teams who set up a new tool without telling IT. How to handle third-party senders during DMARC projects covers the recurring pattern. - Move to
p=rejectwithpct=100. Or stepped viapct=if your reports show any residual ambiguity. Once atp=rejectwith 100%, your domain is unspoofable on every major mailbox provider.
Time-wise, the full path is 8-16 weeks for a domain with normal sender complexity. Faster for a small domain, slower for an enterprise with 50+ sending platforms.
Best practices
A few rules that separate clean rollouts from rollbacks:
- Don't use
pct=atp=none. It has no effect — receivers aren't acting on failures anyway. Save it for quarantine and reject. - Match
sp=top=explicitly. The subdomain policy defaults to inheritingp=if not set, but many domains have a non-sending parent and high-volume subdomains. Setsp=rejecteven when the parent doesn't send, so attackers can't pivot to a random subdomain — see DMARC for subdomains. - Use a real address for
rua=, not a personal inbox. Aggregate reports can be hundreds per week for an active domain. Route them to a dedicated mailbox that a DMARC platform reads automatically — manual parsing is a fool's errand past a few dozen senders. - Don't add
ruf=unless you actually parse it. Forensic reports include individual failed messages and can leak sensitive content from forwarded mail. Most providers don't send them anyway. Skip unless you have a specific incident-response workflow that consumes them. - Keep
adkim=andaspf=at relaxed alignment (the default) until you have a specific reason to move to strict. Strict alignment (s) requires the DKIM signing domain and the From domain to match exactly — useful for high-stakes domains but easy to misconfigure. The trade-offs are unpacked in DMARC alignment explained.
When to stay at p=quarantine long-term
Almost never. The only legitimate reasons to stop at quarantine:
- A regulator or insurer specifically requires that you not bounce mail (rare).
- You have a high-stakes legitimate sender that absolutely cannot be moved to authenticated infrastructure within the rollout window, and you'd rather quarantine its mail than block it.
In both cases the right answer is usually still to fix the sender and move to reject — quarantine is a stepping stone, not a destination. Why your DMARC record is not working covers the most common reasons people get stuck mid-rollout.
Recommended next step
If you're currently at p=none, check your aggregate reports for pass rate by sender. You can move to p=quarantine pct=10 the day every known sender shows ≥99% DMARC pass. The DMARC AI platform shows pass rate per sender in one click and flags new senders the day they first appear, so the transition decision is a one-screen check rather than a spreadsheet exercise.
For MSPs, this is the engagement most clients pay for repeatedly — the configuration work happens once, but the monitoring and gradual progression require a steady hand and a system that doesn't lose track of which clients are at which stage. The MSP guide to selling DMARC services covers productizing it.
FAQ
What's the difference between p=quarantine and p=reject?
Quarantine delivers failing mail to spam; reject bounces it at SMTP. Both stop the message from reaching the inbox, but reject also prevents the message from existing on the recipient's server at all. From a user-protection standpoint, reject is strictly better — a phishing message in spam can still be opened.
Can I skip p=quarantine and go straight from none to reject?
Technically yes, if you're confident every legitimate sender is at 100% pass. In practice, going through quarantine for 2-4 weeks gives you a safety net — failures land in spam where you can verify they were attacks, not your own newsletter.
How long should I wait at p=none before moving to quarantine?
Until two consecutive weeks of aggregate reports show no surprises and all named senders are at ≥99% pass. For a small domain that's often 2-3 weeks; for a complex enterprise it can be 6-8 weeks. The signal is the data, not the calendar.
What does pct=10 actually do?
It tells receivers to apply the policy to only 10% of failing messages. The other 90% are treated as if your policy were the next-weakest level. So p=quarantine; pct=10 means 10% of failures go to spam and 90% are delivered (as if p=none). Useful for controlled rollouts.
Will p=reject block forwarded mail?
It can, if the forwarding service rewrites the From header without preserving DKIM. Most modern mailing-list software handles this correctly via DKIM signature passing or rewriting the From header to the list address. Watch your reports for systematic failures from mailing-list IPs as you move toward reject — those are usually safe to push through but worth confirming. The provider-specific guides (Microsoft 365, Google Workspace, Mimecast, Proofpoint) cover platform-specific forwarding quirks.
Final thoughts
p=none is a flashlight. p=quarantine is a strainer. p=reject is a lock. Every domain owner ends up at the same destination — p=reject is the only setting that fully stops exact-domain spoofing — but the time between flashlight and lock is where the work happens.
A clean rollout depends on three things: full visibility into your senders, a structured remediation phase that doesn't skip any of them, and patience to use pct= rather than flipping reject on like a light switch. Get those right and the policy progression is uneventful, which is exactly how it should feel.