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.