DMARC Policies Explained: p=none vs p=quarantine vs p=reject (Safe Rollout Guide)

Publishing a DMARC record with p=none satisfies the minimum baseline of the Gmail and Yahoo bulk sender requirements, which is why thousands of domains stopped there.

The problem is that p=none does not block a single spoofed email. Under p=none, if an attacker sends a phishing email forging ceo@yourdomain.com from an unauthorized server, your DMARC record explicitly instructs Gmail, Microsoft 365, and Yahoo to deliver the message normally and merely log the failure in your daily XML report.

To actually protect your domain from spoofing—and unlock the reputation benefits of full authentication—you must transition from p=none to p=quarantine and ultimately p=reject. Here is how each policy behaves at the mail gateway and the exact 4-stage rollout engineering teams use to reach p=reject without breaking legitimate mail.

You can inspect your domain's current policy and tags in seconds using the Free DMARC Checker.

Side-by-side comparison: p=none vs p=quarantine vs p=reject

The p= tag in your _dmarc.yourdomain.com TXT record defines how receiving mail servers must handle messages that fail both DMARC-aligned SPF and DMARC-aligned DKIM.

Essential companion tags: rua=, pct=, sp=, and adkim=/aspf=

A DMARC policy rarely stands alone. Four other tags in RFC 7489 control how your policy is applied across your domain and subdomains:

1. rua= (Aggregate Reporting URI)

v=DMARC1; p=none; rua=mailto:reports@rua.getmailposture.com;

Without rua=, moving from p=none to p=reject is flying blind. Receiving providers send daily compressed XML reports to the rua= address listing every IP that sent mail as your domain and whether SPF and DKIM aligned. (Read our complete guide to reading DMARC RUA aggregate reports for a breakdown of the XML schema.)

2. pct= (Percentage of Failing Messages Subject to Policy)

The pct= tag (from 1 to 100, defaulting to 100 when omitted) tells receivers what percentage of DMARC-failing messages should have the p= policy applied.

• On p=quarantine; pct=25, 25% of failing messages are sent to spam, while the remaining 75% fall back to the next weaker policy (p=none).
• On p=reject; pct=50, 50% of failing messages are rejected at the SMTP edge, and the remaining 50% fall back to p=quarantine (not none).

3. sp= (Subdomain Policy)

By default, whatever policy you set in p= also applies to every subdomain of your organizational domain (*.yourdomain.com). However, if your root domain is still at p=none while you audit legacy senders, attackers can spoof nonexistent subdomains like billing@secure-login.yourdomain.com.

Setting sp=reject (or sp=quarantine) alongside p=none immediately locks down all unused subdomains while you finish auditing your root domain:

v=DMARC1; p=none; sp=reject; rua=mailto:reports@rua.getmailposture.com;

(Note: If you send legitimate mail from a specific subdomain like marketing.yourdomain.com, publish a dedicated _dmarc.marketing.yourdomain.com record for that subdomain before setting sp=reject at the root.)

4. adkim= and aspf= (Alignment Modes)

These tags specify whether DKIM and SPF domain alignment is relaxed (r, the default) or strict (s):

• Relaxed (r): Subdomains match the organizational domain. For example, an envelope sender of bounce.yourdomain.com or a DKIM d=mail.yourdomain.com aligns with From: user@yourdomain.com.
• Strict (s): The exact FQDN must match (d=yourdomain.com for From: user@yourdomain.com). Keep adkim=r and aspf=r unless you have a specific regulatory requirement for strict matching.

The 4-stage DMARC rollout playbook (Zero-downtime path to p=reject)

Never jump a live production domain directly from "no DMARC record" to p=reject. Follow this four-stage engineering sequence instead.

Stage 1: Visibility Mode (p=none with RUA collection)

Publish a monitoring-only record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:reports@rua.getmailposture.com; fo=1;

Leave this record in place for 7 to 14 days so weekly billing jobs, monthly invoicing scripts, CRM automations, and support desks all generate traffic in your aggregate reports.

Stage 2: Remediate unaligned legitimate senders

Review your DMARC aggregate data and list every legitimate service sending as @yourdomain.com. For each sender:

1. Enable custom DKIM signing first: Configure a 2048-bit DKIM key in the sender's console (selector._domainkey.yourdomain.com) and verify it with the Free DKIM Checker. DKIM survives email forwarding and is the most reliable way to pass DMARC.
2. Configure aligned SPF where supported: Set up a custom Return-Path (bounce) subdomain and verify your root SPF record stays well under the 10-DNS-lookup limit.

Wait 48 hours after DNS changes and confirm in your RUA reports that 100% of legitimate volume passes DMARC alignment.

Stage 3: Staged Quarantine (p=quarantine; pct=25 -> pct=100)

Once all known legitimate senders pass DMARC, move to p=quarantine:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@rua.getmailposture.com;

If no legitimate mail is flagged in your RUA reports after 3–5 days, increase pct=25 to pct=100:

v=DMARC1; p=quarantine; pct=100; rua=mailto:reports@rua.getmailposture.com;

Why stage through quarantine before reject? Because if an undocumented department tool sends a quarterly email without DKIM, quarantine routes it to the recipient's spam folder where it can still be found, whereas reject drops it permanently.

Stage 4: Full Enforcement (p=reject; pct=100)

After 1–2 weeks of clean reports at p=quarantine; pct=100, promote your policy to p=reject:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:reports@rua.getmailposture.com;

Your domain is now protected against exact-domain spoofing, and your rua= address continues collecting reports so you can spot new shadow-IT senders or spoofing campaigns immediately.

Common pitfalls that break mail during DMARC enforcement

• Authenticating SPF without alignment: Adding include:sendgrid.net to your SPF record does not make SendGrid pass DMARC SPF alignment if SendGrid still uses em123.sendgrid.net as the Return-Path domain. You must either configure DKIM (d=yourdomain.com) or set up a custom branded Return-Path subdomain. See our SPF, DKIM, and DMARC alignment troubleshooting guide.
• Multiple _dmarc TXT records: Just like SPF, a domain may only publish one TXT record starting with v=DMARC1 at _dmarc.yourdomain.com. Publishing two _dmarc records causes receivers to ignore DMARC entirely.
• Forgetting to monitor after reaching p=reject: Reaching p=reject is not the end of the lifecycle. If a developer rotates a DKIM key or a marketing manager adds two new SPF includes that push your record over 10 lookups, p=reject will immediately block your own mail.

Test your DMARC policy now

Use our Free DMARC Checker to validate your _dmarc syntax, p= policy, pct= coverage, and rua= reporting tag—or run a complete domain security scan to get copy-paste DNS records and 24/7 monitoring alerts.