How to move from DMARC p=none to p=reject safely

What p=none and p=reject actually mean

When your DMARC record has policy p=none, receiving mail servers do nothing with emails that fail DMARC checks. They accept or reject based on their own spam rules. Your record is effectively in monitoring mode.

When you switch to p=reject, receiving servers reject any message that fails DMARC alignment. No quarantine, no spam folder. Hard reject.

The risk of jumping straight to p=reject without preparation is real: legitimate email from your domain can get rejected if it passes SPF or DKIM but fails DMARC alignment. This is the failure practitioners run into most often, and it is preventable.

How long to monitor before moving to p=reject

Most practitioners recommend a minimum of 4 to 8 weeks at p=none. Some run it longer if the domain is large or has many internal sending systems.

The purpose of the monitoring period is to read your DMARC aggregate reports and find all legitimate sources sending on your behalf before you tell the world to reject anything that fails. Rushing this phase is the most common cause of breaking legitimate email when you finally move to p=reject.

A practical lower bound: stay at p=none until you have received reports covering at least two full billing cycles for any automated systems that send on your domain. Many legitimate failures only surface when monthly invoices go out.

The DMARC pre-flight checklist

Before changing your policy, confirm the following:

SPF is passing for every legitimate sending source. Run a DNS lookup on your SPF record. Check that every IP address in the record is one you control or one owned by a vendor you explicitly authorize. Remove any IP addresses for services you no longer use.

DKIM is signing every legitimate outbound message. Not just marketing emails. Transactional emails, automated alerts, internal system notifications. If a vendor sends on your behalf, confirm they are publishing their DKIM key under your domain, not their own.

You have identified every legitimate sending source from your aggregate reports. Your aggregate reports will show you the IP addresses that are sending email as your domain. Cross-reference them against your known sending infrastructure. Anything you cannot account for needs investigation before you move to p=reject.

All third-party senders are compliant. If you use a CRM, marketing platform, help desk, or any other service that sends email from your domain, confirm they support DKIM signing under your domain. Gmail and Microsoft 365 both reject DMARC failures from third-party senders even when the content is legitimate.

Step-by-step: moving from p=none to p=reject safely

Week 0: Set your policy to p=none and configure report delivery.

Your DMARC record should look like this initially:


v=DMARC1; p=none; rua=mailto:your-reports@example.com; pct=100;

Point the rua address to a mailbox you check regularly, or use a DMARC report aggregation service. Reading raw XML reports by hand is painful and error-prone.

Weeks 1 through 8: Read aggregate reports and close gaps.

Every week, look at which sources are sending as your domain and whether they are passing or failing DMARC alignment. Use the source IP and alignment result fields to find failures. Track each failure back to a legitimate source or flag it as a threat.

This is the most labor-intensive part of the transition. DMARCFlow automates the aggregation and alerting, so you get notified when new failure patterns appear rather than having to check reports manually every day. Without automation, you are relying on yourself to notice spikes in the XML reports you receive.

For each failure you can identify as legitimate, update your SPF record or work with the vendor to set up DKIM signing under your domain.

When you see zero unaccounted failures for at least two consecutive weeks: you are ready to move to p=quarantine.

Note on the pct tag: if you do not specify pct, the default is 100. Every failing message gets rejected at p=reject. If you want to test slowly, set pct=10 or pct=25 to reject only a sample at first.

Step 1: Change policy to p=quarantine.


v=DMARC1; p=quarantine; rua=mailto:your-reports@example.com; pct=100;

p=quarantine tells receiving servers to mark failing mail as suspicious, usually by routing it to spam. This is a softer landing than p=reject and gives you another layer of real-world signal before the full switch.

Step 2: Monitor at p=quarantine for at least 2 weeks.

Watch your aggregate reports. If the volume of quarantined mail matches your expected failure pattern from p=none, proceed. If you see unexpected spikes, investigate before continuing.

Step 3: Change policy to p=reject.


v=DMARC1; p=reject; rua=mailto:your-reports@example.com; pct=100;

