When Is Your Domain Ready for DMARC p=reject?

Most domains that run DMARC at p=none intend to move to p=reject eventually. The problem is that "eventually" tends to become "never" because there is no clear moment that says "you are ready." Organizations either stay unprotected indefinitely or flip to reject too early and spend the next three days unbreaking legitimate mail.

This is not a gap in motivation. It is a gap in process. There is a specific set of signals in your DMARC aggregate reports that tells you when the switch is safe. Here is how to read them.

What p=reject actually does

p=reject tells receiving mail servers to silently discard any message that fails DMARC authentication. It does not bounce the message back to the sender. It does not put it in quarantine. It disappears.

The distinction matters because quarantine gives you a safety net: a message that might be legitimate lands in the spam folder and the recipient can still find it. Reject gives you nothing. If your authenticated mail is misconfigured, those messages vanish from the recipient's inbox with no notification to you and no recovery path.

This is why RFC 9989, which updated the DMARC protocol in 2026, describes p=reject as the appropriate policy for domains where all legitimate senders are fully accounted for. For domains where some senders are unknown or misconfigured, it is a blunt instrument that hurts legitimate mail before it helps anything.

The DMARC readiness checklist

Before you touch your DMARC policy, your aggregate reports should show all five of the following:

All legitimate sending sources produce aligned SPF or DKIM results

No unknown or unexpected sending domains appear in your aggregate reports

All third-party senders (marketing platforms, SaaS tools, CRM systems) are accounted for and passing

SPF alignment is passing for every message that uses your From domain

You have collected and reviewed aggregate reports for at least 30 days at p=none

If any of those five are not true, you are not ready for p=reject. That is not a judgment. It is what the data says.

How to read your DMARC aggregate reports for readiness

Your aggregate reports arrive daily and contain a summary of all messages receivers saw from your domain. Here is what to look at.

Disposition pass rate. Count the percentage of messages where disposition=pass. Target: 95% or higher. If you see sudden spikes of failures where there were none before, something changed. Find out what before you change your policy.

Unknown sending sources. Look for any sending domain or IP you do not recognize. If a vendor is sending on your behalf and their SPF or DKIM is not configured correctly, their mail will show as a failure. If you do not know who they are, you cannot fix it.

Aligned authentication results. DMARC requires at least one of SPF or DKIM to align with your From domain. "Aligned" means the domain in the SPF result or DKIM signature matches the domain a recipient sees in the From header. A passing SPF result from a vendor's server is useless for DMARC if the vendor's domain appears in the SPF check, not yours.

This is where monitoring tools matter. DMARCFlow parses these reports and shows the aligned pass rate broken down by domain and sender, which makes it faster to identify the specific senders that are pulling your numbers down. For teams doing this without a dedicated tool, reading raw XML aggregate reports tends to surface only the loudest failures, and the quiet misalignments quietly break mail for weeks.

What to do when you find senders that fail

Finding failures is the point of running at p=none. What you do next depends on who is failing and why.

Contact the vendor. If a SaaS tool is sending mail with your From address but their own SPF or DKIM, ask them to configure custom DKIM signing for your domain. Many platforms support this: Salesforce, SendGrid, Mailchimp, HubSpot. If they support it and still refuse, move that function to a tool that does.

Isolate legacy senders on a subdomain. If you have a printer, a legacy internal system, or an appliance that cannot be fixed, set up a subdomain and move that traffic off your primary From domain. Apply a separate DMARC policy to the subdomain. Your main domain stays at p=reject; the subdomain stays at p=none for legacy equipment.

A concrete example: a mid-sized company discovered their building access system was sending password-reset emails from noreply@theirdomain.com through an unauthenticated relay. The vendor had no plans to fix it. The company created access.yourdomain.com, moved the access system there, and set its DMARC policy to p=none while the main domain went to p=reject. No mail was lost.

Fix mismatched policies across your org. Some organizations have subsidiaries or satellite operations that send on behalf of the main company. If a domain in your DMARC DNS record is set to p=none but your primary domain is set to p=reject, receivers may selectively accept mail from the p=none domain while rejecting from the main domain. That inconsistency is exploitable. Align your policies before going fully reject.

When to flip the switch and what to watch afterward

Once your checklist is clean, timing matters.

Flip to p=reject during a low-traffic period. Monday morning and the days before holidays are not ideal. A quiet Tuesday or Wednesday gives you the best chance of catching problems during your workday rather than at 2am.

Set up alerting before you flip. If your monitoring tool does not alert you when rejection volume spikes, add that capability first. A spike in rejections within 24 hours of going to p=reject almost always means a sender was not accounted for. The faster you know, the faster you can roll back.

Keep a rollback plan. Change your DMARC record back to p=none if rejections spike. DNS changes for DMARC take effect for new messages within minutes for most receivers, though some may cache the old record briefly. Do not wait three days hoping it settles. If something is wrong, it compounds.

Frequently Asked Questions

What does DMARC p=reject actually do?

It tells receiving mail servers to silently discard any message that fails DMARC authentication. The sender does not receive a bounce notification. The message simply disappears from the recipient's inbox.

How long should I stay at p=none before moving to p=reject?

At minimum 30 days, and only after your aggregate reports show 95% or higher aligned pass rate across all legitimate senders. If you discover a new sending source after going to p=none, account for it and reset the clock.

What percentage of mail should pass DMARC before I go to reject?

Aim for 95% or higher of messages showing disposition=pass in your aggregate reports. Any gap represents mail that will silently fail to deliver when you switch.

Can I go back from p=reject if something breaks?

Yes. Change your DMARC record from p=reject back to p=none at any time. The change takes effect for new messages within minutes. If you have rejection alerting set up through DMARCFlow or another tool, you will see the spike before it becomes a widespread problem.

Does DMARCFlow help with the readiness check?

DMARCFlow parses aggregate reports and shows aligned pass rates by domain and sender, making it easier to spot the senders that need attention before you go to reject. It starts at 1 EUR/month and runs on EU-hosted infrastructure, which matters for organizations subject to GDPR requirements. The mobile app also lets you monitor rejection alerts after the switch, so you catch problems before users report them.