ARC: keeping trust in an email as it crosses intermediaries

In a nutshell: ARC (Authenticated Received Chain) is a standard that lets relays (mailing lists, anti-spam gateways, forwarders, etc.) preserve and seal the authentication results (SPF, DKIM, DMARC) they observed. The recipient can then make an informed decision to trust the message even if SPF/DKIM legitimately fail after a modification or forward.

Why do we need ARC?

Without ARC, a legitimate message can be rejected after being forwarded:

• SPF fails because the sending IP becomes the relay's IP;
• the original DKIM signature can break if the relay tweaks headers or body (banner, footer, anti-spam tagging);
• therefore DMARC fails on the receiving side, even though the email was valid at the source.

ARC lets the relay state: “I received a message that passed SPF/DKIM/DMARC; here are my results and I’m signing them.”
The final server reviews the chain of seals to decide whether the email remains trustworthy.

How ARC works (overview)

At every relay, three ARC headers are appended, with an index i=1, i=2, …:

1. ARC-Authentication-Results (AAR) — copies the SPF/DKIM/DMARC results as seen by the relay.
2. ARC-Message-Signature (AMS) — cryptographic signature of the message as observed by the relay (analogous to DKIM).
3. ARC-Seal (AS) — a seal that signs the whole package (AAR + AMS + previous seals) to chain the trust.

Example ARC headers (simplified)

ARC-Seal: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org; dmarc=pass header.from=example.org

• i=: position in the chain (1 at the first relay, then +1 at each hop).
• d= / s=: domain and selector (like DKIM) used to publish the DNS public key.
• cv= (in ARC-Seal): Chain Validation declared by the relay for the chain it sees; usual values are none, pass, fail.
• h=, bh=, b=: standard signature fields (list of headers signed, body hash, signature blob).

“I see ARC headers even without forwarding—is that normal?”

Yes. Major providers (webmail, collaboration suites, security gateways) often sign inbound traffic with ARC by default.
Goals: set an internal point of truth, trace the message’s path inside their infrastructure, and ease any later forwarding without losing trust.

How does the recipient evaluate the ARC chain?

1. Verify every ARC-Message-Signature and ARC-Seal, starting from the highest i.
2. Check continuity: no i gaps; each seal must cover the previous ones.
3. Inspect cv= in the last ARC-Seal (the signer’s declared view of the chain).
4. Cross-check with DMARC: if the current SPF/DKIM fail, decide whether to trust the recorded results in trusted ARC-Authentication-Results.

Important: ARC does not force acceptance of a message; it provides verifiable context so the recipient can decide more precisely.

Best practices (operator side)

• Sign and validate ARC on your relays (lists, aliases, security gateways).
• Keep existing ARC headers; do not strip valid seals.
• Manage your keys (rotation, DNS TTL, monitoring signature failures).
• Limit message changes once sealed (banners, rewrites) or re-seal after modification.
• Log DMARC decisions influenced by ARC to measure impact.

Common pitfalls

• Adding an ARC-Authentication-Results without an ARC-Message-Signature and ARC-Seal.
• Breaking the chain (duplicate/missing i, seal not covering the prior entries).
• Blindly trusting any unknown d= domain. The signer’s reputation matters.

Frequently asked questions

Does ARC replace DKIM/DMARC?
No. It complements SPF/DKIM/DMARC by preserving the results observed by relays.

Who can add ARC?
Any transport intermediary (MTA, gateway, email service) that handles the message.

What does cv= actually mean?
It’s the signer’s statement about the state of the chain it sees: none (no prior chain), pass (coherent and verifiable), fail (invalid chain). The recipient still performs its own validation.

Why does the same message have multiple i= values?
Each relay increments i and adds its own AAR/AMS/AS triplet.

Learn more

• IETF - RFC 8617: Authenticated Received Chain (ARC) : https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8601 - Authentication-Results Header Field (context for AAR): https://datatracker.ietf.org/doc/html/rfc8601

---

Cheat sheet

• Purpose: preserve and seal SPF/DKIM/DMARC results across relays.
• 3 headers: ARC-Authentication-Results (results) + ARC-Message-Signature (message signature) + ARC-Seal (chain seal).
• Recipient decision: valid signatures + signer reputation + internal DMARC policy.