Expert Tools

The Authenticated Received Chain (RFC 8617) lets a forwarder, such as a mailing list or a corporate relay, vouch that a message passed SPF, DKIM and DMARC when it first received it, so the next hop can trust that assessment even if the forwarder's own changes to the message break the original signatures. Each hop that participates adds an ARC Set: three header fields (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) sharing one instance number, cryptographically chained to every earlier one.

Why this needs a pasted message, not a domain

Every other check on this site looks up a DNS record for a domain you type in. ARC lives entirely in the headers of one specific message: there is nothing to look up without the message itself. Paste the full raw source, headers and body, exactly as your mail client shows it under an option usually called "Show original" or "View source".

pass, fail, or none

A Chain Validation Status of none means the message never carried an ARC Set at all, the ordinary state for most mail. fail means a chain was present but broke somewhere, structurally or cryptographically. pass means every set validated, all the way back to the first hop.

The trace information isn't independently checked

The ARC-Authentication-Results header records what a hop saw at the time, similar to an ordinary Authentication-Results header. RFC 8617 is explicit that its accuracy doesn't affect the chain's own validity, so it's shown here as trace information, not verified against anything.

A hop can be wrong without breaking the chain

The chain of custody (ARC-Seal) and an individual hop's own signed content (ARC-Message-Signature) are checked separately. If an older hop's message signature no longer validates, perhaps because its key rotated since, that alone doesn't fail the chain, since RFC 8617's own algorithm treats that as optional extra information ("oldest-pass"), reported here as a note rather than a failure.