Safely Moving DMARC from p=none to quarantine to reject

With DMARC set to p=reject, mail that spoofs your domain is blocked before it ever reaches an inbox. But if you jump straight to reject without preparation, you also throw away the legitimate mail your company actually sends — newsletters, payment receipts, recruiting systems, and more. That is why DMARC should always be strengthened in stages: monitoring (none) → quarantine → reject, reading reports along the way.

This guide walks through what to check and fix at each stage, and how the pcttag lets you ramp enforcement gradually. Before you start, check your domain's current policy with the DMARC record lookup.

Step 0 — Prerequisite: SPF and DKIM must align first

DMARC does not create new authentication. It reads the results of SPF and DKIM and decides whether the authenticated domain aligns with the message's visible sender (the From: header domain). So before tightening DMARC, every legitimate sending path must pass via SPF or DKIM alignment — at least one of the two.

• SPF alignment: the Return-Path (envelope from) domain must share the organizational domain with the From: domain. SaaS senders usually set the envelope from to their own domain, so SPF passes but alignment breaks.
• DKIM alignment: the signature's d= domain must align with the From: domain. This is why most SaaS senders have you publish a DKIM CNAME under your own subdomain.

Confirm that your DKIM selector is actually published and readable with the DKIM record lookup. If neither SPF nor DKIM aligns and passes, that source fails DMARC — and its mail will vanish once you reach reject.

Step 1 — p=none + rua to gather data (block nothing)

p=none is an observe-only policy that quarantines and rejects nothing. The point is the rua tag, which collects aggregate reports. Only once reports accumulate can you map every source sending as your domain — both legitimate and spoofed.

Example record: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; — fo=1 asks for a failure report whenever SPF or DKIM alignment fails, which is handy for debugging. Build records like this with the DMARC record generator, then verify publication with the DMARC lookup. Collect for at least 1–2 weeks, ideally 4, so you capture weekly sends and billing cycles.

Step 2 — Read the aggregate reports and fix legitimate sources

Aggregate reports are XML showing, per sending IP, the message count and SPF/DKIM alignment results. Your job is simple: make every legitimate message that failed start passing. Common legitimate sources and the fix:

• Marketing mail (Mailchimp, etc.) → publish the provider's DKIM CNAME and add their SPF include
• Payment / transactional mail (Stripe, etc.) → delegate DKIM on a sending subdomain
• Groupware / ERP / recruiting systems → add their server IPs to SPF and enable DKIM signing
• Old forwarding (ex-employee aliases) → SPF breaks but DKIM survives, so rely on DKIM alignment

The goal is a state where only unknown (possibly spoofed) senders still fail, while every legitimate sender aligns and passes 100%. Not spending enough time here before moving on is the single most common mistake.

Step 3 — quarantine with a pct ramp (25 → 50 → 100)

Once all legitimate mail passes, raise the policy to p=quarantine. Failing mail usually lands in spam rather than disappearing, so the risk is lower than reject. The pct tag controls what percentage of mail the policy applies to, so you can enforce gradually instead of all at once.

1. v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; — observe for a few days
2. If nothing breaks, move to pct=50
3. Once stable again, go to pct=100

Between each step, re-read the reports and confirm no legitimate source has started failing. Rebuild each stage's record with the DMARC generator and swap it in.

Step 4 — Final hardening to reject

After p=quarantine; pct=100 runs for several days to a few weeks with no loss of legitimate mail, raise it to p=reject. Now misaligned mail is rejected at the receiving server, so spoofed mail never reaches the inbox. Keep rua in place to keep monitoring for new sources or abuse attempts.

Stage summary table

The biggest mistake in this whole flow is a single one: jumping to reject before fixing your sources. Never raise the policy to reject until reports prove that every legitimate sender aligns and passes.