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
Email Deliverability Monitoring Tools: What to Watch
What email deliverability monitoring tools track, the signals that matter, when manual checking breaks down and how to choose a tool that fits your sending setup.
ReadDeliverabilityShould you turn off open tracking in cold email?
Should you turn off open tracking in cold email? For most campaigns, yes. How the pixel costs placement, what you lose, and what to measure instead.
ReadDeliverabilityGoogle Retired Domain Reputation in Postmaster Tools
Google removed the Domain and IP Reputation dashboards in Postmaster Tools v2. Here is what replaced them, the arithmetic that decides whether your domains report at all, and what to watch instead.
Read