# ARC Authentication
Authenticated Received Chain (ARC) is an email authentication protocol that preserves the authentication status of messages as they pass through intermediaries that modify content, headers, or routing paths. Developed through RFC 8617 and maintained by the IETF, ARC addresses a fundamental problem: legitimate email messages fail DKIM and SPF authentication checks after being processed by mailing lists, forwarding services, security gateways, and other trusted intermediaries that modify messages during transit.
The protocol exists because email authentication was designed for direct sender-to-receiver communication, but modern email rarely follows this path. A message from a corporate sender to a recipient using a mailing list travels through the original mail server, the mailing list processor (which adds headers, modifies subject lines, and appends footers), and finally to the recipient's mail server. Each modification breaks DKIM signatures. The forwarding changes the apparent sending IP address, breaking SPF alignment. Without ARC, these legitimate messages fail DMARC evaluation and face rejection or quarantine.
ARC fits into the email authentication ecosystem alongside SPF, DKIM, and DMARC, but operates at a different layer. While SPF validates sending IP addresses and DKIM validates message integrity, ARC creates a chain of trust that documents authentication decisions made by each intermediary. This allows the final receiving server to evaluate not just the message's current state, but its authentication history throughout the delivery path.
The protocol assumes that certain intermediaries are trustworthy and can make reliable authentication decisions. This trust-based model differs from the cryptographic certainty of DKIM or the DNS-based validation of SPF. ARC's effectiveness depends entirely on the receiving organization's ability to identify and trust legitimate intermediaries while avoiding compromised or malicious ones.
ARC operates through a three-header system added by each trusted intermediary in the message delivery chain. Each intermediary that implements ARC signing adds one complete set of headers, numbered sequentially as the message progresses through the email infrastructure.
The first header, ARC-Authentication-Results, captures the authentication results observed by that intermediary at the time it processed the message. This header records SPF, DKIM, and DMARC results as they existed when the message arrived at that hop. For example, a mailing list server might record that DKIM passed and SPF passed when it received the message, even though subsequent modifications will break both authentication mechanisms.
The second header, ARC-Message-Signature, creates a cryptographic signature of the message as it exists at that point in the delivery chain. This signature uses DKIM-like cryptography but serves a different purpose. While DKIM validates that a message hasn't changed since the original sender signed it, ARC-Message-Signature validates that the message matches what the intermediary saw when it made its authentication decision.
The third header, ARC-Seal, signs the ARC header chain itself. This signature covers all previous ARC sets and the current ARC-Authentication-Results and ARC-Message-Signature headers. ARC-Seal prevents tampering with the authentication chain and ensures that the sequence of authentication decisions remains intact and verifiable.
Each set of ARC headers includes an instance value (i=1, i=2, etc.) that tracks the sequence of intermediaries. Consider a message that travels from the original sender through a security gateway and then a mailing list before reaching the final recipient:
The security gateway receives the message with passing DKIM and SPF. It adds ARC headers with i=1, recording the successful authentication results in ARC-Authentication-Results, signing the current message state in ARC-Message-Signature, and creating ARC-Seal to protect the header chain.
The mailing list server receives the message, observes that DKIM still passes but SPF may have failed due to the security gateway's IP address. It adds ARC headers with i=2, records these results, signs the message as modified by the security gateway, and seals the chain including both the i=1 and i=2 headers.
When the message reaches the final recipient, DKIM likely fails (due to mailing list modifications) and SPF fails (due to the mailing list's sending IP). However, the receiving server can validate the ARC chain by verifying each ARC-Seal signature and checking that the authentication results show the message passed validation at earlier hops.
The key to ARC validation lies in signature verification and trust evaluation. The receiving server must verify that each ARC-Seal signature is valid and created by the claimed intermediary. This requires maintaining a list of trusted ARC signers and their public keys, similar to DKIM key management but focused on intermediaries rather than original senders.
ARC also includes a chain validation result (cv=) that indicates whether the signing intermediary found the existing ARC chain valid. A cv=pass result means the intermediary successfully validated all previous ARC signatures. A cv=fail result indicates a broken chain, while cv=none means no previous ARC headers existed.
The protocol handles several edge cases through specific validation rules. If any ARC-Seal signature fails verification, the entire chain becomes invalid. If the sequence numbers skip values or repeat, validation fails. If an intermediary signs ARC headers but the receiving server doesn't trust that intermediary, the authentication benefit disappears.
Email authentication protocols work well for direct communication between senders and receivers, but modern email infrastructure relies heavily on intermediaries that modify messages during transit. Without ARC, organizations face a choice between accepting the security benefits of strict email authentication and maintaining the functionality of mailing lists, forwarding services, and content filtering systems.
The business impact extends beyond technical email delivery. Organizations running customer communication through mailing lists see legitimate messages rejected when recipients implement strict DMARC policies. Internal email forwarding breaks when employees set up forwarding rules to external accounts. Partner communications fail when messages pass through security gateways that modify content or headers.
These delivery failures create operational costs through increased support tickets, manual intervention requirements, and damaged communication relationships. Sales teams lose leads when prospect communications fail delivery. Customer service suffers when legitimate inquiries are quarantined. Marketing campaigns show reduced effectiveness when mailing list messages face rejection.
ARC provides a path forward that preserves both security and functionality. Organizations can maintain strict email authentication policies while accepting messages that show valid authentication provenance through trusted intermediaries. This reduces false positives in email security systems while maintaining protection against spoofing and phishing attacks.
However, ARC introduces new risks that organizations must understand and manage. The protocol's trust-based model creates dependency on intermediary security practices. A compromised mailing list server could forge ARC headers that make malicious messages appear legitimately authenticated. An attacker who gains control of a trusted intermediary gains the ability to bypass email authentication for messages processed through that system.
The trust management burden represents another significant consideration. Organizations must identify which intermediaries deserve ARC trust, monitor their security practices over time, and revoke trust when intermediaries become compromised or unreliable. This requires ongoing operational overhead that doesn't exist with sender-focused authentication protocols.
Common misconceptions about ARC include treating it as a replacement for existing email authentication rather than a complement, assuming that ARC signatures provide the same security guarantees as DKIM signatures, and failing to implement proper trust boundaries for ARC-signing intermediaries.
Within the Planetary Defense Model, ARC authentication falls under the Security Posture and Hygiene (SPH) domain as part of comprehensive email security configuration. SPH focuses on the ongoing maintenance of security configurations that protect against both external threats and internal vulnerabilities, and email authentication represents a critical component of this defensive posture.
CDA's Autonomous Posture Command methodology applies directly to ARC implementation through automated monitoring and adjustment of trust relationships. While conventional approaches treat ARC trust as a static configuration decision, CDA recognizes that intermediary trustworthiness changes over time based on security posture, compromise indicators, and operational behavior. APC systems continuously evaluate intermediary reputation and automatically adjust trust levels based on observed authentication patterns.
During C-HARDEN email missions, CDA operators assess ARC implementation as part of broader email security architecture. This evaluation includes not just whether ARC signing and validation are enabled, but whether trust relationships align with actual communication patterns and security requirements. Many organizations implement ARC trust too broadly, accepting signatures from intermediaries they don't actively use or can't properly monitor.
CDA differs from conventional ARC approaches by treating trust as a dynamic security control rather than a configuration setting. Traditional implementations establish ARC trust relationships and rarely revisit them. CDA operators continuously monitor authentication patterns to detect compromised intermediaries, evaluate new intermediaries before extending trust, and automatically revoke trust when security posture degrades.
The methodology emphasizes hygiene that never sleeps through automated validation of ARC chains against known good patterns. Rather than simply accepting or rejecting ARC-authenticated messages, CDA systems track authentication results over time to identify anomalies that might indicate compromised intermediaries or attack attempts that abuse ARC trust relationships.
ARC implementation represents a critical test of organizational security maturity. Organizations that can successfully implement and maintain ARC trust relationships demonstrate the operational capabilities needed for more advanced email security measures. Conversely, organizations that struggle with ARC trust management often reveal broader weaknesses in security configuration management and threat monitoring capabilities.
• ARC preserves email authentication results across trusted intermediaries that modify messages, solving legitimate delivery failures caused by mailing lists and forwarding services
• The protocol creates a cryptographic chain of authentication decisions through three headers (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal) added by each intermediary
• ARC effectiveness depends entirely on trust relationships with intermediaries, requiring ongoing evaluation of intermediary security posture and compromise indicators
• Organizations must balance the operational benefits of reduced false positives against the security risks of depending on intermediary trustworthiness
• Successful ARC implementation requires automated monitoring of authentication patterns to detect anomalies and maintain appropriate trust boundaries
• DKIM Message Authentication • SPF and Email Authentication Frameworks • DMARC Policy Implementation • Email Security Gateway Configuration • Autonomous Posture Command (APC): Hygiene That Never Sleeps
• Andersen, K., et al. "Authenticated Received Chain (ARC)." RFC 8617, Internet Engineering Task Force, July 2019.
• National Institute of Standards and Technology. "Trustworthy Email." NIST Special Publication 800-177 Rev. 1, September 2019.
• Crocker, D., et al. "DomainKeys Identified Mail (DKIM) Signatures." RFC 6376, Internet Engineering Task Force, September 2011.
• Kitterman, S. "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1." RFC 7208, Internet Engineering Task Force, April 2014.