Start with a behaviour, not a replacement record
A standards migration becomes manageable when each implementation decision has a named specification and an accountable owner. A DNS editor, an alignment engine and an aggregate-report parser do not perform the same job. Calling all three “DMARC support” conceals dependencies that matter when one component changes and another remains on an older implementation. The practical deliverable is a component-to-requirement map, with versions, interfaces and retained acceptance evidence, rather than a declaration that the whole estate has been upgraded.
The current document set was published in May 2026. RFC 9989 defines the core mechanism and obsoletes RFC 7489 and RFC 9091. RFC 9990 covers aggregate reporting; RFC 9991 covers failure reporting and also updates RFC 6591. Fresh RFC Editor records identify RFC 9989 and RFC 9990 as Proposed Standards. The published RFC 9991 text identifies its Standards Track category. These are published specifications, not unfinished drafts, but publication does not establish a particular receiver's implementation.
Give the core engine a precise contract
Assign record parsing, policy discovery, organizational-domain discovery and identifier alignment to RFC 9989 sections 4.7–4.10. The Author Domain comes from the message's RFC5322.From field. A discovered policy domain can differ from that Author Domain, and the organizational domain used for relaxed alignment is another explicit output. Losing those distinctions in an interface can make a correct parser feed an incorrect decision engine.
The DNS record still begins with v=DMARC1. “DMARCbis” is a name for the standards work, not permission to invent DMARC2. Current discovery uses bounded DNS tree walking rather than treating a historical public-suffix-list checklist as the whole algorithm. The psd, np and t tags require separate decision coverage. The IANA registry marks pct, rf and ri historic; it does not certify whether a deployed product ignores, interprets or exposes them.
Preserve distinctions between a normal DMARC failure, unavailable DNS information, an invalid policy and a receiver's final message disposition. RFC 9989 section 4.10.1 contains special handling for invalid policy tags when a syntactically valid aggregate-report URI remains. A simplistic “every malformed policy becomes none” rule would erase its conditions. Record the exact section beside the parser case that exercises it.
Treat aggregate feedback as its own implementation
Map the aggregate producer, XML validator, report consumer, duplicate handling and delivery integration to RFC 9990 sections 3–4 and Appendix A. The reporting interface needs the policy actually evaluated, authentication results, message counts and reporting-period context. A dashboard that displays XML is not evidence that the upstream receiver selected the correct policy or that every relevant sender appeared in the data.
External report destinations deserve their own component row. Destination authorization is a technical anti-abuse check, not consent to transmit arbitrary organizational data. Put report generation, destination verification and access/retention decisions under distinct acceptance criteria. RFC 9990 section 7 addresses privacy, while section 8 warns about malicious or false report content. Parser hardening and source trust therefore belong in the map alongside schema validity.
Do not reuse an aggregate parser for failure reports
Failure feedback is a different channel with different disclosure risks. RFC 9991 governs its generation and format, working with the referenced authentication-failure reporting specifications. The ruf request and fo conditions are not equivalent to rua aggregation. A receiver can decline failure reporting, and the absence of a failure report is not evidence that all messages passed.
A failure-report integration may encounter message headers or content that an aggregate pipeline is designed not to carry. Identify who may request it, where it can be sent, how incoming material is contained, and which privacy review applies. Never enable it merely to make a feature matrix look complete. Core participation requirements, optional failure reporting and a commercial product's advertised capabilities are different claims requiring different evidence.
Work through a fictional component inventory
Consider a fictional service with six modules: policy decoder, discovery resolver, alignment evaluator, aggregate builder, XML consumer and failure collector. The first three map to RFC 9989. The next two map primarily to RFC 9990. The collector maps primarily to RFC 9991. Shared storage and security controls inherit requirements from every reporting path they handle. This inventory is an original documentary example, not an assertion about EmailAuth's architecture.
For each module, retain its actual build identifier, relevant sections, input/output contract, owner and acceptance fixture. A fictional discovery fixture can pass a selected policy and its source domain into a fictional aggregate fixture; the reporting row should preserve that distinction rather than silently substituting the visible From domain. Then introduce a failure-report request and confirm that the design routes it to a separately authorized processing path. These are proposed checks, not completed executions.
Keep status, errata and deployment separate
The exact commission is: Map every implementation component to RFC 9989, 9990 or 9991 and check errata. Actual implementation coverage has not been supplied. Current errata retrieval failed and was stopped, so this draft cannot assert that the documents have no errata. RFC 9989's discussion of resolved RFC 7489 errata is historical context, not a fresh errata check for the three new documents.
Before release, the implementation owner must reconcile the actual inventory, the standards owner must resolve current errata, and the receiver-testing owner must preserve version-scoped interoperability evidence. Specialist review, production-route checks, visual acceptance and publication approval also remain open. The useful outcome today is a reviewable map that exposes missing evidence without turning an updated standard into an unsupported claim of universal deployment.