What pct actually does

pct looks like a dial for gradual enforcement. It is not one, and understanding why saves you from a rollout that produces unreadable evidence.

What it actually says

pct=50 asks receivers to apply the policy to 50% of messages that fail DMARC, and to fall back to the next weaker policy for the rest.

p=quarantine; pct=50    ->  50% quarantined, 50% treated as p=none
p=reject; pct=50        ->  50% rejected,    50% quarantined
p=reject; pct=0         ->  0% rejected,     all quarantined  (not "none")

RFC 7489 §6.6.4 specifies the fallback as one step down, not as no policy. p=reject; pct=0 is therefore not equivalent to p=none — it is equivalent to p=quarantine, which catches people who reach for it as a safe no-op.

Why it is a poor rollout tool

• The sample is per message, not per sender. A misconfigured sender does not get 50% blocked and 50% delivered in any way a user perceives as partial — it gets half its mail lost, at random, which is harder to diagnose than all of it being lost.
• Implementation varies. Some receivers round, some ignore the tag entirely, and some apply it before evaluating rather than after. You cannot predict the actual proportion at any given receiver.
• It does not reduce risk, it randomises it. The uncertainty about which senders break is unchanged; only the volume moves.
• Reports become harder to read. The disposition column now mixes policy-applied and sampled-out rows, so the evidence you need for the next step is noisier at exactly the point you are trying to make a decision.

What to do instead

Stage by population rather than by percentage. sp and np divide your estate along lines that correspond to real differences in readiness, and each step is a decision you can defend with evidence. Moving a subdomain to reject while the apex stays at none is a real reduction in exposure; rejecting a random half of everything is not.