DMARC policies: none vs quarantine vs reject — when to use each

The p tag in your DMARC record decides what happens to mail that fails authentication: nothing, the spam folder, or outright rejection. Pick wrong and you either leave the door open to spoofers — or block your own legitimate mail. Here's what each policy does, when to use it, and how to move between them safely.

What is a DMARC policy?

A DMARC policy is the instruction you publish in your TXT record at _dmarc (for example _dmarc.example.com), telling receiving servers what to do with mail that fails DMARC checks. It lives in the p= tag. There are only three possible values, and the whole rollout game is knowing when to move from one to the next. For the broader rollout picture, see our DMARC rollout guide.

What does p=none do?

p=none means "take no action on failing mail." Receivers deliver it as normal. That sounds pointless, but it's the most important policy you'll publish: combined with the rua reporting tag, it turns every receiving server into your informant. They send you aggregate reports listing every IP and service sending mail as your domain — your Google Workspace, your cold-email tool, your invoicing software, and any spoofer pretending to be you.

Use p=none when: you're publishing DMARC for the first time, you've just added a new sending service, or you've made any DNS change. Stay here for 1–2 weeks and read the reports before moving on. A p=none record with no rua tag is wasted — without reports you learn nothing.

What does p=quarantine do?

p=quarantine tells receivers to treat failing mail as suspicious — in practice, that usually means the spam folder. It's the probation step: you start enforcing DMARC while limiting the damage if you've missed a legitimate sender, because quarantined mail can still be recovered, while rejected mail is gone.

Use p=quarantine when: your p=none reports show that every legitimate sender passes SPF or DKIM with proper alignment, but you're not yet confident enough to reject. The pct tag shown above applies the policy to only a percentage of failing mail — more on that below. Hold quarantine for a week or more and confirm nothing legitimate is landing in spam.

What does p=reject do?

p=reject tells receivers to refuse failing mail outright. It's maximum protection: spoofed emails never reach anyone's inbox, spam folder included. It also protects your domain's reputation, because receivers stop associating your domain with the junk they were quietly delivering.

Use p=reject when: your reports show zero legitimate failures over a full cycle (including month-end and newsletter days, which catch forgotten senders). It is also a prerequisite for BIMI — you cannot get your logo displayed in inboxes without enforcement. For most domains, this is the correct final destination.

How does pct ramping work?

The pct tag applies your policy to only a percentage of failing messages, letting you enforce gradually. A safe schedule looks like this:

1. p=quarantine; pct=10 — only 10% of failing mail is quarantined. Watch for complaints.
2. p=quarantine; pct=50 — after a few clean days, raise the share.
3. p=quarantine; pct=100 — full quarantine for at least a week.
4. p=reject; pct=10, then pct=50, then pct=100 — repeat the ramp at the stricter policy.

Give each step 3–7 days and check your rua reports between changes. pct is a safety valve, not a permanent setting — the goal is always p=reject; pct=100. Note that some receivers apply pct slightly differently, so treat it as approximate, not exact.

Real-world examples

A freelancer cold-emailing via a sending tool. She runs campaigns on a dedicated domain through her cold-email platform, with SPF and DKIM configured there. She publishes p=none with rua, confirms two weeks of reports show only her platform's servers passing, then moves to p=quarantine and ramps to p=reject within the month. Her domain can no longer be spoofed by competitors or scammers — important when your outreach volume makes you a tempting impersonation target.

A small business on Google Workspace. Their mail comes from Gmail, plus invoices from an accounting tool and appointment reminders from a booking app. p=none reports reveal the booking app fails DKIM because it was never configured — they fix it before ever enforcing. Two quiet weeks at p=quarantine, then p=reject. Had they jumped straight to reject, every booking reminder would have bounced.

A SaaS with twelve sending services. Marketing platform, transactional mailer, support desk, two CRMs, and more. They sit at p=none for a full month to build a complete sender inventory, quarantine for two weeks (catching a forgotten legacy CRM on day nine), and only then enforce p=reject. Complex senders move slowly — and that's correct.

What mistakes should I avoid?

• Jumping straight to p=reject on day one. The most common DMARC mistake. One forgotten sending service and its mail starts bouncing.
• Sitting on p=none forever. Monitoring without enforcement is half the job — you get reports but zero protection. None is a starting point, not a strategy.
• Publishing a policy with no rua reporting address. Without reports, moving to quarantine or reject is flying blind.
• Changing policies faster than your report cycle. Aggregate reports arrive roughly daily; give each change several days before judging the result.

Check your own policy

Paste your DMARC record into the free DMARC audit tool to see your current policy, whether reporting is set up, and how far you are from full enforcement.