Blog · Dmarc
How to Safely Move to DMARC p=reject Without Breaking Your Email
How to Safely Move to DMARC p=reject Without Breaking Your Email
Flipping your DMARC policy to p=reject is the point where your domain stops accepting unauthenticated mail. That is exactly what you want. But if you switch before your infrastructure is ready, you will start bouncing legitimate email from customers, vendors, and internal systems you forgot to audit. The fix is not to avoid p=reject forever. The fix is to move to it deliberately.
Here is how to do that.
Why p=reject Is Worth the Effort But Also Risky
p=reject is the only DMARC policy that actually stops forged mail from reaching inboxes. p=none does nothing. p=quarantine sends unauthenticated mail to spam, which means your domain is still being impersonated, just less effectively. p=reject closes the door entirely.
But that power cuts both ways. If your domain is sending mail through a system that is not properly SPF-aligned or DKIM-signed, p=reject will reject that mail too. And depending on how your infrastructure is set up, you might not immediately know it is happening. Vendor mail gets silently blocked. Customer notifications disappear. Internal alerts stop reaching the people who need them.
The solution is not to stay at p=none forever. It is to spend enough time at p=none that your aggregate reports show you exactly what is sending mail on your behalf, so you can fix the problems before you flip the switch.
The DMARC Pre-flight Checklist Before You Switch
Before you change your DMARC record to p=reject, work through this list. The common failure mode is skipping this step and discovering the hard way that a forgotten CRM or internal appliance was sending unauthenticated mail.
1. Confirm SPF is aligned for every legitimate sending source
Your SPF record must include every IP address that sends mail on behalf of your domain. But alignment is the separate issue. For SPF to pass DMARC alignment, the RFC5321.MailFrom domain must match the RFC5322.From domain. If your marketing platform sends mail with a different envelope domain, its SPF result will be none even if its servers are authorized.
List every service that sends mail from your domain. Check each one individually. If a service cannot send from your domain with proper SPF alignment, either replace it or exclude it via a subdomains policy before moving to p=reject.
2. Confirm DKIM is signing with a domain-aligned signature
DKIM is more forgiving than SPF because it does not care about the envelope domain. But alignment still matters. A DKIM signature passes DMARC when the "d=" domain matches the RFC5322.From domain. Many third-party platforms let you choose which domain signs. Make sure you are using your primary domain, not a platform-specific subdomain like sendgrid.net.
Test your DKIM before proceeding. Use the free DKIM checker at dmarcflow.com to see whether your current DKIM setup is domain-aligned. Then verify that any DKIM signatures in your outbound mail use your actual domain in the "d=" field.
3. Check that all subdomains have their own policy or are explicitly excluded
If you have subdomains used by internal systems, legacy appliances, or specific business units, those need their own explicit DMARC policy. A subdomain without its own policy inherits the root domain's policy. If the root domain is set to p=reject, those subdomains go to p=reject too, which might break systems that have never been audited for email authentication.
The fix is to add explicit "v=DMARC1; p=none; pct=100; rua=mailto:..." for subdomains that are not yet ready, or to set a relaxed policy only for specific subdomains that need it.
4. Identify every third-party sender using your domain
Marketing platforms, CRMs, support ticketing systems, e-signature tools, and billing platforms all commonly send mail from addresses like "billing@yourdomain.com" but use their own servers to deliver it. None of those will pass DMARC p=reject unless they have been set up with proper SPF and DKIM alignment.
Go through your vendor list and check each one. Ask: does this service send from our domain? If yes, what authentication do they support? Some platforms support custom DKIM signing. Others do not and require you to use their sending domain instead of your own in the From address.
5. Set up DMARC aggregate report monitoring
Aggregate reports do not arrive instantly. They come from the receiving servers that accept or reject your mail. If you are not receiving them yet, you have no visibility into what is sending mail on your behalf. You need a monitoring tool that parses your aggregate reports and alerts you to new sources. DMARCFlow receives your aggregate reports and shows you which sources are passing or failing authentication, so you can catch unknown senders before they become outages.
How to Read Your DMARC Aggregate Reports Before Switching
DMARC aggregate reports arrive daily (sometimes less frequently) from the mail servers that process your mail. Each report covers a 24-hour window and lists every source that sent mail to the report receiver's domain during that period.
The key field to look at is
Look for
You need at minimum 7 to 14 days of aggregate report data before moving to p=reject. If you have many sending sources or recent changes to your infrastructure, go longer. The goal is to have zero surprises in your aggregate reports before you enforce reject.
With DMARCFlow, your aggregate reports are parsed automatically and new sending sources trigger an alert. That means you do not have to manually review raw report data every morning. The tool surfaces the information you need to make a decision.
The Safe Transition Path: p=none to p=quarantine to p=reject
Do not go straight from p=none to p=reject. Use p=quarantine as a staging step.
Phase 1: Stay at p=none for at least 2 to 4 weeks
Your goal during this phase is to build a complete picture of your sending infrastructure. Every unique
Check your aggregate reports daily. New sending sources appear regularly when you onboard new tools or change your infrastructure. With daily monitoring via DMARCFlow, you get alerted to new sources within 24 hours rather than discovering them when they show up in a complaint thread.
Phase 2: Move to p=quarantine for 1 to 2 weeks
When you are confident that every source in your aggregate reports is legitimate and authenticated, change your policy to p=quarantine. This causes unauthenticated mail to go to spam rather than being rejected. Watch for two things: reported issues from users who are not receiving expected mail, and aggregate reports that show a spike in failed authentication from sources that were previously passing.
If things look clean during phase 2, proceed.
Phase 3: Move to p=reject
Only switch to p=reject when your aggregate reports show zero unknown sources and zero authentication failures from legitimate senders. If anything is still unclear, extend phase 2.
You can use subdomain-level policies to protect specific domains at different stages. For example, you might set your root domain to p=reject while keeping a legacy subdomain at p=none. This lets you enforce DMARC where you are ready without blocking mail from systems that are still being audited.
Warning Signs That You Are Not Ready for p=reject
You are not ready to switch if any of the following are true.
You have sending sources that do not control their own SPF and DKIM. Some platforms send from your domain using their own infrastructure. If they have not set up DKIM signing with your domain and you cannot add them to your SPF record without exceeding the 10 DNS lookup limit, those sources will break when you switch.
Your aggregate reports show mail going to spam or being rejected that you cannot explain. Something is sending mail on your behalf that you have not accounted for. Until you know what it is, do not switch.
Legacy systems are sending mail without authentication. Printers, multifunction devices, older appliances, and custom applications often send mail directly via SMTP without any authentication. These will fail at p=reject. Either remove the sending capability from these devices or put them behind a gateway that authenticates on their behalf.
You have not audited all third-party senders. If you onboard new tools regularly, you may have sent mail from a new platform before checking its authentication setup. Check your recent aggregate reports for any new sources that appeared in the last 30 days.
What to Do If Email Breaks After You Switch to p=reject
If mail breaks after switching to p=reject, the fix is fast. Roll back to p=quarantine or p=none immediately. Do not wait to see if the problem resolves itself. Unauthenticated mail is being rejected right now, and people are not receiving it.
After rolling back, check your aggregate reports for the period since you switched. Look for
Prioritize fixes in this order. Internal systems first: your own servers and applications are easier to audit and fix than external vendors. Then vendor authentication: work with your third-party senders to get their DKIM or SPF properly aligned. Then legacy devices: either remove their ability to send mail directly or route them through an authenticated relay.