Migrate DMARC: Monitor to Quarantine to Reject

DMARC is the most powerful email authentication control because it tells receivers what to do with mail that fails. But that power is also the danger: set it to reject too early, and you can block legitimate email that hasn't yet been fixed. The safe way to roll out DMARC is in stages — monitor, then quarantine, then reject — using the reports to prove each step is safe.

This guide walks through the migration, the reports you need to read, and how to know when it's time to tighten.

What DMARC does

DMARC builds on SPF and DKIM. For each message, the receiver checks:

1. Does it pass SPF or DKIM (with alignment)?
2. If not, what should the receiver do — based on your p= policy?

The policy is in your DMARC TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

The p= value is the enforcement: none, quarantine, or reject. The rua= tells receivers where to send aggregate reports.

The three stages

Stage 1: p=none (monitor)

Start with p=none. This tells receivers to report on authentication failures but not to reject anything. You get the data with zero risk.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

During this stage, you're learning: which servers send mail for your domain, which pass SPF/DKIM, and which would fail under a strict policy.

Stage 2: p=quarantine

Once monitoring shows your legitimate sources authenticate correctly, move to quarantine. Messages that fail go to spam instead of the inbox. This is a safe middle ground — it catches forgeries without hard-blocking mail.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Stage 3: p=reject

The strongest policy. Messages that fail SPF and DKIM are rejected outright. Only reach this stage when you're confident all your legitimate senders authenticate.

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

How to know you're ready to advance

The decision to tighten should be data-driven, not a guess. Read your DMARC aggregate reports (rua= XML reports) and ask:

• What's the authentication pass rate? If legitimate sources are consistently passing SPF or DKIM, you're ready.
• Are there false positives? If real mail from a source you rely on is failing, fix that source's SPF/DKIM (and alignment) before enforcing.
• How much would be affected? The reports tell you exactly which IPs/senders would be blocked under the stricter policy.

A common rule of thumb: when your aggregate reports show a high pass rate for all expected senders and no unexplained failures, it's safe to move to the next stage.

Common mistakes

1. Skipping none. Jumping to reject without monitoring is how you break legitimate email.
2. No rua=. Without a report address, you're enforcing blind — you can't see what's failing.
3. Ignoring SPF/DKIM fixes. DMARC only helps if the underlying authentication works. Fix SPF and DKIM alignment first.
4. Forgetting subdomains. Use sp= to set a policy for subdomains, or forgeries on subdomains may be treated differently.

A practical checklist

• SPF is healthy (under 10 lookups, ~all/-all).
• DKIM is aligned with the From domain.
• p=none with rua= is live and reports are being received.
• Aggregate reports show legitimate sources passing.
• Move to p=quarantine for a few weeks.
• Confirm no false positives, then move to p=reject.
• Keep rua= and add ruf= (forensic reports) for deeper visibility.

The takeaway

DMARC is a migration, not a switch. Start in none to monitor, fix your SPF and DKIM alignment based on the reports, move to quarantine once it's safe, and only then enforce reject. Done this way, DMARC blocks forgeries without breaking the mail your users actually rely on.

Check your SPF and DKIM alignment with the tools, then use the DMARC inspector to confirm your policy before you tighten it.

Why a staged rollout is non-negotiable

The cardinal rule of DMARC is: never jump straight to a strict policy. If you enforce p=reject before every legitimate sending source is authenticated, you will silently break real email — a transactional message, a newsletter, an automated invoice — that a genuine recipient depends on. The whole point of the staged rollout is to confirm, with evidence, that the legitimate senders pass before you tighten the policy. A DMARC migration is therefore a controlled policy escalation guided by the aggregate reports, not a single configuration change.

The monitor → quarantine → reject sequence

The standard path moves through three policy levels, each gated on evidence:

• Monitor (p=none) — the policy takes no action on failing mail but requests aggregate reports. This is the discovery phase: you learn who is actually sending as your domain, what passes, and what fails, without breaking anything.
• Quarantine (p=quarantine) — failing mail is sent to spam rather than delivered. You escalate here only once the reports show that all your legitimate senders pass. This contains the abuse while keeping a safety net.
• Reject (p=reject) — failing mail is refused outright. This is the strongest protection, adopted only after quarantine confirms that legitimate traffic is unaffected.

Each step is a decision informed by the reports, and you can stay at a level as long as needed. The authentication guide explains the underlying SPF/DKIM/DMARC mechanics this relies on.

Reading the evidence to advance safely

The key skill is reading the aggregate reports before escalating. Confirm that the sending sources you recognize appear as aligned and passing; identify any failing sources and whether they are legitimate (then fix their authentication) or illegitimate (good — the policy is working). Only escalate when the passing set is stable and complete. If a legitimate sender is still failing, fix it before tightening, or you will quarantine or reject your own mail.

A few rollout details that save pain

Set rua= to an address that actually receives and is monitored, set pct= at 100 only after confidence builds (a lower percentage limits the blast radius while testing), add sp= (subdomain policy) deliberately, and re-run the migration whenever you add a new sending source. These details keep the rollout reversible and prevent a policy change from quietly damaging delivery for weeks before anyone notices.