What Is ARC?

**ARC (Authenticated Received Chain) is an email authentication protocol designed to preserve and communicate the authentication status of messages as they pass through intermediary mail servers such as forwarding services, mailing lists, and gateways. ARC allows each intermediary to digitally sign the original message's authentication results, creating a cryptographic "chain of custody" that enables receiving servers to verify whether the original message passed SPF and DKIM checks before any intermediaries modified it. Defined in RFC 8617, ARC solves the fundamental problem that email forwarding breaks traditional DMARC protection.

How does ARC work?

ARC creates a verifiable chain of authentication results as email passes through multiple mail servers, preserving information that would otherwise be lost when intermediaries modify messages.

When an email is sent from the original sender's mail server with SPF and DKIM authentication intact, it travels to an intermediary server such as a mailing list, mail forwarding service, or email gateway. The intermediary server evaluates the original message's authentication status, checking the SPF, DKIM, and DMARC results that existed before the intermediary received the message.

The intermediary server then adds three ARC header fields to preserve this authentication information. The ARC-Authentication-Results (AAR) header records the SPF, DKIM, and DMARC validation results from the previous step, along with an instance number indicating the intermediary's position in the chain. The ARC-Message-Signature (AMS) header provides a DKIM-like signature over the entire message (except ARC-Seal headers), signed by the intermediary with its private key. The ARC-Seal (AS) header contains a DKIM-like signature over all previous ARC-Seal headers and the current AAR and AMS headers, also signed by the intermediary.

Each set of ARC headers includes an instance number (i=1 for the first intermediary, i=2 for the second, etc.), allowing receiving servers to reconstruct the sequence of intermediaries that handled the message.

After adding ARC headers, the intermediary may modify the message content or headers—adding unsubscribe links, injecting virus scanning notices, appending mailing list footers, or making other changes that would normally break DKIM signatures. The modified message is then forwarded with the ARC chain preserved, documenting that the original message passed authentication before modification.

When the receiving mail server processes the email, it retrieves each intermediary's public key from DNS and validates each ARC-Seal signature in the chain. The receiver starts with the first ARC set (i=1) and validates the seal, then proceeds through each subsequent set in order. If all seals validate correctly and the chain shows the original message passed SPF and DKIM, the receiving server can accept the email despite the intermediary's modifications breaking traditional DKIM.

If multiple intermediaries handle the message, each adds its own ARC headers with incrementing instance numbers, creating a complete chain of authentication results from the original sender through all intermediaries to the final recipient.

How does ARC differ from traditional email authentication?

Why does ARC matter?

ARC addresses a fundamental limitation of email authentication: forwarding breaks verification. Traditional DMARC protection fails when legitimate email passes through intermediary servers, creating a tension between security and functionality that ARC resolves.

As of February 2024, Google Gmail added ARC to its email sender requirements for bulk senders (5,000+ emails/day). This mandate reflects recognition that email forwarding is common in business communications, and authentication systems must accommodate legitimate forwarding while still detecting spoofing.

Organizations that operate mailing lists, email forwarding services, or shared mailboxes face particular challenges with DMARC enforcement. When a mailing list receives an email from example.com and forwards it to subscribers, the mailing list server becomes the new sender. SPF checks fail because the list server's IP isn't in example.com's SPF record. If the list adds a footer or modifies headers, DKIM verification fails. Without ARC, the message fails DMARC alignment and may be rejected despite being legitimate.

ARC enables these intermediaries to prove they received an authenticated message before modifying and forwarding it. The receiving server can validate the ARC chain and understand that while the current DKIM signature may be broken, the original message passed authentication before the legitimate intermediary modified it.

Major email service providers supporting ARC include Gmail, Outlook, Zoho, Fastmail, and Pobox. Microsoft Exchange and Google Workspace have integrated ARC support, allowing organizations using these platforms to benefit from ARC validation without additional configuration.

However, adoption remains limited compared to SPF, DKIM, and DMARC. In a November 2021 message analysis, 88.7% of messages contained DKIM keys while only 13.4% contained ARC keys, indicating a significant adoption gap. This disparity means many forwarded messages still fail DMARC even though ARC could preserve their authentication status.

