The difference between p=none and p=quarantine is the difference between watching your domain get spoofed and doing something about it. p=none tells receiving servers to deliver mail that fails DMARC as if nothing happened, and just send you a report. p=quarantine tells them to put failures in spam. Every cold email domain should start at p=none — and almost none of them should stay there as long as they do.
Most do stay there, indefinitely, because the record was pasted from a setup guide the day the domain was born and never touched again. That's rational caution the first month. After that it's just an unread report address and unclaimed protection.
What each policy actually instructs
A DMARC policy is an instruction to other people's mail servers about mail claiming to come from your domain:
| Policy | Failing mail is… | Right for |
|---|---|---|
p=none | Delivered normally, reported to you | New domains, new senders, anything unverified |
p=quarantine | Sent to the spam folder | Domains with 2–4 weeks of clean, aligned reports |
p=reject | Bounced outright | Mature domains you've watched long enough to trust completely |
The part people miss: the policy doesn't distinguish spoofers from you. If your own mail fails authentication — a broken DKIM key, a tool sending unaligned — quarantine and reject punish your campaigns. That's why the sequence is monitor, verify, then tighten, and why jumping straight to p=reject on day one occasionally bounces a company's own legitimate mail.
Why p=none first (and what to actually watch)
Since the 2024 Google and Yahoo sender requirements, bulk senders need DMARC at minimum p=none — so the monitoring stage is also the compliance stage. Publish it with a report address you control:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Then read what comes back. The rua address receives aggregate reports — XML summaries from Google, Microsoft, and others listing every server that sent mail as your domain and whether it passed. Raw XML is unpleasant; a free report viewer turns it into a table. You're answering two questions:
- Does every legitimate source pass with alignment? Your sending mailboxes should pass SPF or DKIM and the passing domain should match your From domain. Alignment is where correct-looking setups fail — DKIM signed by your provider's shared domain instead of yours passes DKIM and still fails DMARC. The SPF/DKIM/DMARC setup guide covers fixing that.
- Is anything sending that you don't recognize? Some entries are forwarders (normal). A steady stream of unknown servers failing auth as your domain is spoofing — which is precisely what enforcement stops.
When to move to p=quarantine
The checklist is short. Two to four weeks of reports where every source you recognize passes aligned, and no legitimate stream is failing. On a cold email sending domain — one tool, a handful of mailboxes, no marketing platform or HR software sending as the domain — the picture is usually clean fast. That simplicity is an advantage of keeping cold email on separate sending domains: fewer senders, faster path to enforcement.
If you want a gradual rollout, DMARC has one built in:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com
pct=25 applies quarantine to a quarter of failing mail and keeps reporting on the rest. Step it up weekly — 25, 50, 100 — watching for surprises. On a simple sending domain this is usually overkill; on anything shared with other mail streams it's cheap insurance.
Update the existing _dmarc record when you tighten. Two DMARC records on one domain is an error receivers resolve unpredictably — same class of mistake as duplicate SPF.
Is p=reject worth it for cold email?
Eventually, on domains you've watched long enough. p=reject is the strongest anti-spoofing stance and the policy Google itself moved to. The practical risk is forwarded mail: forwarding often breaks SPF, and if DKIM doesn't survive either, a legitimate forwarded reply can bounce under reject where quarantine would have delivered it to spam. For most cold email operations, quarantine captures nearly all the value; treat reject as the graduation step, not the goal.
Two flags worth knowing at that stage: sp= sets a separate policy for subdomains (spoofers love unprotected subdomains of enforced domains), and adkim/aspf switch alignment from relaxed to strict — leave those relaxed unless you have a specific reason.
Enforcement only counts while it holds
The failure mode after tightening isn't the policy — it's drift. A re-generated DKIM key that never got published, a provider migration that broke alignment, an edit that clipped the record: any of these under p=quarantine sends your own campaigns to spam, quietly, on the domain where you did everything right. Reports would tell you, weeks later, if anyone still read them.
Point-in-time checks catch what's broken today — the free deliverability checker verifies your DMARC record and policy per domain, and now hands you the exact upgraded record to paste when you're ready to tighten. Continuous coverage is the harder part at agency scale, which is what Coldops is for: it re-verifies DMARC, SPF, MX, and blacklist status across every client sending domain daily, so a record that breaks on Tuesday is an alert on Tuesday.
If your reports have been clean for a month and you're still on p=none, you've already done the hard part. Claim the protection.
Frequently asked
Is DMARC p=none enough for cold email?
What is the difference between p=none, p=quarantine, and p=reject?
When should I move DMARC from p=none to p=quarantine?
Does a stricter DMARC policy improve deliverability?
Keep reading
APRF: Aggregate Performance Reporting, Explained
Comcast sends APRF reports today and Google co-wrote the spec. What Aggregate Performance Reporting returns and why cold email cannot use it yet.
ReadDeliverabilitySURBL blacklist check: why clean domains still get filtered
A SURBL blacklist check reads the domains inside your email, not the one you send from. Why a clean sending domain still gets filtered, plus what to check.
ReadDeliverabilityHow to Read a DMARC Report (Aggregate XML, Explained)
How to read a DMARC aggregate report: what each XML field means, why SPF passing is not the same as aligned, plus when it is safe to tighten.
Read