How to move your DMARC policy from p=none to p=reject without breaking mail

Moving your DMARC policy from p=none to p=reject is the right goal. It is also the step that makes most administrators nervous. The fear is legitimate: flip the switch too early and valid mail starts bouncing. Stay at p=none too long and your domain stays exposed to spoofing.

The upgrade is straightforward if you do it in stages and watch the right signals. Here is how to do it.

Why p=reject is the goal

p=none tells receiving servers to do nothing with mail that fails DMARC. Your domain is published in DNS but offers no protection. Spoofers can send mail pretending to be from your domain and it will arrive normally.

p=reject tells receiving servers to refuse outright any mail that fails DMARC. This is full protection. A spoofer sending mail that does not align with your SPF or DKIM will be rejected at the door, not delivered to the inbox.

p=quarantine is the middle ground. Failing mail gets tagged as suspicious, usually landing in spam. It reduces spoofing risk but does not eliminate it.

p=none exists because getting SPF, DKIM, and DMARC alignment right takes time. Organizations use p=none to monitor what legitimate mail is doing before locking things down. The problem is that p=none is comfortable and the upgrade feels risky.

It does not have to be.

Read your aggregate reports before changing anything

Before you touch your DMARC record, you need to know what legitimate mail is sending through your domain and how it authenticates.

DMARC aggregate reports arrive daily from receiving servers. They do not contain message content. They contain counts: how many messages arrived from your domain, how many passed DMARC, how many failed.

The key number to find in each report is this: how many messages are failing DMARC but come from a source you control? Those are the failures you need to fix before you upgrade.

Common causes of legitimate mail failing DMARC:

• A mailing list or email gateway that rewrites the From header
• A marketing automation platform or CRM sending on your behalf without proper DKIM signing
• A legacy mail server that does not align with your SPF or DKIM
• A cloud productivity suite that sends from a subdomain you forgot to include in your SPF record

Reading raw DMARC XML reports is doable but slow. Most teams use a parser that turns the data into something readable. The critical action is this: identify every failing source that you control and fix its SPF or DKIM alignment before you advance your policy.

You want to reach a state where at least 95 percent of your legitimate sending volume passes DMARC before you consider moving to p=quarantine.

Fix alignment failures first

DMARC checks alignment. For a message to pass DMARC, either the SPF domain must match the From header domain exactly (or be a subdomain under certain conditions), or the DKIM domain must match the From header domain exactly.

If you have a vendor sending mail as you, that vendor must either send through your mail server (SPF aligned) or sign with a DKIM key that uses your domain (DKIM aligned). If they do neither, their mail fails DMARC regardless of whether their own SPF record is valid.

This is a common problem with transactional email platforms. SendGrid, Brevo, Mailgun, and similar services all offer custom domain sending. The setup requires DKIM signing on their infrastructure with your domain. If that is not configured, their mail fails DMARC when they send as you.

Before upgrading, identify every legitimate sender using your domain and confirm their authentication setup. Anything you cannot fix should have a subdomain reserved for it so its failures do not drag down your main domain policy.

The safe upgrade sequence

Once your aggregate reports show consistent high pass rates, upgrade in stages.

Stage 1: Stay at p=none

Duration: 30 to 60 days minimum.

Collect aggregate reports every day. Look for patterns. Weekends and weekdays can show different sending volumes. Automated systems may send at night. You want to see all your normal traffic patterns before proceeding.

If anything unusual appears in reports, investigate before advancing.

Stage 2: Move to p=quarantine

Change your DMARC record from p=none to p=quarantine.

Duration: 14 to 30 days.

Watch for two things. First, check your own inbound mail flow. Are colleagues receiving mail from your domain that suddenly lands in spam? That is a quarantine event for mail you sent.

Second, monitor your reject and quarantine notifications. If your domain sends mail to external recipients and something is misconfigured, you may start seeing reject or quarantine messages coming back to your postmaster address.

If you see a spike in rejects from a specific destination, that destination is receiving mail from your domain that is failing DMARC. Either fix the sending source or exclude that subdomain with a pct tag to limit exposure while you resolve it.

The pct tag controls what percentage of failing traffic gets affected. Setting pct=50 means 50 percent of failing messages get rejected or quarantined and 50 percent pass through unaffected. Use it cautiously and temporarily. It is better to fix the root cause than to rely on pct to hide problems.

Stage 3: Move to p=reject

Once you have gone 14 to 30 days at p=quarantine without unexpected quarantine events on legitimate mail, move to p=reject.

Duration: permanent.

Most organizations find that the jump from p=quarantine to p=reject is smooth if the preparation was thorough. The aggregate reports at p=quarantine stage showed exactly what would happen.

What to do when rejects start appearing after upgrading

They will. Even with perfect preparation, you will occasionally see a reject notification come back.

The most common cause is a new vendor or internal system you forgot about. Someone stood up a new piece of software that sends email as your domain and did not configure authentication.

The fix is the same as during preparation: identify the source, configure SPF or DKIM alignment, wait for DNS to propagate, and confirm via aggregate reports that the source now passes.

If the mail is not important, you can also exclude that subdomain from DMARC. But exclusion should be a temporary measure while authentication is being set up, not a permanent workaround.

How DMARCFlow helps during and after the upgrade

The hardest part of moving from p=none to p=reject is not the DNS record change. It is the monitoring. Aggregate reports arrive daily and they are verbose. Parsing them manually for every sending domain you control takes time.

During an upgrade, the thing that bites you is a new source appearing in your reports after you have already tightened the policy. A new marketing platform gets connected, someone stands up a new internal tool, a subsidiary starts sending mail. These changes do not always come with a notification to the email team. Without continuous monitoring, you find out about the resulting rejects when a business user calls to say their mail is not getting through.

DMARCFlow monitors your DMARC reports continuously and alerts you when a new source starts failing. That early warning means you can fix the authentication configuration before the problem reaches your users.

After the upgrade is complete, DMARCFlow continues monitoring. New infrastructure gets added over time. DMARCFlow catches the authentication gaps before they become rejected mail.

FAQ

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

At minimum 30 days. Longer if you have complex sending infrastructure or seasonal mail patterns. You want to see at least two full billing cycles for any automated sending you do.

What percentage of legitimate mail should pass DMARC before I upgrade?

Aim for 95 percent or higher. If 5 percent of your legitimate volume is failing, that is a significant chunk of mail that will be rejected or quarantined when you tighten the policy.

Can I skip p=quarantine and go straight from p=none to p=reject?

Technically yes. If your aggregate reports are clean and you are confident in your sending infrastructure, you can. But p=quarantine gives you a safety net. Quarantine events show up in your reports and you get visibility. Going straight to p=reject means any mistake lands as a hard reject with no middle ground.

My aggregate reports show failures from my own IP addresses. What do I do?

If your own mail server is failing DMARC, check your DKIM signing configuration and your SPF record. A properly configured mail server sending from its own IPs should pass SPF alignment. DKIM signing issues are the more common cause of alignment failures from your own infrastructure.

I upgraded and now a critical vendor is blocked. What do I do?

Revert to p=quarantine immediately. Contact the vendor and get their authentication configuration sorted. Once they confirm DKIM signing or SPF alignment is set up, wait for DNS propagation and review aggregate reports before moving back to p=reject.

Bottom line

The path from p=none to p=reject is well-traveled. The steps are: read your reports, fix alignment failures, upgrade in stages, and monitor throughout. Each stage has a purpose. Do not skip p=quarantine unless you are certain your sending infrastructure is clean. And watch your reports continuously during the transition so you find out about problems before your users do.