Watch your reports daily for the first week. Any new failure patterns at this stage indicate a legitimate source you missed during monitoring.

How to read aggregate reports during the transition

The most useful fields in a DMARC aggregate report are:

Source IP: the IP address sending the mail
DKIM result: pass or fail against your DKIM selector
SPF result: pass or fail against your SPF record
Alignment result: whether the From domain matches the DKIM domain or SPF domain
Message count: how many messages were affected

A DMARC pass requires both an authentication pass (SPF or DKIM) AND alignment. You can pass SPF but still fail DMARC if the RFC5321.From domain does not match the RFC5321.MailFrom domain used in SPF.

When reviewing reports during the transition, look for:

Alignment failures on messages that should be legitimate: this means a sender is using your From domain but using a different envelope. Work with that sender to align their DKIM or SPF setup.
Unexpected source IPs: these may be spoofing attempts, or they may be legitimate sources you did not know about.
High-volume failures from a single IP: if thousands of messages from one IP are failing alignment, you likely have a vendor or internal system that needs fixing.

Manual report parsing is time-consuming and easy to neglect when you are in the middle of other work. DMARCFlow automates the aggregation and alerting, so you get notified when new failure patterns appear rather than having to check reports manually every day.

What to do when legitimate mail fails after p=reject

If you move to p=reject and legitimate email starts bouncing, you have a few options in order of speed:

Option 1: Identify and fix the sending source with the help of your DMARC reports.

Your DMARC aggregate report tells you the exact source IP that caused the failure, the sending domain, and whether it was a DKIM or SPF alignment problem. Use that data to determine whether the sender is legitimate before you take any other action. DMARCFlow parses these fields automatically and presents them as a readable alert rather than raw XML. Read the DMARC failure report to get the source IP. Determine whether it is a legitimate sender you missed. If yes, add them to SPF or get them set up with DKIM signing under your domain. Then wait for DNS propagation and test.

Option 2: Lower pct to slow the impact. Add or reduce the pct tag to limit how many messages are affected:


v=DMARC1; p=reject; rua=mailto:your-reports@example.com; pct=50;

This causes a 50% random sample of failing messages to be rejected while the rest are delivered. Use this as a temporary throttle while you fix the underlying issue.

Option 3: Revert to p=quarantine while you investigate. If you cannot identify the failure source quickly, revert to p=quarantine to stop the rejections while you dig into the reports. A brief return to quarantine is not a failure; it is the correct operational decision.

Option 4: Adjust the subdomain policy separately. If the failure is coming from subdomains, you can set a different policy for subdomains without affecting the root domain:


v=DMARC1; p=reject; rua=mailto:your-reports@example.com; sp=quarantine;

This is useful when a subdomain has a legitimate reason to send through a system that does not yet support DKIM alignment.

Frequently asked questions

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

At minimum 4 weeks. 8 weeks is better for domains with complex sending infrastructure. The goal is to capture at least two cycles of any automated sending system and to see all failure patterns during normal operations.

How do I find all the sending sources my domain uses?

Start with your SPF record to list every authorized IP. Then check your DMARC aggregate reports for any source IPs not in your SPF record. For each unknown source, investigate whether it is legitimate before blocking it. Pay attention to internal mail systems, legacy servers, and third-party platforms that may send on your behalf.

What does it mean when my DMARC report shows alignment failures?

Alignment failure means the message passed SPF or DKIM but the From domain did not match the domain used for that check. This often happens with third-party senders who send from their own infrastructure but use your domain in the From address. It can also happen with internal mail systems that do not use DKIM at all.

How do I know if moving to p=reject will break legitimate email?

If you have thoroughly reviewed your aggregate reports at p=none and found zero unaccounted failures over a sustained period, the risk is low. The keyword is unaccounted. Any failure you cannot explain is a risk.

What do I do if a legitimate sender fails after moving to p=reject?

Identify the source IP from the failure report. Determine if it is a legitimate sender you missed. Fix their SPF or DKIM alignment. If you need more time, reduce the pct tag or temporarily move to p=quarantine while the fix propagates.