ARC was designed to carry authentication assessments across intermediaries that can change a message. It adds evidence about earlier handling; it does not turn the intermediary into the original author or require the final receiver to accept the message. Read an ARC result as one input to a receiver decision, alongside current authentication and abuse controls.
Read the three components
References: RFC 8617 §4.1.1, RFC 8617 §4.1.2, RFC 8617 §4.1.3.
An ARC set contains ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal. The first carries an intermediary's assessment. The second signs message content in the ARC framework. The seal binds the ARC material into an ordered chain. Instance numbers connect the components belonging to each set. RFC 8617, sections 4 and 5, defines the structures and processing.
The reported earlier dmarc=pass is an assertion by an intermediary, not a fresh result computed by the final receiver. A valid seal establishes a cryptographic relationship with the signing domain under the validation rules. It does not establish that the domain is a reliable judge, that its systems were uncompromised or that its asserted earlier assessment was correct.
Follow a synthetic path
References: RFC 8617 §5.2, RFC 8617 §7.2.1.
Consider author.example sending to forwarder.example, which records an aligned pass before applying a footer. The final message may fail current DKIM because of the modification and fail aligned SPF because it arrives through the intermediary. ARC can carry the earlier assessment for a receiver that validates the chain and has a reason to rely on that intermediary.
The checkpoint includes a deliberately non-validating header illustration with i=1, the three field names and cv=none. Signature placeholders are visibly marked as not signatures. It must never be pasted into a message as if it were a working ARC set. The companion executable model supplies chain-validity and trust inputs and demonstrates that neither an untrusted valid chain nor a trusted invalid chain qualifies for its illustrative override.
Separate an override from a pass
References: RFC 8617 §7.2.1, RFC 8617 §9.3, RFC 9989 §7.4.
A receiver may use trustworthy earlier evidence when deciding disposition, but the locally observed DMARC result remains distinct. Record current authentication, chain validation, sealer trust and final handling independently. A message accepted through local policy should not be relabeled as having passed a different authentication mechanism.
The toy model also includes malicious content with otherwise favorable inputs. Its filtering decision still rejects that case. This is an original conservative policy example, not a normative ARC algorithm or a prediction of Gmail or Microsoft behavior. That first toy model performs no signing or verification. The retained laboratory below records actual ARC cryptography using controlled key lookup, without provider delivery.
Keep the standards status dated
The IETF Datatracker check on November 8, 2026 lists RFC 8617 as Experimental. Revision 01 of the proposal to reclassify ARC as Historic is an active Internet-Draft, dated October 21, 2026. Its proposal is not completed reclassification. Recheck both records before a deployment decision, and assess provider support separately. RFC status and reclassification work.
For an existing dependency, identify which trusted intermediaries and business flows actually rely on ARC before changing configuration. For a proposed dependency, document uncertainty and alternatives. The retained evidence includes a genuinely signed local header chain and a local trust-decision model below. External receiver deployment evidence remains unavailable.
Retained laboratory evidence
References: RFC 8617 §5.1, RFC 8617 §5.2.
The retained 7 November 2026 laboratory first verified the original author's actual DKIM signature and SPF inputs. It records those results at lab.forwarder.example, appends the footer and uses dkimpy to create a real one-set ARC chain with a temporary forwarder RSA key. dkimpy subsequently validates the seal and message signature. A post-seal appended paragraph causes ARC validation failure. The receiver decision code separately accepts or declines the valid chain's eligibility according to a configured trust flag. Complete signed and tampered messages plus validation details are retained. ARC signing and tampering occurred offline after the six-message SMTP capture; the trust flag drives a separate decision function, not a provider delivery result.
The retained runner and 7 November 2026 capture were inspected; no network experiment was rerun for this review. The original experiment used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.
The active Historic reclassification draft recommends against deploying or relying on ARC between disparate senders and receivers. This is a consequential proposal to consider when planning new dependencies, not completed retirement or proof that a current provider has disabled ARC. Retain a dated provider-specific dependency assessment while the standards process continues.