Skip to content

A staged path from DMARC p=none to p=reject

A week-by-week DMARC rollout: monitor with p=none, fix every legitimate source, move to quarantine, then reject, with clear exit criteria per stage.

Koltrix Team4 min read
A red padlock resting on a black computer keyboard
Photo by FlyD on Unsplash
On this page(9 sections)
  1. Why stage the rollout
  2. Stage 0: prerequisites (a few days)
  3. Stage 1: monitor with p=none (2 to 6 weeks)
  4. Stage 2: fix the stragglers
  5. Stage 3: quarantine (2 to 4 weeks)
  6. What about pct?
  7. Subdomains as a gradual lever
  8. Stage 4: reject
  9. Things that will fail and are fine
  10. Rollout checklist
  11. Key takeaways

Publishing p=reject on day one is how companies discover, the hard way, that their payroll provider sends as their domain. Staying at p=none forever is how they stay spoofable.

The path between the two is a sequence of stages with clear exit criteria.

Why stage the rollout

A DMARC policy tells receivers what to do with mail that claims to be from your domain but fails authentication. At enforcement, failing mail goes to spam (quarantine) or is refused (reject). That is exactly what you want for spoofed mail, and exactly what you do not want for a legitimate system you forgot about.

Staging lets you find every legitimate sender while the policy has no teeth, fix each one, and then raise enforcement gradually.

Stage 0: prerequisites (a few days)

Before publishing anything, confirm:

  • SPF exists and is a single valid record under ten DNS lookups.
  • Your main mail systems sign with DKIM using your domain (d=example.com).
  • You have somewhere to receive aggregate reports: a dedicated mailbox, or a report-processing service. Reports arrive as compressed XML attachments and pile up quickly.

Stage 1: monitor with p=none (2 to 6 weeks)

Publish a monitoring record:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

p=none asks receivers to take no action on failures, only to report. Aggregate reports typically arrive once a day from each participating receiver.

During this stage, build a list of every source that sends with your domain in the From header:

Source Volume SPF aligned DKIM aligned Action needed
Workspace mail High Yes Yes None
Transactional provider High Yes Yes None
Help desk Medium No No Enable custom DKIM
Unknown IP range Low No No Investigate

Look up unfamiliar source IPs. Some will be forwarders (expected failures), some will be spoofers (the reason you are doing this), and some will be forgotten legitimate tools.

Exit criteria: every legitimate source you can identify passes DMARC through aligned SPF or aligned DKIM, and you have watched at least two full weeks of reports including any monthly mailings, such as invoices or newsletters, that would not appear in a shorter window.

Stage 2: fix the stragglers

This is where most of the time goes. For each failing legitimate source:

  • Prefer aligned DKIM. Enable custom-domain signing in the vendor's settings, usually by publishing CNAME records at a selector.
  • Add SPF only where needed. If a vendor uses your domain as the envelope sender, add its include, watching the lookup count.
  • Move awkward senders to a subdomain if they cannot authenticate as your root domain.
  • Retire senders nobody owns.

Re-check reports after each fix. A fix is not done until reports from several receivers show aligned passes.

Stage 3: quarantine (2 to 4 weeks)

Move to quarantine:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Failing mail now goes to spam at receivers that honor the policy. This is your safety net stage: if you missed a legitimate source, its mail lands in junk rather than disappearing, and people tend to notice and complain before damage is serious.

What about pct?

Under the original DMARC specification (RFC 7489), the pct tag let you apply the policy to a percentage of failing mail, and a common pattern was ramping quarantine from pct=10 to pct=100. In May 2026 DMARC was republished on the standards track as RFC 9989, which removes pct. Receivers may continue to honor it for some time, but you should not design a new rollout around it. Use the stage durations, and a subdomain-first approach if you want a smaller blast radius, instead.

Subdomains as a gradual lever

The sp= tag sets policy for subdomains separately. Some teams enforce on subdomains first, where the sender list is short and well known, then on the organizational domain:

v=DMARC1; p=none; sp=reject; rua=mailto:[email protected]

Exit criteria: two or more weeks at quarantine with no reports of legitimate mail landing in spam due to DMARC, and aggregate reports showing only forwarders and spoofers failing.

Stage 4: reject

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Receivers that honor the policy now refuse failing mail at the SMTP stage. Spoofed messages using your exact domain stop reaching inboxes at those receivers.

Keep reading reports. New vendors appear, teams adopt new tools, and someone will eventually configure a system that sends as your domain without telling anyone. With p=reject, its mail will bounce, and the reports will show why.

Things that will fail and are fine

Expect some failures to remain at every stage:

  • Forwarded mail where the forwarder breaks SPF and modifies the message enough to break DKIM.
  • Mailing lists that alter subjects or add footers without rewriting the From header.
  • Spoofing attempts, which are the point.

You cannot fix these at your end. ARC and From-header rewriting by list software mitigate the first two.

Rollout checklist

  • SPF valid and under ten lookups; DKIM signing with your domain.
  • Report mailbox or processing service in place.
  • p=none for at least two to six weeks, covering monthly mail cycles.
  • Inventory of every legitimate source with an owner.
  • Aligned DKIM enabled for each vendor.
  • p=quarantine for two to four weeks with no legitimate breakage.
  • p=reject, with ongoing report monitoring.
  • A documented rollback: you can drop to quarantine or none in minutes if something important breaks.

Key takeaways

  • Stage the rollout: monitor, fix, quarantine, then reject, with explicit exit criteria for each stage.
  • Spend the most time on inventory and fixing vendors; the policy changes themselves are one-line edits.
  • Aligned DKIM is the most robust way to bring third-party senders into compliance.
  • pct was removed in RFC 9989; use stage durations and subdomain policies instead.
  • Reaching p=reject is not the end; keep reading aggregate reports.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

SharePost on XLinkedIn