ARC — Authenticated Received Chain

ARC is the gap competitor for the auth cluster. While SPF, DKIM, and DMARC handle direct sender-to-receiver authentication well, they all break in predictable ways when messages traverse intermediaries — mailing lists adding subject prefixes, account forwarders changing the envelope, security gateways rewriting headers. ARC is the experimental protocol that solves this by preserving the original authentication results across the forwarding path, allowing the final receiver to make informed trust decisions even when SPF and DKIM fail at the final hop.

Most published material on ARC falls into one of two camps: vendor-side guides explaining "ARC is the solution to forwarding problems" without operational depth, or RFC summaries that quote definitions without showing real headers. This entry synthesizes the operational reality: the actual three-header structure with annotated examples, the chain validation flow with cv= semantics, the implementation matrix across providers and MTAs, the IETF Experimental status controversy, and the honest decision framework about when senders need ARC and when they don't.

The forwarding problem ARC solves

SPF, DKIM, and DMARC were designed for direct delivery: sender → recipient. They break in predictable ways when messages traverse intermediaries. The most common failure scenarios:

In each case, the message itself is legitimate but the authentication signal at the final receiver is broken. Without ARC, the receiver sees an SPF/DKIM/DMARC failure and applies the sender's DMARC policy — quarantine or reject. The legitimate message gets blocked. With ARC, an intermediary can record "I saw this message authenticate cleanly before I modified it; here's the signed proof," letting the final receiver trust the original authentication despite the broken final-hop checks.

The three ARC headers (AAR + AMS + AS)

ARC adds three header fields per intermediary hop, called an "ARC set." Each has a specific role in the chain-of-custody mechanism:

Each ARC-aware intermediary that handles a message adds one complete ARC set (AAR + AMS + AS) with an incrementing instance number — first sealer adds i=1, second adds i=2, and so on. The final receiver validates the chain backwards from the highest instance number to verify each hop's signatures, and reads the original authentication results from the i=1 AAR (the first hop's record of the original SPF/DKIM/DMARC results before any modifications).

Real ARC headers in code

Here's an actual ARC set generated by Gmail when forwarding a message — abbreviated for readability but showing the real structure:

# Original message arrives at Gmail with valid SPF + DKIM + DMARC
# Gmail receives it, will forward to user's other mailbox
# Before forwarding, Gmail seals the original authentication into ARC

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@example.com header.s=20230601 header.b="abc123...";
       spf=pass (google.com: domain of sender@example.com designates 203.0.113.10 as permitted sender);
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
       d=google.com; s=arc-20160816;
       h=to:subject:message-id:date:from:mime-version:content-type:dkim-signature:arc-authentication-results;
       bh=ABCDEF1234567890...;
       b=Cryptographic-message-signature-here-base64-encoded...

ARC-Seal: i=1; a=rsa-sha256; t=1714843200; cv=none;
       d=google.com; s=arc-20160816;
       b=Cryptographic-seal-signature-here-base64-encoded...
       # cv=none because this is the first ARC set (no prior chain)

# Gmail then forwards the message to the user's destination mailbox
# If the destination is also ARC-aware (e.g., another Gmail account, Microsoft 365),
# it would add i=2 ARC set to the message preserving the chain

The same message after passing through a second ARC-aware intermediary (say Microsoft 365) would have:

# Second intermediary adds i=2 ARC set (prepended above i=1)

ARC-Authentication-Results: i=2; outlook.office365.com;
       dkim=fail (signature did not verify);            # DKIM broke after Gmail forwarding
       spf=fail (sender IP not in SPF);             # SPF broke (Gmail's IP, not original)
       dmarc=fail;
       arc=pass header.b="AbCdEf..." (i=1 chain validation passed)   # ARC chain still valid!

ARC-Message-Signature: i=2; a=rsa-sha256;
       d=outlook.com; s=arc-2024;
       # [...signature over current message + Gmail's ARC set...]

ARC-Seal: i=2; a=rsa-sha256; cv=pass;
       d=outlook.com; s=arc-2024;
       # cv=pass because the i=1 chain validated successfully

ARC-Authentication-Results: i=1; mx.google.com; ...    # Gmail's original AAR preserved
ARC-Message-Signature: i=1; ...                          # Gmail's original AMS preserved
ARC-Seal: i=1; ...                                     # Gmail's original AS preserved

The receiver evaluates the chain by validating each AS signature backwards from the highest instance number. If the entire chain validates, the receiver can trust the i=1 AAR — Gmail's record of the original SPF/DKIM/DMARC results — even though the final-hop SPF and DKIM failed.

Chain validation status (cv=)

The cv= tag in the most recent ARC-Seal header records the status of the previous chain. Three possible values:

The receiving MTA uses cv= to decide whether to trust the original authentication: cv=pass means the chain is valid and the original authentication results recorded in the i=1 AAR can be trusted; cv=fail or chain-validation-failure means the message can't benefit from ARC and falls back to standard SPF/DKIM/DMARC results — which by definition will fail because the chain failed for a reason.

ARC chain across a forwarding hop

Concrete example showing what happens at each step when a legitimate authenticated message gets forwarded through an ARC-aware intermediary:

