How to Change DMARC Policy from "none" to "reject"

The short answer: you move in phases. Audit first, then p=none to p=quarantine to p=reject. Each phase involves reading DMARC aggregate reports and confirming zero failures before moving forward.

This process takes most domains 60 to 90 days from start to finish. The ones who skip phases and go straight to p=reject are the ones who end up calling their IT team at 9 PM because half their invoices are bouncing.

Here is how to do it properly.

Why "p=none" Is a Temporary Setting, Not a Destination

p=none tells receiving servers to do nothing -- accept everything regardless of alignment. It is a passive setting. It produces reports but takes no action.

The only reason to stay at p=none indefinitely is if you send email through so many third-party systems that you genuinely cannot achieve alignment. That is rare. For most organizations, p=none is a monitoring tool, not a destination.

The goal is p=reject. p=none is just the ramp.

What Happens When You Set DMARC to "reject"

p=reject tells receiving servers to refuse non-aligned messages outright. A message fails DMARC when it does not pass SPF or DKIM alignment. There are two alignment modes:

Aligned: the From domain matches the domain used in SPF (sending IP) or DKIM (signing domain)
Not aligned: the From domain and the SPF/DKIM domain are different, and no valid DMARC alignment exception applies

If neither SPF nor DKIM is aligned with the From domain, the message gets rejected. This is the desired outcome for spoofed emails impersonating your domain.

The Two-Phase Migration: p=none to p=quarantine to p=reject

Most domains follow this sequence:

1. p=none: monitor and audit. Make no changes to policy enforcement.
2. p=quarantine: suspicious messages go to spam folder instead of being accepted outright. This is a lower-stakes test.
3. p=reject: full enforcement. Receiving servers refuse non-aligned messages.

Some domains add a fourth step using the pct tag (percentage). This lets you enforce DMARC on only, say, 10% of messages while you verify. You can raise the percentage as confidence grows.

The standard recommendation is to spend at least 30 days at p=none before moving to p=quarantine. Most domains then spend another 30 to 60 days at p=quarantine before going to p=reject. Rushing this is how you end up with a 2 AM incident call.

Step 1: Audit Your Email Sources Before Changing Anything

Before you touch your DMARC record, document every system that sends email on behalf of your domain. This includes:

Your primary mail server (Exchange, Postfix, etc.)
Marketing platforms (Mailchimp, HubSpot, etc.)
Transactional email services (SendGrid, AWS SES, etc.)
HR and payroll systems
CRM platforms
Internal alert systems
Any legacy or undocumented relay you find in your SPF record

If a system sends email but is not in your SPF record, that is a problem to fix before you tighten your DMARC policy.

Step 2: Set a DMARC Aggregate Report Parser

Every DMARC policy needs a destination for aggregate reports. This is the RUA tag in your DMARC record.

Without a parser, you get XML files emailed to a mailbox you never check. Nobody does that manually for more than a week.

The RUA tag points to a URI where receivers send your XML aggregate reports on a schedule -- typically once every 24 hours per receiver domain.

DMARC aggregate reports contain:

Which IPs are sending as your domain
Whether each IP produces aligned SPF, aligned DKIM, both, or neither
Message volume per sending IP
Disposition applied (none, quarantine, reject)
Authentication results

The parsing step is where most teams stall. The XML files are structured but verbose, and reviewing them manually for more than a few sending domains quickly becomes impractical. This is where DMARCFlow fits naturally into the workflow -- it reads the XML format, breaks down the data by sending IP, and flags anything that was not there in previous reports. You do not need to open a single XML file to know that a new sending IP appeared last Tuesday.

Step 3: Read Your First DMARC Reports

After setting up your parser, wait 3 to 5 days for the first aggregate report to arrive. Most major receivers (Google, Microsoft, Yahoo) send daily. Smaller receivers may take longer.

When the report arrives, focus on two numbers:

Failure rate: what percentage of your outbound volume is producing DMARC failures (aligned SPF fail or aligned DKIM fail). If this number is above 1% in the first week, something is misconfigured. If it is below 1% and stable, you are ready for the next phase.

