Ask what the proposed upgrade actually changes
A claim that a platform offers a DMARCbis upgrade should identify the current standard, the implementation behavior being changed and the evidence that the change works. It should not be accepted as a request to switch a DNS record to an invented DMARC version. The retained current RFC 9989 still specifies the case-sensitive version value DMARC1. A new standards document and a new implementation release are not the same thing as a new version token in the published policy.
This article proposes a standards-linked readiness review. It does not claim that EmailAuth implements RFC 9989 completely, that every receiver has adopted it or that an upgrade was performed. No DNS record, parser, receiver or production configuration was changed. The review should separate normative changes, supplier implementation claims and observed interoperability before anyone approves a rollout.
Reject the version-switch shortcut
RFC 9989's policy-record definition states that the version tag's only possible value is DMARC1 and that an otherwise different version value causes the record to be ignored under the specified processing. A proposal to publish v=DMARC2 is therefore not a standards-based migration instruction from this RFC. Ask the proposer to identify the exact section supporting any recommended record change rather than relying on a product label.
The same caution applies to renaming a dashboard setting. A setting called DMARCbis may enable a parser feature, a policy-discovery algorithm or reporting interpretation, but its meaning is product-specific until documented. Record the actual supported behavior, release version and limitations. Do not infer that toggling a setting updates external receivers, rewrites every record correctly or verifies all legitimate sending workflows.
Inventory the relevant standards changes
Use RFC 9989's change discussion and normative sections to build a focused checklist. One important area is DNS-based policy and organizational-domain discovery, including the DNS Tree Walk. That is an implementation behavior, not simply a new string to insert into an existing record. A supplier claiming support should explain which discovery and alignment cases it handles and provide scoped evidence for the actual product version.
Another explicit change is removal of the pct tag from the current specification. Appendix A.6 explains the history and introduces the testing tag t with values y and n, described as analogous in application to the former pct values 0 and 100. That does not justify a blanket mechanical replacement of every historical percentage value or a promise that every receiver implements the new behavior. Review the exact current semantics and the relevant deployment population before proposing a policy diff.
Keep protocol requirements separate from provider eligibility rules
A provider can publish product eligibility requirements that refer to existing deployment conventions. Those requirements need their own current source review and should not be silently rewritten because a protocol document changed. Conversely, a historical provider instruction does not redefine the normative content of RFC 9989. Record the apparent difference, the source dates and the implementation question that needs resolution instead of pretending the two layers are identical.
This manuscript does not claim universal receiver support for the testing tag, tree-walk behavior or any other revised feature. The readiness assessment must identify which components the organization controls and which are external. A sender can update its own implementation or policy only within the supported scope; it cannot force all receiving systems to upgrade. Compatibility conclusions therefore need demonstrated, bounded evidence rather than a global adoption assumption.
Separate reporting standards and parser readiness
RFC 9990 defines DMARC aggregate reporting as a separate specification. A platform's policy evaluator and report-ingestion parser may have different upgrade requirements. Ask which reporting formats, fields and validation behaviors are supported, and how older retained reports remain interpretable. Do not assume that changing a policy-discovery implementation automatically updates every reporting workflow or historical analysis.
Pin the product release and retained standards references used for the assessment. If a parser encounters an unsupported field or report variant, its behavior should be documented and tested rather than silently interpreted as zero activity. Preserve original report provenance and distinguish missing observations from authentication outcomes. No report parser was exercised for this article, and no test fixture is represented as an actual receiver report.
Build a standards-to-implementation matrix
Create one row per relevant requirement with RFC section, normative behavior, current product behavior, proposed change, affected component, evidence reference and unresolved limitation. Separate sender policy publication, receiver evaluation, organizational-domain discovery, report generation and report ingestion. A platform may perform only some of those roles, so unsupported roles should be marked out of scope rather than counted as implemented by implication.
Add representative cases for existing valid policies, invalid version values, discovery boundaries, alignment relationships and reporting compatibility where applicable. The exact fixtures should be designed by a qualified reviewer against the normative text and the product's supported role. This draft does not provide an implementation conformance suite or claim that a small set of examples proves complete compliance. Each observed result needs the input, product version and expected behavior retained.
Tie any record change to sender readiness
If the assessment proposes a DNS policy change, prepare an exact diff, ownership record, business approval, verification plan and rollback criteria. Keep legitimate sending workflows visible through a sender-by-sender readiness matrix. A standards upgrade does not prove that every supplier has aligned authentication or that every critical workflow will continue unaffected. Do not use a new implementation label as a reason to skip operational readiness.
Record what the change can and cannot demonstrate. Authoritative DNS evidence can show publication at a particular time; trusted received-message evidence can show a scoped authentication result; aggregate reports can show patterns within their retained coverage. None alone establishes universal interoperability. Rollback planning must account for cached state and external implementation differences, not just the ability to restore an old configuration file.
Fictional diagnosis: a requested DMARC2 record
A fictional supplier proposes an upgrade and tells a buyer to change the policy's version value to DMARC2. The buyer asks for the standards reference and finds that RFC 9989 still specifies DMARC1. The proposed version switch is rejected as unsupported, while the broader implementation review continues: the supplier may have legitimate changes to discovery or reporting behavior that need separate evidence.
The team would request a scoped readiness matrix and demonstrated results for the actual product release instead of accepting or rejecting the entire upgrade based on its marketing name. This is a fictional review exercise, not a real supplier instruction or an observed production defect. No record was published and no receiver was tested. The example shows how a precise standards question can separate a false shortcut from potentially useful implementation work.
Require demonstrated scope before calling the upgrade complete
A useful conclusion identifies the standards-linked changes implemented, the roles covered, the evidence retained and the external compatibility still unknown. It should not say that the organization now uses version two or that all receivers behave uniformly. The upgrade is an implementation and readiness assessment, not a universal switch.
The catalogue requires a standards-linked readiness assessment and demonstrated, scoped implementation results. Those original results remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft provides a review method and fictional example, not conformance evidence, a deployed migration or a claim of complete EmailAuth support.