What are the limitations of ARC?

Low overall adoption limits effectiveness. Only 13.4% of messages contained ARC keys as of 2021 analysis, compared to 88.7% containing DKIM keys. This adoption gap means most email forwarding scenarios still break DMARC authentication because intermediaries haven't implemented ARC signing. Until adoption increases substantially, ARC provides limited value across the broader email ecosystem.

Not all email providers validate ARC chains. Even when intermediaries properly implement ARC, receiving mail servers may ignore ARC headers if they haven't implemented validation. This creates scenarios where intermediaries invest in ARC deployment but receiving servers don't use the authentication chain information, rendering the implementation ineffective.

Implementation requires technical expertise. Properly deploying ARC requires generating cryptographic keys, publishing them in DNS, configuring mail servers to add ARC headers correctly, and managing key rotation. Smaller organizations operating mailing lists or forwarding services may struggle with the technical complexity, particularly without vendor support or clear implementation guides.

ARC only preserves authentication status, not broken signatures. ARC documents that the original message passed authentication before intermediary modification, but it doesn't restore or repair the broken DKIM signatures. Receiving servers must be configured to trust ARC chains instead of requiring current DKIM validation, creating deployment dependencies.

RFC 8617 marked as "Experimental" limits adoption obligations. Unlike SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) which have Standards status, ARC is specified in RFC 8617 marked as "Experimental." This designation may reduce urgency for adoption and create hesitation among organizations concerned about implementing non-Standard protocols.

Privacy concerns from routing exposure. ARC headers expose information about email routing paths and the intermediaries that handled messages. This could reveal organizational email infrastructure details or relationships between senders and intermediaries that some organizations prefer to keep private.

Complex deployment for multiple intermediaries. Organizations with multiple forwarding intermediaries requiring coordinated key management face significant complexity. Each intermediary needs its own key pair, DNS publication, and proper ARC configuration. Coordinating these deployments across multiple teams or vendors creates project management challenges.

How can organizations implement ARC effectively?

For email senders, ensure SPF, DKIM, and DMARC are properly configured as the foundational authentication framework before considering ARC. ARC preserves existing authentication results, but it cannot create authentication where none exists. Organizations must have working SPF and DKIM before ARC provides any benefit.

For intermediaries operating mailing lists, email forwarding services, or gateways, implement ARC signing to preserve authentication status when modifying and forwarding messages. Configure intermediary mail servers to evaluate incoming email authentication results, generate the three required ARC headers (AAR, AMS, AS) with proper instance numbering, and sign the headers with the intermediary's private key.

Publish public keys for intermediaries in DNS using the standard DKIM key format (selector._domainkey.intermediarydomain.com). This allows receiving servers to retrieve the public key and validate ARC-Seal signatures in the chain.

Implement ARC validation on receiving mail servers to trust forwarded messages with valid ARC chains. Configure the mail server to retrieve intermediary public keys from DNS, validate each ARC-Seal signature in sequence, and accept messages that show original authentication success even if current DKIM is broken.

Configure DMARC policies to allow ARC-authenticated forwarding through trusted intermediaries. Some DMARC implementations include options to trust ARC chains from specific intermediaries or to reduce enforcement severity for messages with valid ARC chains.

Monitor ARC chain validation results to identify broken forwarding chains or intermediaries that aren't properly implementing ARC. Validation failures may indicate misconfiguration, key rotation issues, or attempts to forge ARC chains.

Implement key rotation procedures for intermediary servers generating ARC signatures. Like DKIM keys, ARC signing keys should be rotated periodically (every 1-3 years) to limit the impact of potential key compromise. Use selectors to enable rotation without breaking existing ARC chains.

Use trusted forwarding services that implement ARC natively rather than building custom forwarding infrastructure. Major email service providers and enterprise mailing list platforms increasingly include ARC support, reducing the implementation burden.

Combine ARC with DMARC enforcement policies to enable intelligent message filtering based on ARC validation. This allows organizations to maintain strict p=reject policies while still accepting legitimate forwarded email that shows valid ARC chains.