Safely Moving to DMARC Reject

Moving your DMARC policy to reject is the single most impactful thing you can do for your email security. A reject policy tells email providers to block any email that fails authentication, effectively preventing anyone from impersonating your domain.

But moving too fast can break legitimate email delivery. Marketing platforms, CRM systems, ticketing tools, and other third-party services that send email on your behalf might fail DMARC checks if they're not properly configured. A premature move to reject means those emails never arrive.

Here's how to do it safely.

Phase 1: Monitor with p=none

If you don't have a DMARC record yet, start with p=none. This tells email providers to deliver all mail normally but send you reports about authentication results.

The critical part is the rua tag. This is where aggregate reports are sent. These reports tell you every server that's sending email as your domain and whether they pass SPF and DKIM.

Run p=none for at least 2-4 weeks. During this time, identify all legitimate senders and make sure they pass authentication. Common senders you might discover:

• Your primary email provider (Google Workspace, Microsoft 365)
• Marketing platforms (Mailchimp, HubSpot, SendGrid)
• Transactional email services (Postmark, SES, Resend)
• CRM and support tools (Salesforce, Zendesk, Freshdesk)
• Internal tools and applications that send notifications

Phase 2: Fix alignment issues

DMARC requires "alignment": the domain in the From header must match the domain authenticated by SPF or DKIM. Many third-party services break alignment by default because they use their own domain for SPF and a generic DKIM selector.

For each sender that fails alignment:

• Configure custom DKIM signing: most email services let you set up DKIM with your own domain. This usually involves adding CNAME records to your DNS.
• Set up custom return-path: some services let you configure a custom bounce address on your domain, which fixes SPF alignment.
• Verify with reports: after making changes, check your next DMARC report to confirm the sender now passes.

Phase 3: Move to p=quarantine

Once your reports show that all legitimate senders pass DMARC, move to quarantine. This sends failing emails to spam rather than blocking them entirely, a safer intermediate step.

Notice the pct=25 tag. This applies the quarantine policy to only 25% of failing messages. This lets you catch problems early without affecting all your email at once.

Monitor for 1-2 weeks. If no legitimate email is being quarantined, increase pct to 50, then 100. If you spot a sender that should be passing, fix their alignment before continuing.

Phase 4: Move to p=reject

When you've been running p=quarantine; pct=100 without issues for at least 2 weeks, you're ready for reject.

At this point, any email that fails DMARC authentication will be blocked by receiving servers. This is the strongest protection against domain impersonation.

Continue monitoring your reports after moving to reject. New services, changes to existing senders, or configuration drift can cause legitimate email to start failing. Continuous monitoring is the only way to catch these issues quickly.

How MailShield helps

MailShield automates the hardest part of this process: reading and understanding DMARC reports. We process your reports automatically, show you exactly who's sending email as your domain, flag senders that fail authentication, and tell you when it's safe to upgrade your policy.

We also monitor your DMARC record continuously and alert you if anything changes. No surprises, no silent failures, just clear visibility every step of the way.