Forwarding can break the authentication path that existed at first receipt
An intermediary can change the envelope sender, message body or headers while forwarding a message. Those changes can invalidate SPF or DKIM evidence that would have been available at the first receiver. ARC was designed to let participating intermediaries preserve authentication assessments and seal the chain so a later receiver has more context when evaluating a message that has passed through indirect mail flows.
An ARC instance is a three-part set
Each ARC instance uses an ARC-Authentication-Results field, an ARC-Message-Signature and an ARC-Seal with the same instance number. A useful parser groups these fields by i= value, checks whether instance numbers are contiguous and highlights incomplete sets. The presence of fields alone does not establish that the cryptographic chain validated; structural completeness and receiver-stamped arc=pass evidence are separate observations.
Read the chain from the earliest preserved assessment forward
The first ARC-Authentication-Results can show what an intermediary observed before later transformations. Subsequent instances add their own assessment while sealing the previous chain. Compare SPF, DKIM and DMARC results across instances to locate where authentication changed. A DKIM pass in an early instance followed by a final DKIM failure can be consistent with legitimate forwarding that modified signed content rather than proving spoofing.
cv values describe chain validation context
ARC-Seal includes a chain-validation value. The first instance uses its initial state, while later sealers indicate whether they considered the existing chain valid before extending it. A parser should expose these values and any gaps instead of collapsing the entire chain into one colored badge. The final receiver remains responsible for deciding how much weight to give ARC evidence in its own anti-abuse policy.
Combine ARC with the Received chain and current Authentication-Results
ARC is most useful when it is placed beside transit evidence. Received headers establish the sequence of relays, the final Authentication-Results shows what the destination observed, and ARC can preserve earlier authentication context from participating systems. When these three views agree on the order of events, an investigator can distinguish a normal forwarding transformation from an unexplained identity change much more reliably.
Do not treat ARC as a universal bypass for DMARC
ARC does not make a failing message automatically trustworthy and it does not replace SPF, DKIM or DMARC. Receivers may use a validated ARC chain as one input when handling indirect mail, but the message can still be malicious or incorrectly authenticated. Mailybox therefore reports complete ARC sets, observed chain-validation values and receiver-stamped ARC status separately rather than manufacturing a single “safe” verdict.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.