ARC Email Authentication Explained: How Authenticated Received Chain Saves Forwarded Mail

Mailing lists, security gateways, and forwarding services routinely break SPF and DKIM before email reaches the final inbox. When intermediate servers modify a message or relay it from a different IP, the original authentication signals no longer match, DMARC fails, and legitimate mail lands in spam folders or gets rejected outright. ARC (Authenticated Received Chain) was designed to solve this exact problem by preserving authentication results across every hop the message takes.

For senders, ARC is the difference between mail that survives forwarding and mail that vanishes into junk folders the moment it leaves a mailing list. For mailbox providers, ARC offers a verifiable way to trust that a message was authenticated upstream even when the final delivery cannot be checked directly. This guide covers how ARC works, when you need to implement it, and how Gmail, Microsoft, and Yahoo treat ARC chains in 2026.

What Is ARC and Why Does It Exist?

ARC (Authenticated Received Chain), defined in RFC 8617, is an email authentication standard that allows intermediate handlers to vouch for the authentication results of a message they received and forwarded. Every server that handles a message can add a cryptographically signed record stating, in effect, "When this message arrived at my server, here is what SPF and DKIM said about it."

The problem ARC solves is older than ARC itself. SPF (Sender Policy Framework) validates the sending IP, but the moment a forwarder relays a message, the IP changes and SPF fails. DKIM (DomainKeys Identified Mail) survives some forwarding scenarios, but mailing lists that rewrite subjects (adding "[List-Name]") or insert footers break the DKIM signature. When both fail, DMARC fails, and any sender publishing a strict policy ends up with their forwarded mail rejected at the receiving server.

ARC creates a verifiable record of what happened upstream so that the final mailbox provider can choose to trust that record even when the immediate authentication checks at delivery time fail.

How ARC Works: The Three Headers

Every ARC-aware server adds three headers when it relays a message. Each set of headers is numbered with an instance value (i=1 for the first signer, i=2 for the second, and so on), and together they form the chain.

ARC-Authentication-Results (AAR)

The AAR header captures a snapshot of the authentication results the relaying server observed when the message arrived. It records SPF, DKIM, and DMARC outcomes, plus any other authentication checks performed. This header is plaintext (not signed by itself) but becomes part of the signed material in later headers.

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

ARC-Message-Signature (AMS)

The AMS is essentially a DKIM signature over the message body and headers as the relaying server saw them. It uses the same canonicalization and signing mechanics as DKIM. If the message gets modified later (for example, a downstream filter adds yet another footer), the AMS still verifies against the version this server forwarded, proving what was sent.

ARC-Seal (AS)

The AS header signs the AAR, the AMS, and any prior AS headers from earlier hops. It is what binds the chain together. Each new signer creates a new AS that wraps everything that came before, making it impossible to retroactively edit earlier hops without breaking the chain.

How Mailbox Providers Trust the ARC Chain

Adding ARC headers is the easy part. The harder question is whether downstream mailbox providers will trust them. ARC was deliberately designed without a built-in reputation system, leaving each receiver to decide how much weight to give a chain based on the signing domains involved.

In practice, three factors determine trust:

1. Reputation of every signer in the chain. If a known mailing list operator with a clean reputation signs an ARC chain, downstream receivers are likely to trust it. If a low-reputation or unknown domain sealed the chain, the chain provides less benefit.
2. Chain validity. Each AS must verify cryptographically. If any seal fails (because of corruption, misconfiguration, or tampering), the entire chain is marked invalid (cv=fail) and ignored.
3. Original sender reputation. ARC says "trust me, the message authenticated when I received it," but receivers still consider the original sender reputation. ARC cannot rescue mail from a domain with poor standing.

Who Needs to Implement ARC?

ARC implementation falls into two distinct categories: signing and verifying. Most senders never need to sign ARC themselves. The signers are intermediate handlers that modify or relay mail.

Who Should Sign ARC

