Long-term email architecture should account for changing standards without treating a proposal as an installed capability. ARC was published as an experiment; newer work proposes ending that experiment and incorporating lessons into DKIM2. The immediate task is to inventory dependencies, preserve evidence of current behavior and define what would justify a future migration. A document title or draft publication is not an operational cutover instruction.
Pin the documents and their status
References: Source §3, Source §4.
This review retains RFC 8617, draft-ietf-dmarc-arc-to-historic-01 dated 21 October 2026, and draft-ietf-dkim-dkim2-spec-09 dated 1 November 2026. The two drafts are work in progress. The ARC draft requests reclassification of RFC 8617 as Historic; its request should not be reported as an already completed standards action on the strength of that draft alone. Per Datatracker, RFC 8617 remains Experimental and DKIM2 revision 09 is an active Internet-Draft. Recheck before making a later status assertion.
The ARC retirement proposal identifies a central limitation: cryptographic chain validation does not supply a universal trust framework for the intermediaries making assertions. Its operational analysis and guidance support reassessing new dependence on ARC. They do not prove that an existing receiving provider has stopped using ARC or that removing a trusted sealer is harmless.
Understand what DKIM2 proposes
References: Source §2, Source §9, Source §10.
The DKIM2 revision 09 draft describes signed message instances, information about intermediary changes, chained verification and replay-related protections. These are proposed mechanisms in the pinned revision, not a guarantee of deployed support or universal attack prevention. Implementers must assess the complete specification, related documents and subsequent revisions before claiming interoperability.
Separate four questions in the planning register: what the document specifies, what an implementation supports, what your deployment enables and what receiving systems actually use. A vendor roadmap answers neither the last question nor a retirement date. Record unknowns explicitly, including key management, transformation handling, coexistence, operational limits and the receiver's trust or reputation decisions.
Preserve a laboratory baseline
References: Source §6, Source §5.3.5.
The retained 7 November 2026 fixture provides a concrete current-protocol baseline. It signed a harmless message with DKIM and retained unchanged and footer-modified copies. This review reverified those retained signatures offline on 8 November 2026: the unchanged copy passes and the modified body fails. A bounded exact-domain model shows the resulting loss of aligned authentication. The retained messages and public key make the result inspectable.
No ARC signing, ARC-chain validation or DKIM2 implementation is exercised. The lab therefore establishes the transformation problem, not the proposed solution. For a future pilot, add a version-pinned implementation, known-answer tests, negative controls, interoperability partners and rollback criteria. Preserve both old and new outputs so that a change in draft syntax or semantics is visible rather than hidden by a generic pass label.
Make a reversible operating plan
Inventory current trusted sealers, list services, forwarding exceptions and important message modifications. Ask owners which flows depend on receiver-local ARC handling and retain observed examples where available. Continue to protect current DKIM signatures and reduce unnecessary transformations while the proposals mature. Do not weaken DMARC merely because a future protocol might improve forwarding.
Use decision gates rather than a speculative deadline: published status checked, supported implementation identified, controlled pilot completed, recipient compatibility measured and rollback approved. Review the register after a new draft, implementation release or provider announcement. A long-term plan is ready when its dependencies and evidence are clear; it is not ready simply because the organization has chosen a new acronym.