ARC (Authenticated Received Chain): RFC 8617 Intermediary Preservation & Protocol Mechanics

The Forwarding Problem ARC Solves

The standard email authentication stack (SPF, DKIM, and DMARC) was designed around direct sender-to-receiver transmission. However, millions of emails transit through intermediaries: university alumni forwarders, discussion mailing lists (Mailman, Sympa), and cloud security gateways (Proofpoint, Mimecast).

When an intermediary processes a message, direct authentication almost invariably breaks:

• SPF Breaks: The intermediary sends the message to the final destination from its own IP address. The destination MX evaluates SPF against the original domain, but observes the intermediary’s IP, triggering an SPF SoftFail or Fail.
• DKIM Breaks: If the intermediary alters the message body—such as appending a mailing list footer ("Click here to unsubscribe") or rewriting links for security analysis—the cryptographic body hash (bh=) invalidates, causing DKIM verification to fail.
• DMARC Fails: With both SPF and DKIM failing alignment, a domain publishing p=reject causes legitimate forwarded mail to be dropped or sent to spam.

Authenticated Received Chain (ARC) resolves this structural impasse by allowing intermediaries to act as trusted witnesses, recording the original authentication state and cryptographically sealing it into the header chain.

The Three ARC Headers Decoded (AAR, AMS, AS)

Every ARC-participating intermediary inspects inbound authentication, increments the instance counter (i=1, 2, ...), and prepends three coupled headers:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc2026;
  t=1730000000; b=gT8y...[Signature over previous ARC-Seals and AMS]...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.org; s=arc2026;
  h=from:to:subject:date:message-id; bh=47DEQpj8...; b=mX3a...[Signature over modified message body]...
ARC-Authentication-Results: i=1; mx.lists.example.org;
  dkim=pass (2048-bit key) header.d=original-sender.com header.s=s1;
  spf=pass (lists.example.org: domain of sender@original-sender.com designates 198.51.100.10);
  dmarc=pass (p=REJECT) header.from=original-sender.com

Chain Sequence & Validation Mechanics (i=1, i=2)

As an email passes through multiple intermediaries, each hop attaches a new triplet with an incremented instance index:

1. Hop 1 (Origin to List): Original sender transmits to marketing-list.org. The list verifies SPF/DKIM/DMARC as pass. It modifies the body (adds footer), signs i=1 with cv=none (indicating the start of the chain).
2. Hop 2 (List to Corporate Gateway): The email arrives at a security gateway. The gateway verifies the i=1 seal. It appends disclaimers and prepends an i=2 triplet with cv=pass.
3. Final Destination (Google / Microsoft 365): The receiving mailbox provider validates the entire mathematical chain from i=1 to i=N. If the chain is unbroken and the provider trusts the sealers, it honors the original dmarc=pass recorded in i=1, overriding the current SPF/DKIM failures.

cv= Validation Semantics (none, pass, fail)

The cv= (Chain Validation) tag inside the ARC-Seal informs downstream receivers of the chain’s integrity up to that point:

• cv=none: Reserved exclusively for the first ARC hop (i=1). Declares that no previous ARC chain existed.
• cv=pass: Indicates that all preceding ARC instances (1 through i-1) were successfully validated by this intermediary.
• cv=fail: The intermediary detected a broken seal or corrupted chain prior to signing. Subsequent receivers will reject ARC validation.

The Receiver Trust Model: Microsoft 365 & Gmail Sealed Lists

ARC does not mandate blind acceptance of recorded results. A malicious actor could easily forge an AAR header claiming dmarc=pass and seal it with their own domain. Therefore, ARC is fundamentally an identity and reputation assertion mechanism.

Major mailbox providers maintain internal reputation algorithms for ARC sealers. Furthermore, Microsoft 365 provides the Trusted ARC Sealers configuration portal in Exchange Online Protection (EOP), allowing administrators to explicitly whitelist trusted intermediaries (such as partner gateways or university forwarding systems).

Production Implementation: Milters, MTAs & Gateways

Operational Decision Framework: When Do You Need ARC?

• First-Party Originating Senders: Direct outbound senders (e.g., standard marketing or transactional senders) do not need to implement ARC sealing. Focus 100% of your resources on robust SPF and 2048-bit DKIM signing.
• Mailing List Operators & Security Gateways: If your infrastructure ingests third-party mail, modifies content, and re-injects messages toward external recipient MX servers, implementing ARC sealing is essential to preserve deliverability for your subscribers.