• Mailing list operators. Any list that adds subject prefixes, body footers, or rewrites headers should sign ARC.
• Email forwarding services. Anyone running a mail forwarding service (work-to-personal forwarders, alias services, transactional forwarders) should sign ARC.
• Security gateways and filtering appliances. Inbound mail gateways that perform virus scanning, modify headers, or relay to internal systems should sign ARC.
• Group address handlers. Distribution groups in M365, Google Workspace, and on-prem Exchange that resend mail to members should sign ARC.

Who Should Verify ARC

• Mailbox providers. The big four (Gmail, Yahoo, Microsoft, iCloud) all verify ARC. Smaller providers should as well.
• Hosted email platforms. Any platform delivering mail to end users should evaluate ARC before applying strict DMARC enforcement to forwarded mail.

How to Implement ARC Signing

The mechanics of ARC signing closely mirror DKIM. You need a private signing key, a corresponding public key published in DNS, and an MTA capable of generating ARC headers.

DNS Setup

ARC public keys are published in DNS exactly like DKIM keys, using a TXT record at:

selector._domainkey.signing-domain.example

The same DKIM record format applies. ARC does not use a separate DNS prefix; it reuses the DKIM key infrastructure.

MTA Configuration

Major MTAs support ARC through plugins or built-in modules:

• OpenARC works with Postfix and Sendmail, providing both signing and verification milters.
• Rspamd includes ARC signing as a standard module, popular with Postfix deployments.
• Exim supports ARC natively in modern versions through its authentication framework.
• Microsoft Exchange Online handles ARC automatically for distribution groups and connectors.

Whichever you use, the signing process happens at the moment of forwarding: receive the message, examine its existing authentication, capture the AAR, generate the AMS over the modified message, then create the AS that seals everything together.

Common ARC Implementation Mistakes

ARC is unforgiving of misconfiguration because a broken seal renders the entire chain useless. The most common failures we see in the wild include:

• Signing in the wrong order. The AS must be created last, after the AAR and AMS exist. Some implementations build the AS before the AMS, breaking the chain immediately.
• Modifying the message after signing. If a relay adds a footer or rewrites a subject after generating the AMS, the AMS will not verify when the next hop checks it. Always sign last.
• Reusing an old DKIM key for ARC without coordination. Sharing keys works, but if you rotate the DKIM key without updating ARC tooling, signatures break.
• Ignoring cv=fail signals. When ARC verification fails at one hop, downstream signers should record cv=fail rather than continuing to add seals on top of a broken chain.
• Skipping verification of inbound mail. If your gateway accepts ARC-signed mail without verifying, you cannot extend trust correctly to internal recipients.

How Major Providers Handle ARC

Each major mailbox provider treats ARC slightly differently:

Smaller providers and on-prem mail servers vary, but the trajectory is clear: ARC has moved from optional to expected for any system handling forwarded mail at scale.

How to Test Your ARC Implementation

The simplest way to test ARC signing is to send a message through your forwarding system to a Gmail or Outlook account, then inspect the raw headers. Look for three things:

1. Three ARC headers (AAR, AMS, AS) added by every relay between origin and final delivery.
2. An "Authentication-Results" header at the final receiver showing arc=pass.
3. cv=pass on every AS header except the very first one (which legitimately has cv=none).

If you see arc=fail or arc=none, work backwards through the chain to find the broken hop. Our email header analyzer can parse the chain and highlight which hop failed verification.

ARC, DMARC, and the Future of Email Authentication

DMARC enforcement at p=reject is increasingly common, but mailing lists and forwarding workflows make strict enforcement risky for many domains. ARC provides the technical bridge that lets receivers apply DMARC fairly: if the original message authenticated correctly and a trusted forwarder signed an intact ARC chain, the receiver can extend the original authentication trust forward instead of rejecting the message because of forwarding mechanics.

For senders considering moving to DMARC p=reject, ARC adoption by intermediate handlers is what makes the move viable. As ARC support grows, the historical concern about strict DMARC breaking mailing lists fades, because receivers can verify the upstream authentication through the ARC chain.

Implementing or verifying ARC is now a basic expectation for any system handling forwarded email at volume. Senders who originate mail rarely sign ARC, but every operator of a list, gateway, or forwarder should. For deeper coverage of the surrounding standards, see our email authentication guide.

Frequently Asked Questions

← Back to Blog