Sudden changes: if your failure rate spikes after you change your DMARC policy, that is your early warning system. Revert and investigate before the next wave of mail arrives.

Common things that cause failures:

A third-party ESP is sending as your domain without DKIM signing
A forwarding rule is rewriting headers in a way that breaks alignment
A mailing list is sending as your domain without proper DKIM configuration
A legacy system is using a hardcoded sending IP not covered by SPF

Step 4: Fix Alignment Failures Before Moving to p=quarantine

If you see failures, fix them before tightening the policy. The failure tells you something is sending as your domain that does not have valid alignment. You need that system fixed or formally included before receivers start taking action on non-aligned mail.

Common fixes:

Add the third-party ESP's DKIM keys to your DNS so they sign with your domain
Route ESP mail through a subdomain with its own DMARC record
Remove forwarding rules that rewrite headers if they cannot be reconfigured
Update your mailing list software to preserve original DKIM signatures

Do not move to p=quarantine while you have unexplained failures. Those failures will become rejections.

Step 5: Move to p=quarantine and Monitor for 30 to 60 Days

When your failure rate has been below 1% for at least two consecutive weeks, change your DMARC policy to p=quarantine:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=25;

The pct=25 means only 25% of messages are subject to the quarantine policy. This is your safety net. If a legitimate sender is still misconfigured, only a quarter of their messages go to spam instead of all of them.

After two weeks at 25% with no complaints about missing mail, raise it to pct=50. After another two weeks with no issues, raise to pct=100.

When pct=100 and you have had zero quarantine incidents for 30 days, you are ready for p=reject.

Step 6: Move to p=reject When Zero Failures Are Reported

Final DMARC record:


v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com;

Remove the pct tag or set pct=100. Full enforcement is now active.

Before you make this change, confirm:

Zero DMARC failures in the last 30 days
Zero quarantine incidents in the last 30 days
No new email systems added since your last audit
All third-party ESPs are signing DKIM with your domain or are properly isolated on subdomains

What to Do If Legitimate Mail Still Fails After the Switch

If mail starts bouncing after p=reject goes live, revert immediately to p=none and investigate. The failures are almost always an alignment problem, not an authentication problem.

The most common causes:

A third-party ESP is still not signing DKIM with your domain
An internal system is sending from an IP not in your SPF record
A mailing list or forwarder is rewriting From headers

Check your aggregate reports to see which IP is failing and why. The report tells you the sending IP, the alignment result for SPF and DKIM, and the reason for failure. Work backwards from the specific failure to the specific system.

How DMARCFlow Fits Into This Process

The three-phase migration is not a one-time project -- it is an ongoing operational process. After you reach p=reject, you still need to monitor reports for new senders, configuration drift, and third-party ESP changes.

The time-intensive part of this migration is reading and acting on DMARC aggregate reports. DMARCFlow automates that loop: it collects reports across all your domains, surfaces sudden failure spikes when you change policies, tracks your migration progress from p=none through to p=reject, and flags new third-party senders that appear in your SPF or DKIM records before they become incidents.

The migration itself is a sequence of decisions -- when to move from p=none to p=quarantine, when to raise the enforcement percentage, when to go to p=reject. Each decision rests on what the aggregate reports show. DMARCFlow makes each decision faster and less error-prone than reviewing XML files manually, and it maintains a migration history that surfaces when a sender was first flagged versus when it became a problem.

Frequently Asked Questions

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

At least 30 days, with a failure rate consistently below 1%. If you have many third-party senders, spend the full time auditing and fixing each one before tightening the policy.

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

Only if you have been running at p=none for an extended period with zero failures and you are certain you have documented every legitimate sender. Most domains should not skip this step. p=quarantine gives you a lower-stakes test environment.

How do I read DMARC aggregate reports?

You need a parser that can read the XML format used by major receivers. Manual review of XML files is impractical beyond a few sending domains. Use a parser that consolidates all your RUA reports into a readable dashboard.

What causes DMARC failures even after SPF and DKIM are configured?

The most common cause is third-party email services that do not DKIM-sign with your domain. Also check: forwarding rules that rewrite headers, mailing list software that strips DKIM signatures, and internal systems that send from IPs not covered by your SPF record.