/Guides/Moving to p=reject Safely
DMARC Implementation

Moving to p=reject Safely

p=reject is the gold standard for DMARC protection, but jumping directly to it can break legitimate email delivery. This guide shows you how to progressively roll out enforcement safely.

12 min read
Updated January 2025

Why p=reject Matters

DMARC has three policy levels with increasing protection:

p=none

Monitor Only (No Protection)

Receiving servers do nothing with DMARC failures. Attackers can still spoof your domain. Only use for initial setup and monitoring.

p=quar

Quarantine (Partial Protection)

Failed emails go to spam/junk folder. Better than nothing, but sophisticated users check spam folders. Not full protection.

p=reject

Reject (Maximum Protection) ✓ RECOMMENDED

Failed emails are completely blocked before reaching the inbox. This is the only policy that truly prevents domain spoofing.

Industry Standard
Google, Microsoft, and major financial institutions all use p=reject. It's required for BIMI (brand indicators) and recommended by all security frameworks.

The Risk: Moving Too Fast

Jumping directly to p=reject without proper validation can cause:

Legitimate Emails Blocked

Third-party services not properly configured (Salesforce, Zendesk, SendGrid) will fail authentication and be rejected.

Email Forwarding Breaks

Forwarded emails often fail SPF alignment. If you have users forwarding to Gmail/Outlook, those emails will be rejected.

Mailing List Issues

Some mailing lists modify email content (adding footers, subject prefixes), breaking DKIM signatures.

Hidden Email Sources

Marketing automation, CRM systems, monitoring alerts - you might discover email sources you didn't know existed.

Progressive Rollout Strategy

The safest path to p=reject uses a 4-phase approach with validation at each step:

1

Phase 1: Monitor (p=none)

Duration: 2-4 weeks

v=DMARC1; p=none;

rua=mailto:dmarc@yourdomain.com;

pct=100

Goal: Collect baseline data on all email sources. Identify legitimate senders and fix SPF/DKIM for services failing authentication.

Review DMARC reports daily for first week

Document all email sources (Google, SendGrid, Salesforce, etc.)

Fix failing senders by configuring SPF and DKIM

Target: 95%+ DMARC compliance before moving to Phase 2

2

Phase 2: Gradual Quarantine (pct=25, then 50, then 100)

Duration: 3-6 weeks total

Week 1-2: Apply to 25% of email

v=DMARC1; p=quarantine;

pct=25;

rua=mailto:dmarc@yourdomain.com

Week 3-4: Increase to 50%

v=DMARC1; p=quarantine;

pct=50;

rua=mailto:dmarc@yourdomain.com

Week 5-6: Full enforcement (100%)

v=DMARC1; p=quarantine;

pct=100;

rua=mailto:dmarc@yourdomain.com

Goal: Test enforcement gradually. The pct= tag tells receiving servers to only apply the policy to X% of failing emails. This limits blast radius.

Monitor user complaints about missing emails

Check spam folders for legitimate emails quarantined

Fix any newly discovered failing senders

3

Phase 3: Gradual Reject (pct=25, then 50, then 100)

Duration: 3-6 weeks total

Week 1-2: Apply to 25% of email

v=DMARC1; p=reject;

pct=25;

rua=mailto:dmarc@yourdomain.com

Week 3-4: Increase to 50%

v=DMARC1; p=reject;

pct=50;

rua=mailto:dmarc@yourdomain.com

Week 5-6: Full enforcement (100%)

v=DMARC1; p=reject;

pct=100;

rua=mailto:dmarc@yourdomain.com

Critical Phase
p=reject blocks emails completely. Monitor VERY closely during this phase. Have rollback plan ready.
4

Phase 4: Full Enforcement (p=reject, pct=100)

Ongoing

v=DMARC1; p=reject; pct=100;

rua=mailto:dmarc@yourdomain.com;

ruf=mailto:forensic@yourdomain.com

Congratulations! Your domain is now fully protected against spoofing. Continue monitoring reports to catch any new email sources.

Monitor weekly DMARC reports for new failures

Set up alerts for authentication failures

Document your email sources for future reference

Typical Timeline: 8-16 Weeks

Weeks 1-4

p=none - Monitor and fix authentication

Weeks 5-10

p=quarantine with pct=25, 50, 100 progression

Weeks 11-16

p=reject with pct=25, 50, 100 progression

Faster for Simple Setups
If you only use Google Workspace or Microsoft 365 with no third-party email services, you can move faster (4-6 weeks total). Complex environments with many ESPs take longer.

Key Metrics to Monitor

DMARC Compliance Rate

Percentage of email passing DMARC (SPF or DKIM aligned)

Target: 95%+ before moving to next phase

If compliance drops below 95%, pause rollout and investigate failures

Volume of Failing Messages

Number of emails failing DMARC per day

Target: Less than 5% of total volume

High failure volume = major email sources not configured correctly

User Complaints About Missing Email

Support tickets reporting undelivered emails

Target: Zero complaints related to DMARC

Any complaints = rollback immediately and investigate

Forensic Report Volume

Real-time failure notifications (ruf= tag)

Target: Only spoofing attempts, not legitimate senders

Legitimate senders in forensic reports = configuration issue

Emergency Rollback Plan

If you discover legitimate emails being blocked:

  1. Immediately change DMARC policy back to previous phase (e.g., p=reject pct=50 → p=quarantine pct=100)
  2. DNS changes propagate in 5-60 minutes depending on TTL
  3. Identify failing sender from DMARC reports or user complaints
  4. Fix SPF/DKIM configuration for that sender
  5. Wait 1 week monitoring with fixed config before re-attempting rollout

Common Pitfalls to Avoid

Skipping the p=quarantine Phase

Going directly from p=none to p=reject is risky. Always use p=quarantine as intermediate step.

Not Testing Subdomain Policies

Don't forget sp= tag for subdomains. Test marketing.domain.com, app.domain.com separately.

Rushing Through pct= Progression

Give each pct= step at least 1-2 weeks. Don't jump from pct=25 to pct=100 immediately.

Ignoring DMARC Reports

Review reports DAILY during rollout. Weekly after reaching p=reject. Set up automated alerts.

Not Communicating with Stakeholders

Inform marketing, sales, and support teams about the rollout. They should watch for delivery issues.

Automated Progressive Rollout

TrustYourInbox automates your p=reject rollout with built-in safety checks and monitoring. No manual policy changes needed.