Moving from p=none to p=reject: The DMARC Enforcement Guide

Why p=none Is Only Step One

Publishing p=none is the right first move. It gives you visibility without risk — mailbox providers send you DMARC aggregate reports, and no mail is affected regardless of whether it passes or fails.

But p=none is not the destination. It does nothing to stop email spoofing or protect your domain's reputation. A phishing campaign using your domain in the From: header gets delivered just as easily with p=none as with no DMARC record at all.

The goal is enforcement: moving to p=quarantine (failing messages go to spam) and eventually p=reject (failing messages are blocked entirely). The purpose of monitoring is to give you the information you need to do that safely.

If your domain has been on p=none for weeks or months without progressing, see DMARC p=none: Why You Should Move to Enforcement.

The Enforcement Ladder

DMARC gives you a graduated path to enforcement using two mechanisms: the p= policy and the pct= percentage tag.

The graduated approach exists to limit the impact if you missed a legitimate sender during monitoring. A misconfigured sender at 25% means 75% of its messages still get delivered — giving you time to fix the configuration before the full policy takes effect.

What "Ready" Looks Like Before Each Step

Before moving from monitoring to quarantine, you need to be able to answer these questions with confidence:

1. Have you identified all legitimate senders?

Your DMARC aggregate reports should show every IP sending email as your domain. Each one should be either a service you recognize and have configured, or traffic you have deliberately classified (forwarded mail, denied senders, known infrastructure).

If you have significant unclassified traffic volume — sources you cannot explain — do not move to quarantine yet. Understand what is there first.

2. Are your legitimate senders aligned?

Every sender you rely on should be passing DMARC alignment. That means either SPF passes with your domain in the envelope sender, or DKIM passes with d=yourdomain.com in the signature. Ideally both.

The practical threshold before moving to quarantine: 95% or more of your recognized/authorized sending volume should be passing alignment. If a significant percentage of your known traffic is still failing, fix those senders first.

3. Are you monitoring consistently?

You should have at least 2–4 weeks of data covering a full business cycle — monthly newsletters, billing emails, onboarding sequences, anything that sends on a schedule longer than daily. A sender that runs once per month is invisible in a one-week sample.

Before moving to p=reject from p=quarantine:

The same criteria apply, but you need a longer track record at quarantine:

• No legitimate senders appearing in quarantine over 2–4 weeks of p=quarantine; pct=100
• No reports from stakeholders of missing or filtered email
• Subdomain policy reviewed (see below)

What Can Go Wrong at Each Stage

Moving to p=quarantine

Forgotten senders. The most common problem. A service that another department set up — a new CRM, a quarterly HR notification, a contractor's mailing tool — appears in your aggregate reports failing DMARC, and suddenly its email starts landing in spam.

Prevention: cross-check with marketing, sales, support, finance, and engineering before moving. Ask specifically whether anyone has set up a new service that sends email with your domain in the From header in the past quarter.

DKIM not configured for legacy tools. Older tools or internally built applications may not support DKIM with a custom domain. They will pass SPF if you added their IP ranges, but DKIM alignment will fail. At p=quarantine, this becomes visible to recipients.

Forwarding chains breaking. Some forwarding arrangements that were tolerated under p=none become problematic at quarantine if DKIM signatures are being broken. Check that your primary senders all have DKIM configured — it is the mechanism that survives forwarding.

Moving to p=reject

Mailing list breakage. Mailing lists redistribute email keeping the original From: header. The redistributed message fails SPF (the list server is not in your SPF record) and may fail DKIM if the list adds footers or rewrites links. At p=reject, those redistributed messages get bounced.

This is a known limitation of DMARC with mailing lists, documented in RFC 7960. If your organization has heavy mailing list usage, factor this in before moving to reject.

Incomplete DKIM deployment. If any significant sender is relying solely on SPF alignment and does not have DKIM configured, it is vulnerable to forwarding failures at p=reject. DKIM is not optional at full enforcement — you need it on every sender.

Subdomain inheritance. Subdomains that do not have their own DMARC record inherit the parent domain's policy. If app.yourdomain.com sends transactional email and you have not verified its authentication is clean, moving the parent to p=reject can block that subdomain's mail.

How Long to Wait at Each Stage

There is no fixed timeline — it depends on your sending volume and the variety of your sending patterns.

As a practical guide:

• p=none monitoring: 2–4 weeks minimum. Longer if your domain has irregular sending patterns (seasonal business, infrequent bulk sends).
• p=quarantine; pct=25 → pct=100: 1–2 weeks per step with no reported issues.
• p=quarantine; pct=100: 2–4 weeks before moving to reject.
• p=reject; pct=25 → pct=100: 1–2 weeks per step.

Move faster only if you have high confidence in your sender inventory — for example, a new domain with a small, well-documented set of senders. Move slower if your organization is large, if sending patterns are complex, or if you cannot easily reach all the teams that use email services.

Do not use the pct= ramp to substitute for proper monitoring. The purpose of pct is to limit blast radius in case you missed something — it is a safety net, not a monitoring replacement.

When NOT to Move to Reject

Some situations genuinely call for holding at p=quarantine or even p=none longer than usual:

Heavy forwarding use cases. If your users frequently forward email to personal addresses, or if your organization relies on mailing list distributions, p=reject will break those workflows in ways that are difficult to fix. Consider whether the tradeoff is acceptable before moving.

Incomplete DKIM deployment. If you cannot configure DKIM for all legitimate senders — because a vendor does not support it, or because an internal system cannot be modified — you are dependent on SPF alignment alone. That is less resilient. Hold at quarantine until DKIM is in place everywhere.

External recipient complaints about filtered mail. If stakeholders are already reporting legitimate email going to spam at p=quarantine, do not move to reject. Diagnose and fix the underlying alignment issue first.

Recently discovered senders. If your most recent monitoring period revealed a sender you did not know about, fix its configuration and wait for a full cycle of clean reports before advancing.

How mxio's Enforcement Readiness Assessment Works

The Enforcement advisor in the DMARC Reporting dashboard automates the readiness analysis described above.

As aggregate reports arrive, it tracks:

• what percentage of your total sending volume comes from classified/authorized sources
• what percentage of your authorized sources are passing alignment
• whether any significant unclassified traffic remains
• whether you have open misconfiguration issues on known senders

When you meet the threshold to safely move to the next policy level, the advisor tells you. When something is blocking you, it shows you specifically what — a misconfigured sender, a high-volume unknown source, or a subdomain with a different policy inheritance.

It also generates the exact DNS record change for each step in the ladder, so you are not writing the record syntax from scratch.

This does not replace your judgment — you still need to check with stakeholders and verify your sender inventory is complete. But it replaces the manual process of reading aggregate report XML, counting passing IPs, and doing the arithmetic yourself.

Related Articles

• DMARC Deployment Guide: From p=none to p=reject — the complete deployment process including DKIM and SPF setup
• Understanding DMARC Aggregate Reports — how to read the XML reports the enforcement decision is based on
• DMARC Reporting in mxio: Setup, First Data, and What To Do Next — the DMARC Reporting dashboard product guide
• DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails — the most common class of problem during enforcement ramp-up
• DMARC p=none: Why You Should Move to Enforcement — what you are leaving on the table by staying at monitoring