Authenticated Received Chain (ARC, RFC 8617) preserves email authentication verdicts as messages traverse indirect mail flows, solving false-positive DMARC rejections caused by mailing lists and auto-forwarders.
The Forwarding Problem
Traditional email authentication relies on static validation boundaries that fracture whenever messages route through intermediate gateways. When an automated mailing list (such as GNU Mailman, LISTSERV, or Google Groups) receives a message, it rewrites the envelope sender and transmits from its own IP address. Because this relay IP is not listed in the originator's SPF record, SPF evaluation fails.
Simultaneously, if the mailing list modifies message headers, prefixes subject lines (e.g., [Engineering]), or injects mandatory unsubscribe footers into the MIME body, the cryptographic hash computed for DKIM breaks. Under a strict DMARC enforcement policy (p=reject), receiving MTAs are obligated to drop or quarantine the forwarded message despite it having originated from a legitimate sender. You can inspect how these authentication markers manifest in our breakdown of Email Headers Decoded.
Anatomy of the Three ARC Headers
RFC 8617 addresses this architectural flaw by creating an authenticated chain of custody. Each intermediate forwarding hop prepends three cryptographic headers:
- ARC-Authentication-Results (AAR): Captures the raw SPF, DKIM, and DMARC verification verdicts evaluated by the forwarder before modifying headers or message content (e.g.,
i=1; mx.google.com; dkim=pass [email protected]; spf=pass). - ARC-Message-Signature (AMS): Computes a cryptographic signature across message headers and the message body at the current forwarding hop, similar to a standard DKIM signature.
- ARC-Seal (AS): Cryptographically binds the preceding ARC signatures, sequence instance numbers (
i=1, 2, ...), and forwarder identities into a tamper-evident seal, guaranteeing that intermediate hops cannot forge earlier upstream verification verdicts.
When the message reaches its final destination, the receiving MTA verifies each sequential seal back to i=1. If the chain is unbroken and the forwarders are recognized as trustworthy, the receiver accepts the original AAR results, allowing the message to pass DMARC evaluation despite SPF and DKIM failures on the final network hop.
Practical Implications for Deliverability
ARC does not exempt senders from maintaining baseline authentication. Receiving MTAs at Google, Microsoft 365, and Yahoo evaluate ARC seals only when they explicitly trust the intermediate relays participating in the chain. Untrusted relays or broken ARC seals default directly to standard DMARC failure policies.
To preserve deliverability across forwarded traffic, senders must configure resilient SPF records with our SPF Generator and enforce valid DMARC tags via the DMARC Record Generator. Understanding indirect routing behaviors is critical when architecting outbound systems; explore our analysis on Email Forwarding Detection, and verify recipient addresses with MailVeri Verification Features to ensure destination addresses route cleanly through modern MTA pipelines.