All tips
DMARC 5 min read

Moving from p=none to p=reject safely

Enforcement is a staged rollout driven by reports, not a flag you flip. Here is the sequence, and the signals that say you are ready for the next step.

The risk in DMARC enforcement is not technical. Publishing p=reject is a one-line DNS change that takes a minute. The risk is organisational: somewhere in the company, a system sends mail that nobody on the mail team knows about, and at p=reject that mail stops arriving.

The staged rollout exists to find those senders before they are rejected. Every step below is really about buying time to build a complete inventory.

The stages

  1. p=none for at least four weeks, with a rua address. Nothing changes about delivery; you are collecting the sender inventory.
  2. Fix everything the inventory surfaces. SPF entries for senders that are missing, aligned DKIM for vendors signing with their own domain.
  3. p=quarantine. Failing mail goes to spam rather than disappearing, so a mistake is recoverable by the recipient.
  4. Watch for two to four weeks. Investigate any new failing source immediately rather than waiting for the next review.
  5. p=reject. Keep reading reports, because the job does not end here.

Four weeks at p=none is a floor, not a target. The purpose is to catch infrequent senders, and some of them fire monthly or quarterly. If your business sends annual renewal notices, you will not see that system in a four-week window.

Signals you are ready to tighten

  • The share of aligned-passing volume is high and stable across several consecutive weeks, not just trending upward.
  • Every remaining failing source is identified, and is either not yours or is a forwarder whose loss you accept.
  • No new unexplained sources appeared in the most recent reporting period.
  • Somebody owns the rua mailbox and actually reads it. An unread reporting address means you will not notice when something breaks.

If you cannot say all four, you are not ready, and tightening anyway converts an unknown into an outage.

Quarantine is the load-bearing stage

It is tempting to treat quarantine as a formality on the way to reject. It is the opposite: it is the only stage where you get real enforcement behaviour with a recoverable failure mode. Mail that should not have failed lands in a spam folder, where a recipient can find it and tell you, rather than being refused at the SMTP transaction with nothing to retrieve.

Spend real time here. If a sender you missed exists, quarantine is where you want to discover it.

About pct=

RFC 7489 defines a pct tag that applies your policy to a percentage of failing mail, so you can ramp through pct=25, then 50, then 100. In principle this is a gentle way to expose a problem at low volume.

In practice, treat it as a comfort measure rather than a control. Support across receivers has always been uneven, the DMARCbis revision removes the tag, and a partial policy makes your reports harder to read because you cannot tell whether a source escaped enforcement or was simply not sampled. Quarantine at full percentage is the more predictable intermediate stage, and it is what most rollouts end up relying on anyway.

Do not forget subdomains

The sp tag inherits from p unless you set it explicitly, so tightening the parent domain tightens every subdomain that lacks its own record, at the same instant. If a subdomain is behind the parent in its rollout, give it either its own record or an explicit sp value before you tighten. Subdomains and sp= covers the inheritance rules.

Do not tighten during a product launch, a campaign send, or the week before a holiday. If something breaks you want the people who can fix it at their desks, and you want the failure to be noticed in hours rather than days.

Have a rollback ready

Before you tighten, know exactly how you would undo it. The change is a single DNS edit, so rollback is fast, provided two things are true: the record's TTL is short enough that reverting takes effect in minutes rather than hours, and someone who can edit DNS is reachable.

  1. Lower the TTL on the _dmarc record to five minutes, at least one full old-TTL period before you tighten.
  2. Tighten the policy, and watch for reports of missing mail as well as the reports themselves.
  3. If something legitimate is being rejected, revert to the previous policy first and diagnose afterwards. Do not debug with live mail bouncing.
  4. Once you have been stable for a couple of weeks, raise the TTL back to an hour or more.

Reverting is not a failure. It costs nothing, and it is how you avoid the far worse outcome of leaving a policy in place that is quietly rejecting invoices while you work out why.

After you reach reject

Enforcement is a state to maintain, not a milestone to pass. New vendors get onboarded, marketing signs up for platforms without asking, providers change their sending infrastructure. Any of those can start failing against a policy that is now rejecting rather than observing.

Keep reading aggregate reports after you tighten, and keep the rua mailbox owned. A monthly review is enough once things are stable. Check what a domain currently publishes with the DMARC tool.

Check your DMARC policy
dmarcrolloutoperations