ARC (Authenticated Received Chain) Explained: How It Fixes Email Forwarding Authentication Failures

If you have moved your DMARC policy to p=quarantine or p=reject, you may have noticed something frustrating: legitimate emails that are forwarded or sent through mailing lists start failing authentication checks and landing in spam, or worse, getting rejected entirely. This is the exact problem that ARC (Authenticated Received Chain) was designed to solve.

Defined in RFC 8617 and published in July 2019, ARC provides a mechanism for intermediate mail servers to cryptographically sign and preserve the original authentication results of a message as it passes through multiple hops. In this guide, we'll explain how ARC works, why it matters for your deliverability, and how it fits into the broader email authentication ecosystem.

The Email Forwarding Authentication Problem

To understand why ARC exists, you need to understand the limitations of existing authentication protocols when emails are forwarded.

How Forwarding Breaks SPF

SPF (Sender Policy Framework) validates that an email was sent from an IP address authorized by the sender's domain. When an email is forwarded, the forwarding server's IP address becomes the new sending IP. Since this IP is not listed in the original sender's SPF record, the SPF check fails at the final destination.

For example, if Alice sends an email from example.com to a mailing list at lists.company.com, and that list redistributes the message to Bob at recipient.com, the final receiving server sees the message arriving from lists.company.com's IP address, not example.com's authorized IP. SPF fails.

How Forwarding Breaks DKIM

DKIM (DomainKeys Identified Mail) signs specific parts of the email header and body with a cryptographic signature. When a mailing list or forwarding service modifies the message, such as adding a subject tag like "[ListName]", appending a footer, or changing headers, the DKIM signature becomes invalid because the signed content no longer matches.

How DMARC Fails as a Result

DMARC requires that at least one of SPF or DKIM passes and aligns with the From domain. When forwarding breaks both SPF and DKIM, DMARC fails. If the sender has published a strict DMARC policy (p=quarantine or p=reject), the receiving server may quarantine or reject the message entirely, even though it was a completely legitimate email.

What Is ARC (Authenticated Received Chain)?

ARC is an email authentication protocol that allows intermediate mail servers, such as mailing list managers, forwarding services, and email gateways, to sign the original authentication results of a message and preserve them as the email passes through multiple hops. By creating a verifiable "chain of custody," ARC enables the final receiving server to see that the email originally passed authentication, even if the current checks fail due to legitimate modifications in transit.

Think of ARC as a notarized trail of authentication stamps. Each server the email passes through adds its own stamp, vouching for the authentication results it observed. The final recipient can then review the entire chain and decide whether to trust the message based on its original authentication status rather than just the current (broken) checks.

The Three ARC Headers

ARC introduces three new email headers that work together to create the authentication chain. Each set of headers is numbered with an instance counter (i=1, i=2, etc.) that increments at each hop.

ARC-Authentication-Results (AAR)

This header records the authentication results (SPF, DKIM, DMARC) that the intermediate server observed when it received the message. It is essentially a copy of the standard Authentication-Results header, preserved under a new name so it cannot be overwritten by subsequent servers.

ARC-Authentication-Results: i=1; mx.forwarder.com;
    dkim=pass header.d=example.com;
    spf=pass smtp.mailfrom=example.com;
    dmarc=pass header.from=example.com

ARC-Message-Signature (AMS)

This is a DKIM-like signature that covers the message headers and body at the point when the intermediate server processes it. It functions similarly to a standard DKIM signature but is specifically tied to the ARC chain. This allows the receiving server to verify that the message content has not been tampered with since the intermediate server processed it.

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com;
    s=arc-selector; c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=abc123...=; b=xyz789...=

ARC-Seal (AS)

The ARC-Seal is a cryptographic signature that covers all previous ARC header sets (AAR, AMS, and prior ARC-Seals). It includes a critical tag called cv (Chain Validation Status) that indicates whether the existing ARC chain was valid when this server processed the message.

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com;
    s=arc-selector; t=1700000000;
    cv=none;
    b=def456...=

The cv tag has three possible values:

• none: No prior ARC chain existed (this is the first hop)
• pass: The prior ARC chain was validated successfully
• fail: The prior ARC chain validation failed

How ARC Works: Step by Step

Here is a complete example of ARC in action when an email is sent through a mailing list:

