Parse and visualize Authenticated Received Chain (ARC) headers per RFC 8617. Validate chain integrity, inspect each hop, and diagnose forwarding issues.
Authenticated Received Chain (ARC) is defined in RFC 8617. It preserves email authentication results across intermediaries like mailing lists, forwarding services, and security gateways that would otherwise break SPF, DKIM, or DMARC validation.
Each intermediary adds three headers forming a "hop": ARC-Authentication-Results (AAR) records authentication results at that point, ARC-Message-Signature (AMS) creates a DKIM-like signature over the message, and ARC-Seal (AS) signs the entire ARC chain so far. The cv= tag on each
seal indicates whether the chain was valid when that hop processed the
message.
| Header | Purpose | Key Tags |
|---|---|---|
ARC-Seal | Signs the chain of ARC headers, proving they were not tampered with. | i, cv, a, d, s, b |
ARC-Message-Signature | DKIM-like signature over the message body and selected headers. | i, a, c, d, s, h, bh, b |
ARC-Authentication-Results | Records SPF, DKIM, and DMARC results as seen by this intermediary. | i, then standard Authentication-Results fields |
| Value | Meaning |
|---|---|
none | First hop in the chain. No previous ARC sets to validate. |
pass | All previous ARC sets validated successfully. |
fail | Validation of previous ARC sets failed. The chain is broken and should not be trusted. |
ARC is critical for messages that pass through intermediaries: mailing lists that modify headers or the body, email forwarding services that change the envelope sender (breaking SPF), and security gateways that scan and re-sign messages. Without ARC, these legitimate forwarding scenarios often cause DMARC failures even though the original sender was fully authenticated.
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free