← RFC Reference

ARC — Authenticated Received Chain

Why This RFC Exists

Email forwarding is the Achilles' heel of SPF and DKIM. When a message is forwarded through a mailing list, an alias, or a .forward rule:

• SPF breaks because the forwarding server's IP is not authorized by the original sender's SPF record.
• DKIM breaks if the intermediary modifies the message (adding list footers, rewriting headers, changing encoding).

When both SPF and DKIM fail at the final destination, DMARC also fails, and the message may be rejected or quarantined — even though it was legitimately sent and forwarded through trusted infrastructure.

ARC (Authenticated Received Chain), defined in RFC 8617, solves this by having each intermediary record a snapshot of the authentication results it observed, then sign that snapshot. The final receiver can examine the chain to determine that the message was authenticated at the point of origin, even if direct SPF and DKIM checks now fail.

How It Works

The Three ARC Header Sets

Each intermediary that processes a message adds a set of three headers, numbered with an instance counter (i=) that increments at each hop:

Chain of Custody Example

Key Technical Details

The Chain Validation (cv) Tag

The ARC-Seal header includes a cv= (chain validation) tag with one of three values:

• cv=none — This is the first ARC set in the chain (i=1). There is no prior chain to validate.
• cv=pass — All previous ARC sets in the chain have been validated and their seals are intact.
• cv=fail — The chain is broken. A previous ARC set failed validation. Once the chain is marked fail, it cannot be repaired.

ARC and DMARC Override

ARC does not replace DMARC. Instead, it provides additional information that a receiver can use when making a DMARC override decision. The receiver's logic might be:

1. Check DMARC directly. If it passes, deliver normally.
2. If DMARC fails, check the ARC chain. If the chain is valid (cv=pass) and the receiver trusts the intermediaries in the chain, override the DMARC failure.
3. If the ARC chain is invalid or the intermediaries are untrusted, apply the DMARC policy as usual.

The decision to trust an intermediary is local policy. Gmail, for instance, maintains a list of trusted ARC signers (major mailing list providers, university mail systems, etc.).

Signing Requirements

ARC signatures use the same cryptographic format as DKIM (RSA-SHA256 or Ed25519). The signing domain publishes its ARC public key in DNS at a selector under _domainkey, identical to DKIM key publication:

Instance Numbering

ARC sets are numbered sequentially starting from i=1. Each intermediary adds a set with the next number. The final receiver validates the chain by checking all seals in order. If any seal fails or any instance is missing, the entire chain is invalid.

What ARC Does Not Do

• ARC does not authenticate the original sender directly — it records and conveys authentication results from earlier hops.
• ARC does not create trust in intermediaries — the receiver must independently decide which ARC signers to trust.
• ARC does not prevent message modification — it records what the authentication state was before modification occurred.

Common Mistakes

• Assuming ARC is universally honored: ARC is still Experimental (not Standards Track). While Gmail, Microsoft, and other major providers support it, not all receivers do. You should not rely on ARC alone for deliverability.
• Breaking the chain: If an intermediary that doesn't support ARC sits between two that do, the chain has a gap. The next ARC-aware hop will see missing instance numbers and mark the chain as failed.
• Not publishing ARC DNS keys: If you operate a mailing list or forwarding service and add ARC headers but don't publish the corresponding public key in DNS, verifiers cannot validate your ARC-Seal, breaking the chain.
• Confusing ARC with DKIM: While ARC reuses DKIM's signature format, they serve different purposes. DKIM authenticates the signing domain as responsible for the message. ARC records a chain of custody documenting authentication state at each hop.
• Ignoring ARC as a domain owner: Even though domain owners don't generate ARC headers, understanding ARC helps diagnose deliverability issues when messages pass through mailing lists or forwarding services.

Deliverability Impact

• Rescues forwarded mail: ARC's primary value is preventing legitimate mail from being rejected after forwarding. Mailing lists, university aliases, and corporate forwarding rules all benefit from ARC.
• Gmail's ARC trust: Gmail uses ARC to make DMARC override decisions. If a message fails DMARC but has a valid ARC chain from a trusted intermediary, Gmail may deliver the message to the inbox instead of rejecting it.
• Microsoft support: Microsoft 365 also evaluates ARC chains and uses them in its DMARC override logic, particularly for messages from trusted mailing lists.
• Enables stricter DMARC policies: Without ARC, moving from p=none to p=reject risks blocking legitimate forwarded mail. ARC mitigates this risk, making it safer for domain owners to adopt strong DMARC policies.
• Future-proofing: As more intermediaries adopt ARC, the email ecosystem becomes more resilient. Supporting ARC positions your infrastructure to benefit from an increasingly trusted forwarding chain.

Related RFCs