Every DMARC deployment starts with the same question: which policy do I set, and when do I move to the next level? The answer matters — move too fast and you block legitimate email. Stay at p=none forever and you provide no protection against spoofing.
What each DMARC policy does
p=none — monitoring mode
rua= address but deliver all messages normally, regardless of whether they pass or fail DMARC.With p=none, your DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
What happens to failing messages: nothing. They are delivered normally. Spoofed email reaches inboxes. Your only gain from p=none is the aggregate reports — which tell you what is happening so you can fix it.
Purpose: Discovery. Use p=none to identify every source that sends mail claiming to be from your domain and determine which ones are legitimate.
p=quarantine — partial enforcement
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
The pct=10 means only 10% of failing messages are quarantined — the other 90% are still delivered normally. This is the recommended starting point for enforcement. It reduces spoofing impact while preserving a safety margin if you have misconfigured legitimate senders you have not found yet.
Purpose: Partial protection with a recovery path. Reduces spoofing visibility without risking total loss of legitimate mail.
p=reject — full enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
p=reject is the goal for most domains. It completely blocks spoofed email that fails DMARC. But it also blocks any legitimate email that fails DMARC — so readiness is critical.
Purpose: Complete protection against domain spoofing and phishing using your domain.
The policy decision framework
Use this table to decide which policy level is appropriate for your current situation:
| Situation | Recommended policy | Why |
|---|---|---|
| Just published DMARC record — no reports yet | p=none | Need data to identify all sending sources before enforcing |
| Collecting reports, pass rate below 90% | p=none | Too many legitimate failures to enforce — fix auth first |
| Pass rate 90–95% for 2+ weeks | p=quarantine; pct=10 | Ready to start enforcement with a safety buffer |
| Pass rate 95%+, pct=10 stable for 2 weeks | p=quarantine; pct=50 | Ramp up enforcement gradually |
| Pass rate 95%+, pct=100 quarantine stable for 2 weeks | p=reject; pct=10 | Begin reject rollout cautiously |
| p=reject pct=100, pass rate 98%+ for 2+ weeks | p=reject; pct=100 | Full enforcement — your domain is protected |
Readiness criteria before advancing policy
Before moving from p=none to p=quarantine
- You have been collecting rua reports for at least 2 weeks
- You have identified all IP addresses appearing in your reports
- All legitimate senders (your own mail server, ESPs, transactional email services) are configured with DKIM alignment or SPF alignment
- Your DMARC pass rate is above 95% across Google and Microsoft reports
- Failing records either have low counts (forwarding noise) or belong to unknown IPs (likely spoofing)
Before moving from p=quarantine to p=reject
- You have been at
p=quarantine; pct=100for at least 2 weeks - No legitimate mail has ended up in spam during this period
- Pass rate is above 98% consistently
- Any remaining failures are confirmed as forwarding artifacts or known spoofing sources — not legitimate senders
- You have informed all teams (marketing, IT, transactional systems) and all senders are correctly configured
Using pct for gradual rollout
The pct= tag is your safety valve. It controls what percentage of failing messages the policy is applied to. The remaining percentage is treated as if p=none.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
This quarantines 25% of failing messages and delivers the other 75% normally. The selection is random — so even a small pct value gives you meaningful signal without risking all your mail.
Recommended rollout timeline:
| Week | Policy | pct | Action if problems appear |
|---|---|---|---|
| 1–4 | none | 100 | Fix all authentication failures in reports |
| 5–6 | quarantine | 10 | Roll back to p=none if legitimate mail is affected |
| 7–8 | quarantine | 50 | Check spam folders, interview teams for missed mail |
| 9–10 | quarantine | 100 | Monitor for 2 full weeks before advancing |
| 11–12 | reject | 10 | Watch for bounce reports from senders |
| 13–16 | reject | 100 | Full enforcement — domain protected |
How to roll back safely
If you advance policy and notice legitimate mail is being blocked or quarantined, roll back immediately:
- Change your DMARC record back to the previous policy level (or to
p=none). DNS changes propagate within minutes to hours. - Analyze your DMARC reports to identify which sender was affected. Look at the source IP of bounced mail and cross-reference with your report records.
- Fix the authentication issue (usually DKIM alignment) for that sender, confirm in reports that they are now passing, then re-advance.
The subdomain policy (sp=)
The sp= tag lets you set a different policy for subdomains. This is useful when your organizational domain uses p=reject but you have subdomains that send marketing or transactional mail not yet fully authenticated:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com
This rejects failing mail from example.com but only quarantines failing mail from sub.example.com — giving subdomain senders more time to configure authentication while the main domain is fully enforced.
If sp= is omitted, subdomains inherit the p= policy.
What happens to failing mail at each policy level
| Policy | What Gmail does | What Outlook does | Recipient sees |
|---|---|---|---|
| p=none | Delivers normally | Delivers normally | Message in inbox |
| p=quarantine | Sends to spam folder | Sends to junk folder | Message in spam/junk |
| p=reject | Rejects at SMTP (bounce to sender) | Rejects at SMTP (bounce to sender) | Message never arrives |
Note: providers may deviate from this in specific circumstances — for example, applying a local policy override that delivers even rejected mail to junk. These deviations appear as unexpected disposition values in your DMARC reports.
Google and Yahoo email sender requirements
Since February 2024, Google and Yahoo require bulk email senders (those sending more than 5,000 messages per day to Gmail or Yahoo) to have a DMARC record with at least p=none. This is a minimum compliance threshold — not a recommendation. For meaningful protection against spoofing, you need p=quarantine or p=reject.
Many ESPs now require or recommend p=reject for custom sending domains as a condition of their services, particularly for high-reputation domains.
Frequently asked questions
What is DMARC p=none?
p=none is the monitoring policy — receiving servers report results but deliver all mail normally, even if it fails DMARC. It is the required starting point for every DMARC deployment.
When should I move to p=reject?
When your DMARC pass rate is above 98% consistently across Google and Microsoft reports, all legitimate senders are correctly authenticated, and you have been stable at p=quarantine; pct=100 for at least 2 weeks without any legitimate mail going to spam.
What does pct do in DMARC?
pct= controls the percentage of non-passing messages to which the policy is applied. pct=10 means 10% of failing messages are quarantined or rejected; 90% are treated as p=none. It is a safety mechanism for gradual enforcement rollout.
Can I skip p=quarantine and go straight to p=reject?
Technically yes, but it is not recommended. Going straight to p=rejectwithout first verifying at quarantine level risks blocking legitimate mail with no warning. The quarantine phase lets you catch any remaining legitimate failures before they become hard rejections.
Does p=reject affect email forwarding?
Yes. Forwarded email often fails DMARC (because forwarding breaks SPF and sometimes DKIM). With p=reject, forwarded mail from your domain may be rejected by the final destination server. This is a known limitation. Providers that support ARC (Google, Microsoft) can work around this for trusted forwarders, but small or legacy forwarders may still reject the mail.
The path from p=none to p=reject typically takes 8–16 weeks for most organizations. The key is using your DMARC aggregate reports at each step to verify readiness. Upload your reports to DMARC Labs to check your pass rate and identify any senders that need to be fixed before you advance to the next policy level.