Testing changes a request, not the authentication result
The t tag in current DMARC is a testing-mode signal attached to the policy record. It does not turn an unauthenticated message into an authenticated one, and it does not promise delivery. Its useful purpose is to soften the requested assessment for DMARC-failing mail while allowing relevant special handling. A deployment plan therefore needs two independent outputs: the expected policy interpretation and the receiver's actual behavior.
RFC 9989 section 4.7 defines t=y and t=n, with n as the default. Testing operates on whichever assessment policy was selected from p, sp or np. Begin by establishing that policy and whether DMARC failed. Do not apply a transformation to an arbitrary p tag when a subdomain override actually governs the message.
Build the six-cell expectation before sending anything
For a selected none policy, y and n both leave the requested assessment at none. For selected quarantine, y requests none while n retains quarantine. For selected reject, y requests quarantine while n retains reject. The none outcome still allows ordinary receiver filtering; it is not an instruction to bypass anti-abuse controls or a guarantee that the message will enter an inbox.
In a fictional test design, _dmarc.trial.north.example holds one alternative record at a time, each beginning v=DMARC1 and containing one selected p value plus one t value. The six alternatives form a matrix, not six simultaneous TXT policy records. Multiple policy records at the same candidate name are a different discovery problem and would invalidate the intended comparison. No records were published and no mail was sent for this article.
Retain a separate expected outcome for a DMARC-passing control message. Testing does not rewrite that result to fail or make a failed SPF result pass. Authentication, alignment, selected assessment and final disposition should occupy different fields in the evidence packet. Otherwise a screenshot saying “delivered” can obscure the very behavior the experiment was meant to establish.
Include special handling without relying on it
The testing definition allows relevant special handling, such as From-field rewriting by an intermediary, alongside the softer assessment. It says the assessment reduction applies irrespective of whether that special handling occurs. A test design must therefore observe both dimensions rather than making the reduced policy conditional on a visible rewrite.
RFC 9989 Appendix A.6 explains the history: inconsistent percentage handling led to removal of pct, while useful practices around pct=0 informed the new binary tag. That history does not make t=y a traffic-sampling percentage or a claim that all historic pct behavior is reproduced. The IANA registry now lists t as active and pct as historic. Registry entries cannot establish which software a receiving organization runs.
An intermediary may alter identifiers in ways that affect later alignment. Preserve the pre-intermediary and post-intermediary message evidence only within an approved, privacy-safe test. Do not infer the mechanism merely from a changed display name or a final folder. The report should identify the exact field changed, the hop where it changed and the authentication result seen downstream.
Final rejection still needs the receiver's wider analysis
A matrix cell labeled reject describes the requested assessment, not an automatic SMTP outcome. RFC 9989 section 7.4 requires receivers not to reject solely on the sending domain's reject policy. They must combine it with other analysis, and without that additional knowledge treat the failing message as quarantine instead. A test that ignores this distinction could wrongly call a conforming receiver defective.
The same section highlights forwarding and mailing-list interoperability risks. Domains publishing reject must not rely only on SPF to secure a DMARC pass and must apply valid DKIM signatures. Testing mode does not repair a broken signature or establish that every indirect route is safe. Include direct delivery and approved representative indirect paths when the actual deployment relies on them, rather than extrapolating from a single mailbox.
Scope the receiver claim to evidence you can retain
A published RFC is a normative reference, not a rollout announcement for every provider. An older implementation may ignore a tag it does not recognize, potentially leaving the declared quarantine or reject assessment unsoftened. That is a risk to evaluate, not a measured finding about a named receiver. Document current provider statements, actual software versions when available, and the specific observations supporting each compatibility conclusion.
A proposed authorized run should preserve the DNS policy snapshot and timing, exact record name, message identifiers, alignment inputs, receiver responses and any available reports. Record local-policy overrides separately. Repeat the six-cell comparison under controlled conditions rather than changing several sending variables at once. Include stop conditions for unexpected rejection and retain an approved rollback plan; this article does not authorize those operational actions.
Reporting also remains separate. The t tag itself does not change report generation. Aggregate requests use rua and the RFC 9990 reporting rules; failure feedback has its own conditions and receiver discretion. Missing feedback cannot prove that the testing tag was ignored, and feedback alone may not explain the receiver's complete final-disposition reasoning.
Leave the execution gate honestly open
The exact commission is: Test t=y and t=n with each policy and preserve the receiver results. This package contains the original six-cell expected matrix, prepared before drafting, but no receiver results. It therefore does not fulfil that execution requirement. The original-evidence gate remains visibly open rather than being replaced by a claim of compatibility based on the standards text.
Before release, a technical owner must approve the fixture, an operational owner must authorize any real tests, and a reviewer must reconcile observations with current specifications and receiver scope. Errata verification, specialist acceptance, production-route checks, visual review and publication permission remain pending. The defensible conclusion today is what the current tag asks a conforming implementation to do, together with the precise evidence still needed to rely on it.