ARC: Preserving Authentication Through Forwarding
ARC (Authenticated Received Chain) solves a critical problem in email authentication: preserving verification results when messages pass through intermediaries like mailing lists and forwarding services.
The Forwarding Problem
Email authentication protocols like SPF and DKIM work well for direct email delivery, but they break down when messages are forwarded. This creates a significant challenge for legitimate email flows.
Why SPF Breaks on Forwarding
SPF validates the sending server's IP address. When a mailing list or forwarding service relays your message, it comes from their servers, not yours. The recipient's mail server sees an IP that isn't in your SPF record and fails the check.
DKIM can survive forwarding if the message isn't modified, but many intermediaries add footers, modify headers, or alter content, which breaks the DKIM signature. This means legitimate emails from mailing lists often fail authentication, even when the original sender had everything configured correctly.
What is ARC?
ARC (Authenticated Received Chain) is an email authentication protocol that preserves the original authentication results as messages pass through intermediaries. It creates a chain of custody that allows receiving mail servers to see what the authentication status was at each hop.
ARC doesn't replace SPF, DKIM, or DMARC. Instead, it supplements them by providing additional context that helps receiving servers make better decisions about forwarded messages.
How ARC Works
When an intermediary (like a mailing list) receives a message and forwards it, ARC captures and preserves the authentication state at that moment. Each intermediary in the chain adds its own ARC headers, creating a verifiable record of the message's journey.
The intermediary receives the message and evaluates SPF, DKIM, and DMARC as normal.
The intermediary adds three ARC headers recording the authentication results and signing the message.
The message continues to the next hop with the ARC chain intact, even if SPF now fails.
The receiving server validates the ARC chain and can trust the original authentication results if the chain is valid.
ARC Headers Explained
ARC adds three headers at each hop in the forwarding chain. Each set is numbered with an instance counter (i=1, i=2, etc.) to maintain order.
ARC-Authentication-Results (AAR)
Records the authentication results (SPF, DKIM, DMARC) as seen by this intermediary at the time it received the message.
ARC-Authentication-Results: i=1; mx.example.org;
dkim=pass header.d=sender.com;
spf=pass smtp.mailfrom=sender.com;
dmarc=pass header.from=sender.comARC-Message-Signature (AMS)
A DKIM-like signature over the message content and selected headers. This allows the next hop to verify the message wasn't tampered with after this intermediary processed it.
ARC-Message-Signature: i=1; a=rsa-sha256; d=example.org;
s=arc-selector; c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=base64hashofbody;
b=base64signatureARC-Seal (AS)
A signature over all previous ARC headers plus this instance's AAR and AMS. The seal ensures the entire chain is intact and hasn't been modified. It also includes a chain validation status (cv=).
ARC-Seal: i=1; a=rsa-sha256; d=example.org;
s=arc-selector; cv=none; t=1234567890;
b=base64signatureChain Validation (cv=): The cv parameter indicates the validation status of previous ARC sets. Values are "none" (first hop), "pass" (previous chain valid), or "fail" (previous chain invalid).
Who Uses ARC?
ARC is implemented by major email providers and services that frequently handle forwarded mail.
Google Groups, Mailman, LISTSERV, and other mailing list platforms add ARC headers when redistributing messages.
Services that forward email to other addresses (like university alumni forwarding) use ARC to preserve authentication.
Google both generates and validates ARC, using it to improve delivery decisions for forwarded messages.
Microsoft validates ARC chains and considers them when evaluating DMARC failures from forwarded mail.
Email security appliances and cloud gateways that process mail before delivery often implement ARC.
ARC and DMARC
ARC was specifically designed to address DMARC failures caused by legitimate forwarding. Here's how they work together:
The DMARC Override Process
- Receiving server checks SPF and DKIM (both may fail due to forwarding)
- DMARC evaluation fails because neither SPF nor DKIM passes with alignment
- Server checks for valid ARC chain from a trusted intermediary
- If ARC shows original authentication passed and the chain is valid, server may override DMARC failure
- Message is delivered instead of being quarantined or rejected
Trust is Key
Receiving servers decide which ARC signers to trust. A valid ARC chain from an untrusted source won't override DMARC. Major providers maintain lists of trusted ARC signers (like Google Groups, Microsoft, etc.).
For domain owners, ARC means you can enforce strict DMARC policies (p=reject) without worrying that legitimate forwarded mail will be lost. The combination of DMARC for direct mail and ARC for forwarded mail provides comprehensive protection.
Key Takeaways
- 1.ARC preserves authentication results when email is forwarded through intermediaries
- 2.Three headers (AAR, AMS, AS) create a chain of custody for each hop
- 3.Major providers like Google and Microsoft use ARC to improve delivery of forwarded mail
- 4.ARC helps DMARC work correctly with mailing lists and forwarding services
- 5.Trust relationships determine whether ARC overrides DMARC failures
Resources
Check Your Email Authentication
Use our scanner to verify your domain has SPF, DKIM, and DMARC configured correctly. Proper authentication is essential for ARC to work effectively.
Scan Your Domain