DMARC p=none vs quarantine vs reject: which policy should you actually run?
p=none only watches and reports, with zero effect on delivery. p=quarantine routes mail that fails DMARC to spam. p=reject has the receiver refuse it outright at SMTP time. The safe path is none first — read your own rua reports for a few weeks — then a gradual quarantine rollout, then reject once quarantine has run clean.
What each policy actually does at the receiving end
| Policy | Receiver action on a DMARC failure | Risk if misconfigured |
|---|---|---|
p=none | None — mail is delivered exactly as it would be without DMARC | None — this is the safe, observation-only starting point |
p=quarantine | Typically routed to spam/junk rather than the inbox | A legitimate but misaligned sender (e.g. an unauthenticated CRM) lands in spam |
p=reject | Refused at SMTP time — the message never reaches the recipient at all | A legitimate but misaligned sender bounces completely, silently, with no inbox trace |
pct= and why it exists
pct= applies your quarantine or reject policy to only a percentage of the mail that would otherwise be affected — pct=25 means roughly a quarter of failing messages get the stricter treatment, while the rest are handled as if the policy were still none. It exists specifically so a rollout can catch a legitimate sending source you missed while reading rua reports, before that mistake affects 100% of your mail instead of a quarter of it. Ramping pct= from 25 to 50 to 100 over successive weeks, watching for complaints or missing mail at each step, is the standard way to de-risk moving off none.
rua/ruf: the reports that tell you whether it’s safe to tighten
rua= is the address a domain’s DMARC record publishes for aggregate reports — daily XML summaries, sent by every major receiver that honors DMARC, listing every source that sent mail claiming your domain and whether SPF and DKIM passed and aligned for it. This is the practical tool for the whole rollout: it is how you find out about a marketing platform, a helpdesk, or a calendar invite sender you forgot was sending as your domain, before tightening the policy blocks it. ruf= would provide forensic, per-message reports, but most large receivers, including Gmail, no longer send forensic reports at all for privacy reasons (DMARC reporting practice, 2026), so rua is the one worth actually configuring.
A safe rollout path
- Publish
p=nonewith a realrua=address, and let reports accumulate for at least 2-4 weeks. - Identify every legitimate sending source in those reports and fix SPF/DKIM alignment for each one — this is almost always where the real work is.
- Move to
p=quarantine; pct=25, and watch for complaints about missing mail from real users, not just the reports. - Step
pct=up gradually — 25, then 50, then 100 — spacing each increase by at least a week. - Move to
p=rejectonly once quarantine has run clean atpct=100for a sustained stretch.
Google and Yahoo’s 2024+ bulk-sender floor
Anyone sending 5,000 or more messages a day to Gmail or Yahoo addresses must have a DMARC record in place for their sending domain, at minimum p=none (Google/Yahoo bulk sender requirements, effective February 2024, still in force September 2026), with SPF and DKIM both configured and at least one of the two in proper DMARC alignment — mail that fails this baseline gets rejected or bulk-foldered outright, independent of content or sender reputation otherwise. p=none is enough to satisfy the letter of that requirement, but it is only the visibility layer: it tells you who is sending as your domain, it does not stop anyone from doing so without your authorization.
Alignment: the part DMARC actually checks
DMARC itself doesn’t authenticate anything new — it checks whether SPF or DKIM, which each verify something different, agree with the domain in the visible From: header. A message can pass SPF and pass DKIM individually and still fail DMARC if neither one is aligned to that From: domain — which is the exact gap that makes domain spoofing possible even when SPF and DKIM are both technically configured. See what each of the three mechanisms checks and how alignment ties them together for the full mechanism.
Check your current DMARC policy
See your live DMARC record, policy, and alignment settings — free, no account required.
Check your DMARC record →Questions
DMARC policy: questions worth answering up front
Can I go straight to p=reject without ever running p=none or p=quarantine?+
You can publish it, but it's a genuinely risky move for any domain that has more than one legitimate sending source. Without first reading rua reports at p=none, you have no visibility into which of your own tools — a CRM, a helpdesk, a calendar invite sender — might fail alignment and get silently blocked the moment reject takes effect.
What's the difference between rua and ruf reports?+
rua (aggregate reports) are daily XML summaries listing every source that sent mail claiming to be your domain and whether SPF/DKIM passed and aligned — these are the ones worth setting up. ruf (forensic reports) would include per-message detail on individual failures, but most large receivers, including Gmail, no longer send them at all for privacy reasons, so treat ruf as effectively unsupported in 2026.
Do I need DMARC if I'm not a high-volume bulk sender?+
It's worth having regardless of volume, since it's what stops someone else from spoofing your domain in a phishing email — a risk that exists whether you send 10 emails a day or 10,000. Google and Yahoo's bulk-sender rules make it mandatory past 5,000 messages/day specifically, but the underlying protection is valuable at any sending volume.
Does p=quarantine mean the email disappears?+
No — quarantine typically means the receiving mail server routes the message to spam/junk rather than the inbox, not that it deletes the message. reject is the policy that has the receiver refuse the message outright at SMTP time, which is the stronger and less forgiving of the two enforcement policies.