How ARC Works: The Enterprise Guide to Authenticated Received Chain (RFC 8617) with SPF, DKIM & DMARC

As enterprise email systems enforce strict DMARC p=reject policies across Microsoft 365, Google Workspace, and major enterprise security gateways, a long-standing architectural challenge has reached critical priority: indirect mail flow.

When an email passes through intermediate systems—such as mailing lists, CRM relays, helpdesk ticketing platforms, or multi-tenant email security gateways (e.g., Proofpoint, Mimecast, Cisco CES)—the message headers and body are frequently modified. This breaks SPF (due to relay IP mismatch) and DKIM (due to footer additions or body modification), causing the receiving mail server to fail DMARC and bounce legitimate emails.

Authenticated Received Chain (ARC), defined in RFC 8617, provides the cryptographic chain of custody needed to solve this problem. In this guide, we dive into how ARC works under the hood, why DMARC needs it, and how modern MTAs evaluate ARC seals.

The Core Problem: Why Indirect Mail Flow Breaks DMARC

Under standard DMARC evaluation, a message passes authentication if either SPF or DKIM passes with domain alignment against the RFC 5322 From: header domain.

Why SRS Only Solves Half the Problem

1. SRS does not fix DKIM if the body or subject was modified.
2. DMARC requires SPF to align with the 5322.From (header sender), not the envelope sender. Therefore, SRS alone cannot achieve DMARC alignment if DKIM was stripped or broken.

How ARC Operates: Cryptographic Chain of Custody

ARC solves this by having each participating intermediary record the authentication state it observed at the time of receipt and sign that record with its own cryptographic key before forwarding.

The Three ARC Headers Explained

For each hop i:

1. ARC-Authentication-Results (AAR):

The intermediate MTA runs standard authentication checks upon receiving the message and logs the result:

   ARC-Authentication-Results: i=1; mx.microsoft.com 1;
     spf=pass smtp.mailfrom=contoso.com;
     dkim=pass header.d=contoso.com;
     dmarc=pass action=none header.from=contoso.com;
     arc=none
   

1. ARC-Message-Signature (AMS):

The MTA hashes the body and selected headers, signing them using its private domain key (similar to a standard DKIM signature):

   ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
     s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type;
     bh=f2X...; b=K9L...
   

1. ARC-Seal (AS):

This is the critical header that locks the chain together. It binds all previous ARC-Seal headers together with the current instance's cv (Chain Validation) state:

   ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
     b=W1q...
   

Chain Validation (cv) Logic: How Receivers Validate ARC

When a destination MTA evaluates an inbound email containing ARC headers, it follows a strict RFC 8617 verification routine:

1. Count the Instances: The sequence i=1, 2, ... N must be strictly contiguous. If any sequence number is skipped or duplicated, the chain is broken (cv=fail).
2. Validate Signatures:

- Verify every ARC-Seal signature from i=1 to i=N. - Verify the most recent ARC-Message-Signature (i=N).

1. Inspect the Chain Validation Flag (cv):

- For i=1: cv must equal none. - For all i > 1: cv must equal pass. - If any hop reports cv=fail, all subsequent hops and the receiving MTA treat the entire chain as unverified.

Does ARC Override DMARC Automatically?

Key Rule: An ARC pass does not grant automatic entry into an inbox by itself.

RFC 8617 explicitly leaves trust to the receiving system's local policy. If ARC blindly overrode DMARC, an attacker could set up their own rogue server (attacker.com), sign an ARC header asserting dmarc=pass, and bypass SPF/DKIM protections on any target domain.

To prevent this exploit:

• Major Providers (Microsoft, Google): Combine ARC with extensive domain sender reputation metrics.
• Enterprise Tenants: Use Trusted ARC Sealers (AAR list). In Microsoft 365, you explicitly specify which third-party intermediaries (e.g., your inbound email security gateway, partner relays) are trusted to override DMARC.

Example in Microsoft 365:

# Connect to Exchange Online PowerShell
Connect-ExchangeOnline

# Inspect current Trusted ARC Sealers
Get-ArcConfig

# Add trusted intermediary domains (e.g., Proofpoint or Mimecast relays)
Set-ArcConfig -Identity Default -ArcTrustedSealers @{Add="proofpoint.com","mimecast.com"}

When EOP processes an email where DMARC fails, but the seal matches an entry in ArcTrustedSealers and the chain is valid, EOP issues a composite authentication pass:

Authentication-Results: ... compauth=pass reason=130

Comparing Email Authentication Technologies

Summary Checklist for IT Administrators

1. Deploy DMARC p=quarantine or p=reject: Do not let fear of forwarding breakage hold back your domain security.
2. Ensure Your Relays Support ARC: If your organization operates mailing lists, support ticketing systems, or outbound security proxies, ensure your software is configured to generate ARC sets (AAR, AMS, AS).
3. Configure Trusted ARC Sealers: If you route external mail through a third-party security gateway before Microsoft 365, add the gateway's signing domain to Exchange Online via Set-ArcConfig.
4. Audit Message Headers: Use native message detail inspectors or PowerShell header analyzers to ensure ARC chains maintain cv=pass status across all routing hops.

Related Guides

• Configure Trusted ARC Sealers in Exchange Online with Set-ArcConfig
• Real 3-Hop ARC Header Walkthrough & PowerShell Parser
• Audit SPF, DKIM and DMARC Across All Microsoft 365 Tenant Domains
• Enable Inbound SMTP DANE with DNSSEC in Exchange Online