1. Alice sends an email from alice@example.com to devlist@lists.company.com. The email passes SPF, DKIM, and DMARC at the mailing list server.
2. The mailing list server records the authentication results in an ARC-Authentication-Results header (i=1), showing that SPF, DKIM, and DMARC all passed.
3. The mailing list server creates an ARC-Message-Signature (i=1) that signs the current state of the message.
4. The mailing list server creates an ARC-Seal (i=1) with cv=none (since there was no prior ARC chain), signing all the ARC headers.
5. The mailing list modifies the message by adding a "[DevList]" subject prefix and a footer, then forwards it to bob@recipient.com.
6. Bob's receiving server checks DMARC and finds it fails because the DKIM signature is now invalid (the message was modified) and SPF fails (the sending IP belongs to lists.company.com, not example.com).
7. Bob's server checks the ARC chain. It validates the ARC-Seal, verifies the ARC-Message-Signature, and reads the ARC-Authentication-Results. The AAR shows the message originally passed DMARC at the mailing list server.
8. If Bob's server trusts the mailing list as an ARC sealer, it can accept the message based on the ARC results despite the DMARC failure.

ARC Support Among Major Providers

ARC has been adopted by all the major mailbox providers, though each implements trust decisions differently:

ARC vs SPF, DKIM, and DMARC

ARC is not a replacement for existing authentication protocols. It is a supplementary protocol that addresses a specific limitation. Here is how it fits into the authentication stack:

When Does ARC Matter Most?

ARC becomes critical in several common email scenarios:

• Mailing lists: Services like Mailman, Sympa, Google Groups, and corporate distribution lists frequently modify messages (adding subject tags, footers, or reply-to headers), which breaks DKIM.
• Email forwarding: When users set up auto-forwarding rules (e.g., forwarding all mail from an old address to a new one), SPF breaks because the forwarding server's IP is not in the original sender's SPF record.
• Email security gateways: Organizations that route inbound email through third-party security gateways or spam filters may see authentication failures if those gateways modify messages before delivery.
• Account migration: During email migrations where mail flows through relay servers, ARC preserves authentication through the transition.

If your organization uses a strict DMARC policy and you receive reports showing legitimate emails failing authentication after being forwarded, ARC is likely the solution. Check your DMARC configuration and review aggregate reports for patterns of forwarding-related failures.

How to Configure ARC

For Microsoft 365 Administrators

If you receive forwarded emails that fail DMARC due to intermediary modifications, you can configure trusted ARC sealers in Microsoft Defender:

1. Open the Microsoft Defender portal at security.microsoft.com
2. Navigate to Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings
3. Select the ARC tab
4. Click "Add" and enter the trusted signing domain (the domain shown in the d= value of the ARC-Seal header from the intermediary)
5. Save the configuration

For Self-Hosted Mail Servers

If you run Postfix, Sendmail, or another MTA, you can implement ARC using the OpenARC milter. The general process involves installing the OpenARC package, configuring your DKIM-like signing keys, and integrating the milter into your MTA's processing pipeline. Mailing list managers like Sympa (v6.2.38+) and Mailman also include built-in ARC support.

ARC Limitations to Understand

ARC is not a silver bullet. There are important limitations to keep in mind:

• Trust is discretionary. The receiving server decides whether to trust a given ARC sealer. There is no universal trust list.
• ARC does not verify sender identity. It only preserves and relays previous authentication results. A malicious intermediary could theoretically forge ARC headers.
• ARC headers can be stripped. An intermediary that does not support ARC may strip ARC headers from the message, breaking the chain.
• Not all intermediaries seal. If a forwarding service does not add ARC headers, the chain of custody has a gap that cannot be bridged.

Troubleshooting ARC Issues

If you are seeing forwarded emails fail despite ARC being present, check these common issues:

• Untrusted sealer: The receiving server does not trust the intermediary's ARC seal. You may need to add the sealer's domain to your trusted ARC sealers list (in Microsoft 365) or adjust your filtering policy.
• Broken chain: One intermediary in the forwarding path does not support ARC, creating a gap in the chain. The cv=fail value in a later ARC-Seal header indicates this.
• Missing ARC headers: The intermediary does not implement ARC at all. In this case, you may need to contact the intermediary or adjust your DMARC policy for that specific mail flow.
• Key rotation issues: If the intermediary has rotated their ARC signing keys without updating DNS, the ARC-Seal signature validation will fail.

You can inspect ARC headers by viewing the full message source in your email client. Use the email header analyzer tool to parse and display ARC chain details in a readable format.

Frequently Asked Questions