Implementation matrix: who actually uses ARC

ARC's value depends on adoption — both at the sealer side (intermediaries that record original authentication) and the validator side (receivers that trust ARC chains). The 2026 state:

Microsoft 365: configuring Trusted ARC Sealers

Microsoft 365 verifies ARC chains by default but requires administrators to explicitly configure "Trusted ARC Sealers" to grant DMARC override authority. Without configuration, ARC chains are seen but not used for authentication decisions.

# Microsoft 365 Defender portal: configure Trusted ARC Sealers
# Email & Collaboration > Policies & Rules > Threat policies
#   > Email authentication settings > ARC tab

# Or via Exchange Online PowerShell:
Connect-ExchangeOnline

# View current trusted sealers
Get-ArcConfig

# Add a trusted sealer (e.g., Gmail)
Set-ArcConfig -Identity Default -ArcTrustedSealers "google.com"

# Add multiple trusted sealers
Set-ArcConfig -Identity Default -ArcTrustedSealers "google.com","fastmail.com","fabrikam.com"

# The d= value in ARC-Seal headers must match exactly
# Use Outlook View > Internet Headers or https://mha.azurewebsites.net to inspect

The Experimental status and the controversy

RFC 8617 was published as IETF Experimental status, not Standards Track. This is a specific designation per RFC 7841 meaning the protocol is published for examination, experimental implementation, and evaluation rather than widespread mandated deployment. The community had public review and IESG approved publication, but with explicit acknowledgment that ARC's effectiveness in real-world conditions wasn't fully proven.

The honest 2026 assessment:

• ARC is the best available solution for preserving authentication across forwarding — no alternative protocol with comparable deployment exists.
• ARC has substantial production deployment — Gmail, Microsoft 365 (with config), Yahoo, Fastmail, Sympa, Mailman all participate.
• ARC's security is reputational, not cryptographic — the chain proves what each intermediary asserted, not whether the assertion was true.
• ARC is an imperfect tool and the IETF community is exploring DKIMv2 or other approaches as longer-term replacements.
• For 2026 deployment decisions, ARC is the right answer; DKIMv2 isn't ready for production use.

Do I need to deploy ARC sealing?

ARC is for intermediaries — not regular senders. The decision framework:

For regular senders: focus on getting SPF, DKIM, and DMARC right. ARC is invisible infrastructure that helps your forwarded mail not fail at the recipient — you benefit from ARC without doing anything if your recipients use ARC-aware mail providers (Gmail, Microsoft 365). Your job is making the original authentication clean; ARC handles preservation downstream.

ARC in Cloud Server for Email infrastructure

Our managed email infrastructure handles ARC pragmatically based on customer architecture:

• Outbound senders (most CSE customers): no ARC sealing required. Focus is SPF, DKIM, DMARC enforcement, IP warming, sender reputation. ARC happens transparently at recipient ISPs that forward our customers' mail.
• Mailing list operators: ARC sealing via OpenARC milter or authentication_milter integration with Postfix-based list infrastructure. Mailman 3 + ARC for list-style deployments where preservation across the forwarding boundary matters.
• Email security gateways: ARC sealing essential when our gateway sits in front of customer mail server, modifying headers or body. Without ARC, downstream DMARC enforcement at recipient ISPs would block legitimate mail that traversed our gateway.
• Internal forwarding infrastructure: customer environments where mail traverses multiple internal MTAs before final delivery. ARC sealing at the boundary preserves authentication across the internal relay path.
• Microsoft 365 customers: configuration of Set-ArcConfig -ArcTrustedSealers for known forwarders in their environment — Mimecast, Proofpoint, internal compliance gateways, partner forwarding domains.
• Diagnostic and remediation: when customers report DMARC failures on legitimate forwarded mail, we analyze ARC chains in the message headers to identify which intermediary broke authentication and whether ARC is being correctly applied across the chain.

The pattern across customers: ARC is rarely the primary investment, but it's frequently the missing piece in incidents where legitimate mail is being blocked due to forwarding-induced DMARC failures.

Related glossary concepts

• SPF — breaks at forwarding boundaries because the IP changes. ARC preserves the original SPF result.
• DKIM — breaks when forwarders modify message body or headers. ARC preserves the original DKIM result.
• DMARC — fails when SPF and DKIM both break. ARC's chain validation lets receivers trust the original DMARC result despite final-hop failures.
• BIMI — requires DMARC at enforcement; ARC helps DMARC survive forwarding so BIMI logos still display for forwarded mail.
• MTA-STS — transport-layer authentication, parallel to but independent of ARC's content-layer authentication preservation.
• Postfix — common MTA for ARC sealing infrastructure via OpenARC milter or authentication_milter.
• SMTP — the protocol over which ARC headers are transported; ARC headers are part of the message DATA payload.

Frequently asked questions

Last updated: May 2026 · Sources: RFC 8617 (IETF Datatracker), arc-spec.org official, Wikipedia: Authenticated Received Chain, Microsoft: Configure trusted ARC sealers, Google: Best practices for forwarding email, Validity ARC explanation, Postmark ARC overview, OpenARC project, RFC 8601 Authentication-Results header.