Authenticated Received Chain (ARC) is an email authentication protocol designed to solve a common problem that plagues standards like SPF, DKIM, and DMARC: legitimate emails failing authentication after being forwarded. This often happens with mailing lists or forwarding rules. When an intermediary server relays a message, it can inadvertently break the original authentication.
For example, SPF checks fail because the forwarding server's IP address doesn't match the original sender's SPF record. DKIM signatures can fail if the forwarder modifies the email's content, such as by adding a footer. When these checks fail, DMARC also fails, potentially causing a perfectly valid email to be rejected or sent to spam. ARC creates a chain of custody, preserving the initial authentication results as the email travels through intermediaries.
The core components of ARC
ARC works by adding three new headers to an email message each time it is handled by a participating intermediary mail server. These headers work together to create a verifiable record of the message's journey and its authentication status at each step.
- ARC-Authentication-Results (AAR): This is the header we're focusing on. It captures a snapshot of the authentication results (SPF, DKIM, DMARC) as they were evaluated by the intermediary server.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that signs the message headers, including the AAR header just added. This ensures the authentication results haven't been tampered with.
- ARC-Seal (AS): This is the final header, which validates the integrity of the previous ARC headers (the AAR and AMS). It creates a chain, linking each intermediary's ARC headers together.
The specific role of the 'Authentication-Results' header
The ARC-Authentication-Results header is arguably the most important part of the entire process. Its primary job is to record and pass along the original authentication verdict. As Bento points out, this header is the central part of ARC because it contains the history.
When a mail server that supports ARC receives a message, it performs the standard SPF and DKIM checks. It then records these results in a new ARC-Authentication-Results header. This header includes an instance number (starting with i=1), the identifier of the server doing the check, and the results of the SPF, DKIM, and DMARC validation.
Here is a simplified example of what this header might look like:
ARC-Authentication-Results: i=1; mx.forwarder.com; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass
When the final recipient's mail server receives this message, the direct SPF and DKIM checks might fail. However, it can see the ARC-Authentication-Results header from mx.forwarder.com. After validating the ARC seal and signature to ensure the header is authentic, the server can see that the message originally passed DMARC. This allows the server to trust and deliver the message, overriding the current authentication failure.
Why this matters for email deliverability
Without ARC, legitimate mail streams that rely on intermediaries are at a high risk of being incorrectly marked as spam or rejected entirely. The ARC-Authentication-Results header acts as a trusted 'note' passed between servers. It preserves the vital context of the original authentication, providing a mechanism for receiving systems to make more intelligent and accurate delivery decisions.
In essence, the ARC-Authentication-Results header is the core of ARC's ability to maintain email trust. It logs the authentication history, and the other ARC headers simply exist to protect that log from tampering, ensuring its integrity throughout the message's journey to the final inbox.
What ARC header field indicates the chain validation status?
What is the ARC-Authentication-Results header used for?
What ARC header indicates the chain of authentication results?
What ARC header contains the list of signed header fields?
What is the 'arc-authenticated-results' header?
What is the 'ARC-Message-Signature' header used for?
