DMARC pct rollout done right (and where pct does not protect you)

dmarc

pct looks like a comfort knob.

Set p=quarantine; pct=10, wait a bit, then raise it to 25, 50, 100. On paper that sounds controlled and safe.

In production, it is useful but not magical. Some receivers treat pct as a hint, sampling details vary, and policy behavior is not guaranteed to be identical across mailbox providers. So the safest way to use pct is as one part of a rollout plan, not as the rollout plan itself.

If this is the first time seeing the DMARC tags in one place, keep DMARC record tag cookbook open in another tab and come back.

What pct actually does

pct tells receivers what percentage of DMARC-failing mail should get the policy action from p (or sp for subdomains).

Example:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

That means: "for about 25% of failing messages, apply quarantine; for the rest, behave more like monitoring."

Two details that often get missed:

  • pct does nothing for messages that already pass DMARC.
  • pct does nothing to fix alignment problems. It only changes enforcement share for failures.

So if a legitimate sender fails alignment, pct only reduces blast radius; it does not remove risk.

Why pct is not a universal safety net

This is the part teams discover the hard way.

Even with a low pct, bad outcomes can still happen if a critical sender is misconfigured. Sampling is not necessarily distributed the way you hope (for example by source, campaign, or business unit), and receiver behavior can differ.

Also, the mailbox where leadership notices issues first might belong to a provider that applies policy more aggressively than expected. So "it was only 10%" is not always comforting during an incident review.

Practical framing: use pct to smooth enforcement, but validate sender alignment as if pct=100 could matter tomorrow.

A rollout pattern that reduces risk in real environments

This pattern is intentionally conservative. It works well for mixed environments where mail is sent from multiple SaaS tools, on-prem relays, and one or two legacy apps.

  1. Keep p=none while building sender inventory from aggregate reports.
  2. Fix alignment for high-volume and high-risk senders first.
  3. Move to p=quarantine; pct=10 and hold long enough to observe a full business cycle.
  4. Increase in steps (25 -> 50 -> 100) only when reports stay boring.
  5. Move to p=reject after quarantine is stable, optionally repeating staged pct.

When "full business cycle" sounds vague, think payroll notices, monthly invoices, support workflows, and any automated system that only sends on certain days.

If you want the broader process context, A (sane) DMARC setup process for busy domains and DMARC setup stage 3 - test & adjust map closely to this approach.

Suggested records by phase

Start (monitoring):

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

First enforcement step:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

Mid rollout:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com

Full quarantine:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com

Final posture for many domains:

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

What to watch between each pct increase

Keep this checklist short and operational:

  • New unknown source IPs claiming example.com
  • Legitimate sources with SPF pass but DMARC fail (alignment issue)
  • DKIM pass rate drops after vendor-side changes
  • Spikes in failures tied to one sender or one region
  • Complaint/abuse desk reports that correlate with policy changes

If one step creates noise, freeze there. Do not keep increasing pct on calendar autopilot.

Provider guidance worth keeping handy

Behavior differs by ecosystem, so official sender guidance is still useful when triaging odd cases:

The mental model to keep

pct is a throttle, not a seatbelt.

It helps stage enforcement, but the real safety work is still sender discovery, SPF/DKIM alignment, and careful observation between changes. Teams that treat pct this way usually reach p=reject with fewer surprises and fewer emergency rollbacks.

Previous Post