When an email is forwarded or sent through a mailing list, traditional email authentication methods like SPF and DKIM can often break. This happens because the email's journey is altered, which can cause the final recipient's server to see a mismatch between the sending server and the original domain's authentication records. This can lead to legitimate emails failing DMARC checks and landing in spam or being rejected entirely.
To solve this problem, a protocol called Authenticated Received Chain (ARC) was developed. ARC creates a verifiable chain of custody for an email as it passes through different servers.
At the heart of this system is the ARC-Authentication-Results header. This header's primary job is to capture and preserve the original email authentication results (SPF, DKIM, and DMARC) before the email is forwarded. Think of it as a snapshot of the email's authentication status at the moment it was received by an intermediary server.
How ARC creates a chain of trust
When a server that supports ARC (like a mailing list provider) receives an email, it first performs the standard SPF and DKIM checks. It then adds a set of ARC headers to the email before forwarding it. This set includes three key parts:
- ARC-Authentication-Results: As we've discussed, this header contains a copy of the original authentication results. According to VAND3RLINDEN, it holds the results for SPF, DKIM, and DMARC. It also includes an instance number (e.g., i=1) to indicate its place in the chain.
- ARC-Message-Signature: This is a DKIM-like signature that covers the entire message content, including the headers, except for the ARC-Seal header.
- ARC-Seal: This is another DKIM-like signature that validates the integrity of the previous ARC headers (ARC-Authentication-Results and ARC-Message-Signature). It effectively 'seals' the ARC information for that specific hop.
If an email passes through multiple forwarders, each one adds its own set of these three headers, creating a chain. The instance number (i) increments with each hop (i=1, i=2, and so on).
An example of the ARC-Authentication-Results header
A typical ARC-Authentication-Results header might look something like this:
ARC-Authentication-Results: i=1; mx.forwarder.com; spf=pass smtp.mailfrom=originalsender.com; dkim=pass (signature was verified) header.d=originalsender.com; dmarc=pass
Here, i=1 indicates this is the first hop in the chain. The header clearly states that the forwarding server (mx.forwarder.com) received an email from originalsender.com which passed SPF, DKIM, and DMARC.
Why this matters for email deliverability
When the final recipient's mail server receives the forwarded message, the direct SPF and DKIM checks will likely fail. However, instead of immediately marking the email as suspicious, the server can check for an ARC chain.
The server validates the ARC-Seal for each hop, starting with the most recent, to ensure the chain is unbroken and hasn't been tampered with. If the chain is valid, the server can trust the results stored in the first ARC-Authentication-Results header. This tells the server that the email was authentic when it started its journey.
By preserving the initial authentication verdict, the ARC-Authentication-Results header allows receiving systems to make better-informed decisions about emails that would otherwise fail DMARC. This significantly improves the deliverability of legitimate messages sent via mailing lists and forwarders, ensuring they reach the intended inbox.
