An ARC header is easy to overinterpret when a screenshot shows cv=pass or dmarc=pass. Those strings are evidence to parse, not instructions to accept the message. Start with the raw message and the receiving system's trusted evaluation, then distinguish the intermediary's statements from checks performed at the final boundary. A copied header excerpt alone cannot establish a valid chain.
Group fields by instance
References: RFC 8617 §4.2.1, RFC 8617 §5.2.
Locate ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal and group them by i=. Valid sets require the expected components and ordered instance structure. The first set uses cv=none, while later valid chain assertions use the appropriate continuation state. A missing component, duplicate set field or inconsistent numbering needs protocol validation, not manual repair of the received evidence. RFC 8617, sections 4 and 5.2, provides the rules.
RFC 8617 §5.2 limits the chain to 50 sets and requires exactly one AAR, AMS and seal in each continuous instance from 1 through N. Validation checks the most recent AMS and every seal; checking older AMS values is optional and does not itself determine chain validity. A failed chain is treated as no ARC chain for ARC processing, not as an automatic instruction to reject the message.
Preserve the original ordering and unfolded values for tooling while retaining original bytes for signature verification. Do not delete a confusing header from the evidence copy to make a parser succeed. If a tool reports malformed structure, retain that outcome and the version used rather than silently treating the nearest-looking fields as valid.
Label each claim's speaker
References: RFC 8617 §4.1, RFC 8601 §5.
For the AAR, identify the intermediary's authentication service and reported results. For the AMS and seal, identify d= and s= as signing-domain and selector inputs. A dmarc=pass in an earlier set describes that intermediary's evaluation context, not necessarily the final receiver's present result. A later cv=pass is itself a signed assertion whose validity must be evaluated.
Ordinary Authentication-Results headers also require a trust boundary. A sender can insert plausible-looking text before delivery. Use the final receiver's documented handling and trusted identifiers, not a substring search for the word pass. RFC 8601 describes the problem of accepting results from untrusted sources.
Work through the supplied illustration
References: RFC 8617 §5.2, RFC 8617 §7.2.1.
The private review package retains a non-validating ARC header illustration separately from signed test messages. The illustration groups one AAR, one AMS and one seal at instance 1. The signature fields explicitly say NOT-A-SIGNATURE and the body hash is illustrative. Its useful result is recognition of the field roles, not successful validation.
Then inspect the executable trust cases. A valid-chain input with an untrusted-sealer input remains ineligible for the example override. A trusted-sealer input with invalid-chain input does too. Only the combination of valid chain, trusted sealer and favorable prior assessment qualifies, and even that case can fail the toy content filter. These supplied booleans model decisions rather than verify ARC cryptography.
Turn parsing into an investigation
References: RFC 8617 §5.2, RFC 8601 §5.
For a real message, use a conforming verifier with the relevant DNS evidence and retain all reported failures. Ask the receiving provider which intermediary it trusted and how it used the assertion. If those details are unavailable, report the visibility gap rather than inventing a trust decision from delivery alone.
Keep a dated protocol-status note with the investigation. The checked IETF records still distinguish Experimental RFC 8617 from active proposed Historic reclassification. Current records should be rechecked before publication. The retained evidence includes locally received forwarding messages and a separately verified local ARC chain below. No external receiver or deployment acceptance is supplied.
Retained laboratory evidence
References: RFC 8617 §5.2.
The private review package retains arc-sealed-footer.eml as a genuinely signed one-set ARC fixture, separate from the placeholder illustration. dkimpy verifies its AMS and seal against the retained public key; arc-tampered.eml adds content after sealing and produces a message-signature failure while the seal itself still validates. observations.json preserves the distinction. The i=1 set contains the local forwarder's actual earlier authentication results. The separate local trust-decision function treats that lab domain as trusted only in its positive case. ARC signing and tampering are offline operations after the SMTP capture; these two ARC artifacts were not themselves sent through an external provider or claimed as additional SMTP deliveries.
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.