What ARC header indicates the chain of authentication results?
Michael Ko
Co-founder & CEO, Suped
Published 23 Jan 2025
Updated 27 Sep 2025
8 min read
The Authenticated Received Chain (ARC) protocol is an essential component in modern email authentication, particularly when emails traverse multiple intermediaries. Without ARC, legitimate emails, especially those sent via mailing lists or forwarded services, often fail standard DMARC checks, leading to them being marked as spam or rejected. Understanding the specific headers that compose ARC is key to interpreting how an email's authentication status is preserved across hops.
Email forwarding, in particular, can break SPF and DKIM alignments, causing DMARC failures for otherwise legitimate mail. ARC provides a mechanism for intermediary mail servers to attest to the original authentication results before any modifications. This chain of custody ensures that the final recipient mail server can trust the message's history, even if direct SPF or DKIM checks fail upon arrival.
The core of ARC's functionality lies in its ability to encapsulate the original authentication results and digitally sign them. This creates a tamper-proof record that each subsequent intermediary can append to, building a trusted chain. When a receiving server processes an email with ARC headers, it can validate this chain to determine if the message was legitimately handled, even if its authentication status changed mid-journey.
The ARC-Authentication-Results header
The ARC-Authentication-Results header
The ARC header that specifically indicates the chain of authentication results is the ARC-Authentication-Results (AAR). This header is a crucial component of the ARC protocol, providing a snapshot of the authentication evaluation performed by an ARC-enabled intermediary before forwarding the message. Each intermediary that processes an email with ARC will add its own AAR header.
The ARC-Authentication-Results header contains an instance number ('i') and the results of SPF, DKIM, and DMARC validation at the point the ARC sealer (the intermediary server) processed the message. This means it records the immediate outcome of these checks before any further modifications or forwarding actions are taken that might alter the message headers or body, which could otherwise invalidate authentication for the next hop.
When an email passes through multiple ARC-enabled intermediaries, each one adds a new set of ARC headers, incrementing the instance number. The final receiving mail server can then examine the series of ARC-Authentication-Results headers (AARs) to reconstruct the authentication journey and confirm that the original message was authenticated at some point in the chain, even if direct DMARC alignment is now broken. This prevents legitimate emails from being incorrectly flagged as suspicious simply due to common forwarding practices.
Example of an ARC-Authentication-Results headertext
ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of sender@example.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=sender@example.com; dkim=pass (signature was verified) header.d=example.com; dmarc=pass (p=quarantine dis=none) header.from=example.com
Decoding the ARC chain
Decoding the ARC chain
Each ARC-enabled hop adds three distinct headers to an email: ARC-Authentication-Results, ARC-Seal, and ARC-Message-Signature. The AAR header, as discussed, carries the raw authentication results. The ARC-Message-Signature header (AMS) contains a cryptographic signature of the message's immutable parts and the AAR header. Finally, the ARC-Seal header (AS) signs the ARC-Message-Signature and other relevant headers, effectively sealing the authentication chain up to that point.
When a message arrives at the final destination, the receiver's mail server processes these headers in reverse order. It verifies the latest ARC-Seal, then the corresponding ARC-Message-Signature, and progressively works its way down the chain. This validation process confirms the integrity of each link in the chain, ensuring that the recorded authentication results were not tampered with. If all seals are valid, the receiver can trust the earliest authentication results in the chain.
The chain validation status itself is indicated by a field within the most recent ARC-Authentication-Results header. This field, usually cv=pass, signifies that the entire ARC chain has been successfully validated. For a deeper dive into this, you can learn more about what ARC header field indicates the chain validation status.
Understanding ARC chain components
ARC-Authentication-Results (AAR): Records the DMARC, SPF, and DKIM results at each hop.
ARC-Message-Signature (AMS): A cryptographic signature of the message content and AAR.
ARC-Seal (AS): Signs the previous AMS and other critical headers, sealing the chain.
The role of ARC-Seal and ARC-Message-Signature
The role of ARC-Seal and ARC-Message-Signature
While ARC-Authentication-Results provides the summary of authentication results, it's the ARC-Seal and ARC-Message-Signature headers that truly establish the chain of custody. The ARC-Message-Signature (AMS) contains a cryptographically signed copy of the message's state including the body and selected headers, essentially a snapshot. This signature ensures that any modifications to the message can be detected.
The ARC-Seal (AS) then acts as a further layer of security. It includes its own cryptographic signature, which covers the previous ARC-Message-Signature (AMS) and the ARC-Authentication-Results (AAR) header. This layered signing process creates an unbreakable cryptographic chain that verifies the authenticity of each intermediary's assessment. You can read more about the three main ARC header fields to understand their individual contributions.
Together, these headers form a robust mechanism to track and verify an email's authentication journey. When a receiving Mail Transfer Agent (MTA) gets an email, it looks for the presence of these headers. If they exist, it processes them to reconstruct the original authentication status. This is particularly valuable for scenarios like mailing lists, where the original sender's domain authentication might break due to the list server's actions.
Why ARC is crucial for DMARC
Why ARC is crucial for DMARC
ARC plays a critical role in the broader email authentication ecosystem, especially for DMARC. DMARC relies on SPF and DKIM to align with the email's visible From: domain. However, email forwarding or mailing list services often modify the message in ways that cause SPF or DKIM to fail, even for legitimate mail. Without ARC, these legitimate emails would likely be rejected or sent to spam due to a strict DMARC policy.
By providing a verified chain of authentication results, ARC allows recipient mail servers (like Gmail and Outlook) to differentiate between legitimate forwarded mail and malicious spoofing. This prevents false positives, improving email deliverability for senders who use intermediaries and ensuring that recipients receive the messages they expect. It effectively acts as an override for DMARC failures that occur solely due to forwarding.
Implementing ARC helps prevent legitimate emails from being incorrectly quarantined or rejected, which is critical for maintaining good sender reputation and effective communication. If you're encountering DMARC failures due to forwarding, understanding how to implement ARC and how it affects DMARC failures is essential. For comprehensive DMARC monitoring and insights, including how ARC impacts your email deliverability, Suped offers an intuitive platform that helps you visualize and manage your email authentication effectively.
DMARC without ARC
Increased false positives: Legitimate forwarded emails often fail DMARC.
Deliverability challenges: Emails sent through mailing lists or auto-responders face rejection.
Trust issues: Receiving servers have difficulty verifying message authenticity post-forwarding.
Improved deliverability: Mail sent via intermediaries reaches the inbox reliably.
Enhanced trust: A cryptographic chain verifies the message's original authentication.
Ensuring email integrity with ARC
Ensuring email integrity with ARC
In summary, the ARC-Authentication-Results (AAR) header is the specific component within the ARC protocol that explicitly indicates the chain of authentication results. It records the DMARC, SPF, and DKIM outcomes at each point an ARC sealer processes an email, creating a historical record. This record, combined with the cryptographic seals, ensures that the message's authenticity can be verified even after multiple forwarding steps.
For email administrators and marketers, understanding ARC is not just a technicality, but a necessity for robust email deliverability. As more email providers adopt stricter DMARC policies, ARC becomes an indispensable tool to prevent legitimate emails from being inadvertently blocked. It builds trust in the email ecosystem, allowing for complex email flows without compromising security.
Monitoring your DMARC reports is crucial to identify issues related to forwarding and ARC validation. Suped offers an industry-leading DMARC reporting and monitoring tool, with the most generous free plan available. Our platform provides AI-powered recommendations to help you fix issues and strengthen your policy, real-time alerts, and a unified view of DMARC, SPF, and DKIM. Whether you're an SMB, a large enterprise, or an MSP, Suped makes DMARC accessible and actionable.
Gmail and 
Outlook) to differentiate between legitimate forwarded mail and malicious spoofing. This prevents false positives, improving email deliverability for senders who use intermediaries and ensuring that recipients receive the messages they expect. It effectively acts as an override for DMARC failures that occur solely due to forwarding.
