Table of Contents
- Introduction
- How To Move your DMARC Policy to p=reject
- Step 1: Publish p=none and Collect Reports (Week 1)
- Step 2: Fix Every Authentication Failure (Week 2-3)
- Step 3: Move to p=quarantine with Percentage Rollout (Week 3-4)
- Step 4: Monitor at Full Quarantine (Week 4-5)
- Step 5: Move to p=reject (Week 5-6)
- What to Do When Something Breaks
- Other Things You Need to Know About Moving to DMARC Reject
Last Updated
Do not index
IntroductionHow To Move your DMARC Policy to p=rejectStep 1: Publish p=none and Collect Reports (Week 1)Step 2: Fix Every Authentication Failure (Week 2-3)Step 3: Move to p=quarantine with Percentage Rollout (Week 3-4)Step 4: Monitor at Full Quarantine (Week 4-5)Step 5: Move to p=reject (Week 5-6)What to Do When Something BreaksOther Things You Need to Know About Moving to DMARC Reject
Introduction
Moving your DMARC policy to p=reject tells receiving servers to block any email that fails authentication. It's the strongest protection against domain spoofing, but it also blocks your own legitimate emails if they aren't properly authenticated. The safe path from p=none to p=reject takes four to six weeks and requires auditing every service that sends email on your domain, fixing all SPF and DKIM failures, and progressively tightening the policy through p=quarantine before reaching full enforcement.
The Verizon Data Breach Investigations Report consistently identifies phishing as one of the leading causes of data breaches, and most phishing attacks start with a spoofed email. Yet according to Sendmarc's analysis, only 19.6% of domains with published DMARC records are at p=reject. The remaining 80% are either monitoring (p=none) or partially enforcing (p=quarantine), leaving their domains partially or fully exposed to impersonation.
The reason most organizations stay at p=none isn't that reject is complicated to configure. It's a single DNS change. The risk is what happens to legitimate email that hasn't been properly authenticated. Moving to reject without preparation means marketing campaigns from HubSpot, transactional emails from SendGrid, calendar invitations from Google Workspace, and support responses from Zendesk might all get blocked if their SPF and DKIM aren't correctly configured for your domain.
How To Move your DMARC Policy to p=reject
.png?table=block&id=34216483-6d68-8033-addf-d1ddbf5e0997&cache=v2)
Step 1: Publish p=none and Collect Reports (Week 1)
If you don't have a DMARC record, start here. Publish: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
This generates aggregate reports showing every IP address and service sending email using your domain. The reports arrive daily as XML files. Use a DMARC report parser (Postmark's free tool, MXToolbox, dmarcian, or EasyDMARC) to make them readable.
What you're looking for: every legitimate sending source and whether it's passing or failing SPF and DKIM. You'll typically find Google Workspace, your ESP, your CRM, marketing tools, and sometimes services nobody on the team remembers configuring.
Step 2: Fix Every Authentication Failure (Week 2-3)
Go through each sending source identified in the reports. For every one that's failing SPF, add its IP or include statement to your SPF record. For every one failing DKIM, configure DKIM signing through that platform's settings and publish the corresponding public key in your DNS.
Common surprises at this stage: an old Mailchimp integration that's still active, a Calendly account sending meeting invitations on your domain, a third-party invoicing tool that sends receipts from your domain without authentication, or a developer staging environment that sends test emails through a different SMTP server.
Mailwarm's infrastructure health check audits SPF, DKIM, and DMARC across your domain and identifies exactly which services need attention. MXToolbox validates individual DNS records.
Step 3: Move to p=quarantine with Percentage Rollout (Week 3-4)
Don't jump to reject. Move to quarantine first with a low percentage:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com
This applies the quarantine policy to only 10% of emails that fail authentication. The other 90% still get delivered normally. Monitor the reports and watch for legitimate email landing in spam.
Increase gradually: pct=25 after a few days, then pct=50, then pct=100. At each stage, check whether any legitimate email is being affected. If you find a service that's still failing, fix it before increasing the percentage.
Step 4: Monitor at Full Quarantine (Week 4-5)
Once you're at pct=100 on quarantine, run it for at least one full week. Check your aggregate reports daily. Look for any failures on legitimate sending sources. Confirm that open rates, reply rates, and deliverability metrics haven't degraded.
This is also where you verify that edge cases are covered. Forwarded emails, mailing list messages, and auto-replies can sometimes fail DMARC. ARC (Authenticated Received Chain) helps with forwarding scenarios, but not all providers support it.
Step 5: Move to p=reject (Week 5-6)
When you're confident that all legitimate email is passing authentication at pct=100 quarantine with no issues:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
From this point, any email that fails DMARC from your domain gets blocked. Spoofed emails are rejected. Impersonation attempts fail. Your domain is protected.
Continue monitoring aggregate reports after enforcement. New services get added, configurations change, team members sign up for tools that send email on your domain. DMARC isn't set and forget; it needs ongoing attention.
What to Do When Something Breaks
If you move to reject and discover that legitimate emails are being blocked, don't panic. You can roll back to quarantine or even none temporarily while you fix the issue. DMARC policy changes take effect as soon as DNS propagates, usually within an hour.
The most common post-enforcement issue is a new service that a team member started using without informing IT. They sign up for a project management tool or a newsletter platform, connect the company domain, and start sending without SPF or DKIM. Those emails get rejected. The fix is adding the new service to your authentication records, not rolling back the policy permanently.
Other Things You Need to Know About Moving to DMARC Reject
How long should I stay at p=none before moving to enforcement?
Two weeks minimum. Four weeks is better. You need enough data to identify every sending source on your domain, including monthly or quarterly campaigns that might not run during a shorter observation window.
Can I skip quarantine and go straight to reject?
Technically yes. Practically, it's risky. Quarantine gives you a safety net where misconfigured legitimate email lands in spam rather than being blocked. You can identify and fix issues without disrupting delivery entirely.
What happens to forwarded emails under p=reject?
Email forwarding can break DMARC because the forwarding server's IP isn't in your SPF record, and the forwarded message may have been modified (breaking DKIM). ARC (Authenticated Received Chain) was designed to solve this. Gmail and Microsoft support ARC; not all providers do.
Does p=reject affect email I receive?
No. Your DMARC policy only affects email sent from your domain. It has no impact on email you receive.