DMARC p=none vs quarantine vs reject: Which Policy Should You Use?

DMARC’s policy tag p= tells receivers what to do with mail that fails authentication: p=none takes no action (monitor only), p=quarantine sends failing mail to spam, and p=reject blocks it outright. Only quarantine and reject actually stop spoofing — none is a safe starting point for collecting data, not a place to stop.

What each policy does

DMARC (defined in RFC 7489) ties SPF and DKIM results to the visible From: domain via alignment, then applies your policy when neither passes and aligns:

• p=none — “do nothing special.” Failing mail is still delivered; you just receive aggregate reports (via the rua= tag) showing who’s sending as you. Zero enforcement — anyone can still spoof your From address.
• p=quarantine — failing mail is treated as suspicious and typically routed to the spam/junk folder.
• p=reject — failing mail is rejected at the SMTP level and never delivered. This is the goal: it’s what actually prevents your domain from being spoofed in phishing.

Why p=none is not a destination

p=none satisfies the letter of Gmail’s and Yahoo’s bulk-sender rules, which require a DMARC record set to at least p=none (Google, Yahoo). But it provides no protection. Both providers publish DMARC at enforcement themselves and expect senders to progress toward quarantine or reject. Leaving it at none forever means you get the reports but none of the defence.

Move from none to reject — safely

1. Start at p=none with reporting. Publish v=DMARC1; p=none; rua=mailto:you@yourdomain. Collect a few weeks of aggregate reports.
2. Fix your legitimate senders. Use the reports to find every service sending as you and make sure each passes SPF or DKIM with alignment. This is the real work — don’t tighten until it’s done.
3. Move to p=quarantine, optionally with pct= to ramp (e.g. pct=25 applies the policy to a quarter of failing mail). Watch for legitimate mail getting caught.
4. Move to p=reject once reports are clean. Now spoofed mail is blocked.

Rushing to p=reject before step 2 is the classic mistake — it can send your own invoices and password resets to the void.

Check where you stand

Our free DMARC checker shows whether a record exists and reports its policy strength (monitoring vs enforcing) in one look. Then verify the SPF and DKIM it depends on with the SPF and DKIM checkers, or the full report.

Sources

• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489
• Google — Email sender guidelines (DMARC at least p=none): https://support.google.com/a/answer/81126
• Yahoo — Sender Best Practices: https://senders.yahooinc.com/best-practices/