What you'll learn
- • The three DMARC policy levels and what they mean
- • How to safely progress from p=none to p=reject
- • Timeline and milestones for each phase
- • How to analyze DMARC reports during progression
- • Rollback strategies if issues arise
Why Policy Progression Matters
Jumping straight to p=reject without proper monitoring can result in legitimate emails being rejected, potentially disrupting your business communications. A gradual progression allows you to:
- Identify all legitimate email sources before enforcement
- Fix authentication issues without impacting deliverability
- Build confidence in your DMARC configuration
- Minimize risk of blocking important emails
- Document your email infrastructure thoroughly
Understanding DMARC Policy Levels
p=none (Monitor)
Monitoring only - No action taken
Emails that fail DMARC are delivered normally. You receive aggregate reports showing which emails passed or failed authentication. Perfect for initial setup and discovery.
p=quarantine (Soft Enforcement)
Failed emails go to spam
Emails that fail DMARC are marked as spam/junk but still deliverable. Recipients can find them in spam folders. Good intermediate step before full enforcement.
p=reject (Full Enforcement)
Failed emails are blocked
Emails that fail DMARC are completely rejected and never reach the recipient. Maximum protection against email spoofing and phishing. Your end goal.
The Recommended Progression Timeline
Phase 1: p=none
Week 1-4Goal: Discover all email sources and establish baseline
DMARC Record:
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; adkim=r; aspf=rKey Activities:
- Set up DMARC record with p=none
- Configure email to receive aggregate reports (RUA)
- Collect data for 2-4 weeks
- Identify all legitimate sending sources
- Fix SPF and DKIM for failing sources
Phase 2: p=quarantine
Week 5-8Goal: Test enforcement with recoverable failures
DMARC Record:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25; adkim=r; aspf=rKey Activities:
- Start with pct=25 (25% of emails)
- Monitor reports for any legitimate failures
- Gradually increase pct to 50, 75, then 100
- Watch for complaints about missing emails
- Tighten alignment (adkim=s, aspf=s) if ready
Phase 3: p=reject
Week 9+Goal: Full protection against email spoofing
DMARC Record:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=25; adkim=s; aspf=sKey Activities:
- Start with pct=25 for initial testing
- Monitor closely for any delivery issues
- Gradually increase pct to 100 over 2-3 weeks
- Use strict alignment (adkim=s, aspf=s)
- Continue monitoring reports indefinitely
Using the pct Tag for Gradual Rollout
The pct tag allows you to apply your DMARC policy to only a percentage of failing emails, providing an additional safety net during transitions:
| pct Value | Percentage | Recommended Duration |
|---|---|---|
pct=25 | 25% of failing emails | 1 week |
pct=50 | 50% of failing emails | 1 week |
pct=75 | 75% of failing emails | 1 week |
pct=100 | 100% of failing emails (default) | Permanent |
Pro Tip: Double Rollout
Use pct when changing policies (p=none → p=quarantine → p=reject). For example: change to p=quarantine; pct=25, gradually increase pct to 100, then change to p=reject; pct=25 and repeat. This provides two layers of gradual rollout for maximum safety.
Analyzing DMARC Reports
During each phase, carefully analyze your DMARC aggregate reports (RUA) to identify issues:
What to Look For
- Volume of failures - High failure rates indicate configuration issues
- Failing sources - Identify which IPs/domains are failing authentication
- SPF vs DKIM failures - Determine which protocol needs fixing
- Alignment issues - Check if From domain matches SPF/DKIM domains
- Unknown sources - Investigate unfamiliar IPs sending from your domain
Common Failing Sources to Fix
Marketing Platforms
Mailchimp, SendGrid, Constant Contact - Add their SPF includes and DKIM records
CRM Systems
Salesforce, HubSpot, Zoho - Configure DKIM and update SPF
Help Desk Software
Zendesk, Freshdesk, Intercom - Set up proper authentication
Forwarding Services
Email forwarding breaks SPF - Consider using SRS or exempting with pct
Decision Points: When to Progress
✅ Ready to Move from p=none to p=quarantine
- 100% of legitimate email passes DMARC (or close to it)
- You've identified and fixed all authentication issues
- All known sending services have SPF/DKIM configured
- You've been monitoring for at least 2-4 weeks
- DMARC reports show consistent passing rates
✅ Ready to Move from p=quarantine to p=reject
- No complaints about legitimate emails in spam
- DMARC pass rates remain consistently high (95%+)
- You've tested at pct=100 for at least 2 weeks
- All stakeholders are informed about the change
- You have a rollback plan ready
🚫 Not Ready to Progress If...
- More than 5% of legitimate email is failing
- You're still discovering new sending sources
- Recent reports show authentication failures
- Critical business emails are failing DMARC
- You haven't documented your email infrastructure
Rollback Strategy
If you encounter issues after progressing your policy, you can safely roll back:
Emergency Rollback (Immediate)
If legitimate emails are being blocked:
- Change DMARC record to
p=none - Wait 5-10 minutes for DNS propagation
- Verify change with DNS lookup
- Investigate and fix the root cause
- Resume progression when ready
Gradual Rollback (Preferred)
If you notice issues but they're not urgent:
- Reduce
pctvalue (100 → 75 → 50 → 25) - If issues persist, downgrade policy (reject → quarantine or quarantine → none)
- Keep
pctat a safe level while investigating - Fix authentication issues for failing sources
- Resume progression cautiously
Advanced: Subdomain Policies
Use the sp tag to set different policies for subdomains:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]This configuration applies p=reject to the main domain but sp=quarantine to all subdomains, allowing you to enforce stricter policies on your primary domain while being more lenient with subdomains.
Best Practices
1. Never Skip p=none
Always start with p=none to discover your email ecosystem. Skipping this phase significantly increases the risk of blocking legitimate email.
2. Take Your Time
There's no rush to reach p=reject. It's better to spend extra time monitoring than to block important emails. Some organizations take 3-6 months to reach full enforcement.
3. Communicate Changes
Inform your IT team, marketing, sales, and other stakeholders before changing policies. Have them watch for delivery issues and report them immediately.
4. Document Everything
Maintain a list of all services sending email on your behalf, their SPF/DKIM configuration, and when they were added. This makes troubleshooting much easier.
5. Continue Monitoring After p=reject
Don't stop reviewing DMARC reports after reaching p=reject. New email services may be added over time, and you need to ensure they're properly configured.
Troubleshooting Common Issues
Legitimate Email Going to Spam (p=quarantine)
- Check DMARC reports to identify which source is failing
- Verify SPF includes and DKIM records for that source
- Temporarily reduce
pctto minimize impact - Fix authentication and test before increasing pct again
Legitimate Email Being Blocked (p=reject)
- Immediately roll back to
p=quarantineor reduce pct - Identify the failing source from DMARC reports
- Set up proper SPF and DKIM for that source
- Test thoroughly before progressing to p=reject again
Forwarded Email Failing
- Email forwarding inherently breaks SPF alignment
- Consider using SRS (Sender Rewriting Scheme) on forwarding servers
- Rely on DKIM for forwarded email (DKIM survives forwarding)
- Use
aspf=r(relaxed SPF) instead ofaspf=s
You're Ready!
Follow this guide carefully, and you'll reach p=reject safely. Remember: slow and steady wins the race. Email deliverability is too important to rush.