Assess the updated specification, not a new version string
“DMARCbis readiness” is a useful project label only if it identifies the actual specifications and implementations being compared. RFC 9989 is the updated DMARC core specification published in May 2026. RFC 9990 separately specifies aggregate reporting. These are published standards-track RFCs, not a reason to invent a new DNS version value. The policy record still begins with v=DMARC1. RFC 9989, section 4.7 and RFC 9990, section 2.
An agent can prepare a standards-linked gap register and acceptance plan. It cannot infer that every receiver, reporting library or EmailAuth deployment implements the updated behavior. This article describes a proposed assessment, with no product inspection, DNS change or executed acceptance test.
Inventory the components that make the decision
List the sender’s Author Domains, policy records, sending identities, report destinations and relevant software versions. Identify which components discover policy, evaluate alignment, generate reports, parse reports and display findings. A dashboard may use a current label while an underlying library still follows legacy discovery behavior. Conversely, a receiver may implement newer evaluation without producing the exact reporting detail an analyst expects.
Give each component an owner and an evidence source. A vendor statement, a configuration export and a controlled acceptance result establish different things. Record what was actually inspected and what is merely claimed. Do not mark an entire organization ready because one parser accepts a new sample file or because one domain already publishes v=DMARC1.
Compare policy and domain-discovery behavior
RFC 9989 replaces Public Suffix List-based organizational-domain determination with the specified DNS Tree Walk, including Public Suffix Domain considerations. Its change summary explicitly notes that legacy and updated implementations can reach different results. A readiness plan should compare representative domain hierarchies, explicit author-domain policies and relevant subdomain cases under the intended implementations. RFC 9989, section 4.10 and Appendix C.3.
Do not reduce this to “the agent walks upward until it finds a record.” The algorithm has defined decisions and query bounds. The assessment should link each expected result to the relevant rule and preserve the actual DNS response context used by the test. Hypothetical domain trees can help design cases, but they are not evidence that a production receiver follows the same algorithm.
Reconcile tag changes without guessing receiver adoption
The updated core removes pct, rf and ri from its policy-record tag set and adds np, psd and t. The t tag carries testing semantics; it is not a replacement numeric percentage dial. An agent should flag legacy assumptions about partial enforcement rather than automatically translate a percentage into an unsupported new policy. RFC 9989, Appendix A.6 and C.5.
The fact that a tag changed in the specification does not prove a particular provider’s deployed interpretation. Where a provider document describes older behavior, retain its date and scope and request current applicability evidence. Do not rewrite a live record merely to make a compliance checklist appear modern. Any proposed tag change needs an impact assessment for the actual receiving population and a separately approved test or rollout.
Include operational policy considerations
Readiness is not synonymous with publishing p=reject everywhere. RFC 9989’s interoperability discussion addresses legitimate indirect flows, including general-purpose users participating in mailing lists, and describes receiver responsibilities beyond the published policy alone. Include those flows in the gap register instead of treating them as inconvenient failures to hide. RFC 9989, section 7.4 and Appendix C.6.
For a fictional organization, a receipts-only subdomain and an employee correspondence domain may need different acceptance cases and policy decisions. The assessment would identify both populations and the owners who can evaluate their tradeoffs. It would not assume that a result on the receipts stream proves the correspondence domain can adopt the same policy without operational consequences.
Assess reporting as a separate implementation dependency
RFC 9990 defines aggregate-report structure, identifiers, duplicate handling, policy-change reporting and external-destination verification. Test the report consumer’s supported format and behavior against appropriate fixtures, including malformed or duplicate inputs under a safe test plan. An XML parser that accepts one file is not proof that counts, identities and policy fields are interpreted correctly. RFC 9990, sections 3, 4 and 8.
Keep synthetic fixtures labeled. A fabricated aggregate report can test a parser but cannot establish real receiver behavior or delivery outcomes. External report routing also requires organizational approval for the destination, separate from the protocol’s technical authorization check. A readiness exercise should not silently redirect production reports or grant a new processor access to existing data.
Make every gap lead to a decision and a reproducible test
The proposed register should contain the requirement, standard section, affected component, observed behavior, expected behavior, uncertainty, owner and acceptance evidence. A gap may require a software update, a clarified provider commitment, an authorized configuration change or no action because the case does not apply. “Unknown” is preferable to an unsupported pass.
For consequential changes, keep preparation separate from execution and have the action path enforce scope and approval. OWASP’s authorization guidance emphasizes checking permission for each request; an agent’s overall project assignment should not substitute for authority over every tenant or DNS record. OWASP Authorization Cheat Sheet.
Require acceptance evidence before claiming readiness
Require a standards-linked gap register and reproducible acceptance results. This exact commissioning requirement remains open. The map below is a documentary register template. Current EmailAuth capabilities, receiver adoption, implementation versions, approved changes and reproducible results have not been established. Standards research defines what to examine; it does not certify deployment readiness.