ARC Sealing and DMARC Pass-Through

Email authentication is a complex dance, and DMARC has introduced a critical layer of security by requiring SPF and DKIM alignment with the From domain. However, the internet's email infrastructure isn't always a direct path. Mail often passes through legitimate intermediaries like mailing lists, forwarding services, or internal message hygiene systems. These hops can inadvertently break DMARC, causing legitimate emails to fail authentication checks at the final recipient. This is where Authenticated Received Chain (ARC) comes into play, offering a mechanism for DMARC pass-through.

The DMARC Challenge: When Legitimate Mail Fails

Before diving into ARC, let's quickly recap the DMARC challenge. DMARC requires that either SPF or DKIM passes and aligns with the From header's domain.

  • SPF (Sender Policy Framework): Checks if the sending IP address is authorized by the Return-Path domain.
  • DKIM (DomainKeys Identified Mail): Uses a cryptographic signature to verify that the message hasn't been tampered with and was sent by an authorized sender for the DKIM-Signature domain.
  • Alignment: For DMARC, the domain in Return-Path (for SPF) or DKIM-Signature (for DKIM) must match or be a subdomain of the From header's domain.

The problem arises when an email goes through an intermediary:

  1. SPF failure: When an email is forwarded, the forwarding server becomes the new sending IP. The original Return-Path domain (the sender's domain) will likely not authorize the forwarding server's IP, causing SPF to fail.
  2. DKIM failure: Intermediaries sometimes modify message content (e.g., adding a footer, rewriting links, changing subject lines for threading). Any modification to signed headers or the body invalidates the original DKIM signature. Even if content isn't modified, if the From header is rewritten (e.g., a mailing list changing From: user@example.com to From: list-owner@mailinglist.com (User via Mailing List)), the original DKIM domain might no longer align with the new From domain.

Without a mechanism to preserve the original authentication results, these legitimate emails will fail DMARC, potentially leading to quarantine or rejection, even if they were originally authenticated and sent by a legitimate source.

Enter ARC: Authenticated Received Chain

ARC is an email authentication system designed to allow intermediaries to assert that an email's authentication status at the point of receipt by the intermediary was legitimate. It provides a chain of custody for email authentication results, enabling a final recipient's mail server to validate the original authentication even if subsequent hops break SPF or DKIM.

Think of ARC as a cryptographic manifest that travels with the email. Each time an ARC-aware intermediary receives a message, it inspects the message's authentication status, records it, and cryptographically "seals" these results into a new set of headers. This forms a chain, where each link in the chain attests to the authenticity of the previous link and the message's state upon receipt.

The primary purpose of ARC is to prevent legitimate mail from failing DMARC due to benign modifications or forwarding, particularly for services like:

  • Mailing lists
  • Email forwarding services
  • Shared mailboxes
  • Cloud-based email hygiene or archiving solutions that modify messages

How ARC Works: Headers and Signatures

ARC introduces three new email headers, added by an ARC-aware intermediary:

  1. ARC-Authentication-Results (AAR): This header captures a snapshot of all relevant authentication results (SPF, DKIM, DMARC, etc.) before the intermediary processes or modifies the message. It's similar to the standard Authentication-Results header but is specifically part of the ARC chain.

    Example: ARC-Authentication-Results: i=1; mx.intermediary.com; spf=pass (sender is user@sender.com) smtp.mailfrom=user@sender.com; dkim=pass (signature was verified) header.d=sender.com; dmarc=pass action=none header.from=sender.com

  2. ARC-Message-Signature (AMS): This header is a DKIM-like signature that covers specific headers from the original message (including the From, Subject, Date, etc.) and the ARC-Authentication-Results header added by the current hop. This signature ensures the integrity of the original message data and the recorded authentication results.

    Example: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=intermediary.com; s=arc; t=1678886400; bh=...; h=from:to:subject:date:arc-authentication-results; b=...

  3. ARC-Seal (AS): This is the crucial chaining header. It's a signature over the ARC-Message-Signature added by the current hop, the ARC-Authentication-Results header added by the current hop, and any previous ARC-Seal headers. This creates a cryptographic chain of custody. Each intermediary adds its ARC-Seal, effectively signing off on the entire history of authentication results up to that point.

    Example: ARC-Seal: i=1; a=rsa-sha256; t=1678886400; cv=none; d=intermediary.com; s=arc; bh=...; b=...

When a recipient's mail server receives an email with ARC headers, it can:

  • Verify the ARC-Seal chain: It starts from the newest ARC-Seal and works backward, verifying each signature. If all seals are valid, the chain is unbroken.
  • Trust the ARC-Authentication-Results: If the chain is valid, the receiver can then look at the ARC-Authentication-Results header from the last valid ARC hop to determine the original authentication status of the message. If that AAR indicates an original SPF or DKIM pass that aligns with DMARC, the message can be considered DMARC-compliant, even if SPF or DKIM failed at the final hop.

ARC in Action: A Real-World Scenario

Let's consider a common scenario: a user sends an email to a mailing list, and that mailing list