Replace the percentage promise with an explicit decision
A rollout plan that says “apply reject to ten percent of failing mail” needs review before it is reused under the updated DMARC specification. RFC 9989 removes the pct mechanism and defines a testing signal called t. This is a change in the available policy language, not evidence that every receiver has changed its software. The practical task is to identify what the existing plan was meant to protect, then compare that intention with current semantics and observed legacy behavior.
Do not translate a percentage into a testing value mechanically. A percentage plan tries to limit how much traffic receives a treatment. A testing signal changes the requested treatment and can trigger special handling. Those are different controls. Business owners should decide which legitimate routes must be represented in the comparison, what failure impact is acceptable and which evidence would permit the next policy change.
Understand what the current specification requests
RFC 9989 Appendix A.6 explains that historical pct behavior was inconsistent outside its endpoints and that pct=0 had acquired useful special-handling meanings. The updated mechanism preserves a testing concept rather than a general percentage selector. The record version remains v=DMARC1; there is no DNS switch to a version string called DMARC2.
Under section 4.7, t defaults to n. With t=y, the specified failing-message treatment is one level below the selected policy: reject becomes quarantine, and quarantine becomes none. A selected policy of none is unaffected. The signal can also prompt special handling by the evaluating actor, and it does not change generation of DMARC reports. These are specified semantics, not a guarantee of the final folder, rejection response or delivery outcome at every receiver.
Keep the selected p, sp or np policy in the assessment. Testing is not restricted to the policy string an operator happens to see first in a dashboard. The domain and discovery path determine which policy applies. A correct explanation of t cannot compensate for an investigation that checked a different domain from the actual message author.
Identify the mixed implementation risk
A receiver that does not recognize t may ignore it and continue using its supported policy logic. Conversely, an implementation of the updated specification does not gain a percentage rollout rule from an old pct value. A record containing both tags is therefore not a portable way to request one uniform experiment across all receivers.
Treat implementation status as a measured property of a named environment and configuration. A vendor announcement, report format or product logo alone does not prove how a particular message was processed. Where a receiver cannot be inspected, preserve the uncertainty and avoid attributing its final action solely to one tag. Receiver-local handling remains a separate stage under RFC 9989 section 5.4.
Review the old plan's hidden assumptions as well. Was the percentage meant to limit legitimate-mail loss, evaluate forwarding, estimate failure volume or test the reporting service? Each purpose needs different observations. Reducing treatment for all failing messages is not the same experiment as applying stronger treatment to a selected subset, even if both plans are described informally as gradual rollout.
Write acceptance criteria before changing DNS
Prepare a sender-by-sender comparison that includes low-volume and periodic legitimate routes. Retain the exact current record, proposed difference, applicable identities and representative message cases. Record the ordinary authentication and alignment results separately from selected policy, testing status, local overrides and final disposition. Define the conditions that stop the rollout, including missing coverage or unexplained legitimate-message failures.
Use aggregate evidence carefully. RFC 9990 section 3.3 explains that a reporting period can straddle policy changes and contain mixed observations. A day label on a report is not proof that one policy governed every counted message. Preserve the report period, observed policy and deployment timing rather than comparing two unlabeled percentages.
The proposed change should have an accountable owner and recoverable baseline. Removing pct from a legacy plan can remove a constraint that an older implementation was using. Adding t does not prove that constraint has been replaced there. A rollback also changes published state rather than instantly rewriting all cached observations, so the recovery evidence needs its own timing and scope.
Fictional worked example of a rejected translation
In this fictional review, Example Manufacturing has an old worksheet containing p=reject and pct=10. An editor proposes replacing the percentage with t=y and calling the result “the same ten-percent pilot.” The reviewer rejects that description: current testing semantics request quarantine for failing messages under a selected reject policy, rather than selecting ten percent for rejection.
The proposed matrix contains a current-semantics column, a legacy-implementation column and an observation column. The first can be filled from the specification; the other columns require identified implementations and authorized tests. They remain not run in this example. No DNS record was published, receiver queried or message delivered for the exercise.
The next decision is to agree on the actual experiment, such as testing specified handling while observing representative legitimate flows, instead of preserving an inaccurate label. The organization must then gather the evidence that supports that experiment before approving a production transition.
Keep the evidence gates visible
The exact original requirement remains open: Compare an old pct-based plan with current testing semantics and legacy/current receiver observations. The fictional worksheet supplies no deployed observations and cannot close that requirement. The commissioning gate also remains visible: Validate current primary specifications and retain a worked example before drafting. Primary text and a pre-draft fictional exercise were retained; implementation applicability, human SME approval and any operational release remain unresolved. No publication or policy change is authorized by this manuscript.