technology email authentication security

What Is ARC (Authenticated Received Chain) and Why Email Forwarding Needs It

12 min read Jan 1, 2026

Email authentication was built for a simple world: one sender, one receiver, no middlemen. But forwarding, mailing lists, and relay services break that assumption. SPF checks the sending server, and a forwarding server is not the original sender. DKIM survives forwarding only if the content stays untouched. DMARC ties it all together but fails when both SPF and DKIM fall apart in transit.

ARC — Authenticated Received Chain — was designed to fix this. It gives each server in the forwarding chain a way to record and sign the authentication results it observed, creating a verifiable chain of custody for email authentication.

The forwarding problem, revisited

Before diving into ARC, it helps to understand exactly what breaks during forwarding. Consider this flow:

A sender at company.com emails you@yourdomain.com
Your domain forwards mail through a service to you@gmail.com
Gmail receives the email and checks authentication

At step 3, Gmail sees the forwarding server's IP — not company.com's. SPF fails because the forwarding server is not listed in company.com's SPF record. If the forwarding service modified anything (added a footer, changed headers, rewrote URLs), DKIM may also fail. With both SPF and DKIM failing, DMARC fails too.

The email was legitimate. The forwarding was authorized. But the authentication chain is broken.

SRS (Sender Rewriting Scheme) solves the SPF part by rewriting the envelope sender. But SRS does not help DKIM, and it does not preserve the original authentication context. That is where ARC comes in.

How ARC works

ARC adds three new headers at each hop in the forwarding chain:

ARC-Authentication-Results (AAR) — Records the authentication results (SPF, DKIM, DMARC) as observed by this hop. This is essentially a signed copy of the Authentication-Results header.
ARC-Message-Signature (AMS) — A DKIM-like signature over the message content and select headers, created by the intermediary. This proves the message was not tampered with between this hop and the next.
ARC-Seal (AS) — A signature over all previous ARC header sets plus the current one. This seals the chain, preventing anyone from inserting or removing hops retroactively.

Each set of these three headers is numbered with an instance counter (i=1, i=2, etc.), creating an ordered chain. The first forwarder adds instance 1, the second adds instance 2, and so on.

A concrete example

Here is what ARC headers look like in practice:

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

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example.com;
    s=arc-20240101; h=from:to:subject:date:message-id;
    b=K8dJ3mN7...

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example.com;
    s=arc-20240101; cv=none;
    b=Lp2xR9vQ...

The cv (chain validation) field in the ARC-Seal is important. It indicates whether the previous chain was valid: none for the first hop, pass if the previous ARC chain validated, or fail if it did not.

The trust model

ARC does not automatically make a message trustworthy. It provides information, but the final receiver decides what to do with it. The key question is: does the receiver trust the intermediary?

When Gmail receives a forwarded message with ARC headers, it evaluates the chain:

Validate all ARC-Seal signatures to ensure the chain is intact
Validate the most recent ARC-Message-Signature to confirm message integrity
Check whether the ARC signer (the forwarder) is in Gmail's trusted list
If trusted, consider the original authentication results from the AAR headers

This trust-based model is both ARC's strength and its limitation. A well-known forwarding service with a good reputation will have its ARC headers respected. An unknown server signing ARC headers carries no weight.

Who trusts ARC today?

Gmail was one of the first major providers to implement ARC validation and is the most prominent consumer of ARC data. Microsoft 365 also evaluates ARC headers and uses them in its filtering decisions, particularly for messages forwarded through known services. Yahoo and AOL have implemented ARC support to varying degrees.

On the signing side, Google Workspace, Microsoft 365, Mailchimp, and several major forwarding services add ARC headers when processing messages. The list of signers continues to grow, but it is far from universal.

ARC validation: pass, fail, and none

When a receiver evaluates ARC, the result falls into one of three categories:

arc=pass — The ARC chain is intact, all signatures validate, and the chain was not broken at any point. This does not mean the message is legitimate; it means the authentication history is verifiable.
arc=fail — One or more signatures in the chain are invalid, or a hop reported cv=fail. The chain is compromised and should not be trusted.
arc=none — No ARC headers are present. The message was either sent directly (no forwarding) or the intermediaries did not implement ARC.

A common misconception is that arc=pass overrides a DMARC failure. It does not, at least not automatically. The receiver may choose to use a passing ARC chain as a signal when making a DMARC override decision, but this is a local policy choice, not a protocol requirement.

ARC and DMARC: how they interact

DMARC's specification includes the concept of "local policy overrides." A domain might publish p=reject, but a receiver can still accept the message if it has a good reason to believe it is legitimate. ARC provides that reason.

The interaction typically works like this:

Message arrives with DMARC failing (SPF fails due to forwarding, DKIM fails due to content modification)
Receiver checks ARC chain — it is valid and signed by a trusted intermediary
The AAR headers show that the original authentication passed at the first hop
Receiver decides to accept the message despite DMARC failure, noting the ARC override in its own Authentication-Results

For a deeper understanding of how DMARC alignment works and why it matters, see The Complete Guide to Email Authentication: SPF, DKIM, DMARC, and Beyond.

Why SRS is still needed alongside ARC

A reasonable question: if ARC preserves authentication history, why do forwarders still need SRS?

The answer is coverage. ARC only helps when:

The forwarder implements ARC signing
The receiver implements ARC validation
The receiver trusts the specific forwarder

If any of these conditions are not met, the forwarded message faces the same SPF problem it always has. SRS, by contrast, works universally. Every receiver understands SPF, and SRS makes SPF pass by rewriting the envelope sender. There is no trust relationship required.

In practice, a well-configured forwarding service should implement both:

SRS to ensure SPF passes at any receiver, regardless of ARC support
ARC to preserve the original authentication context for receivers that understand it

They are complementary, not competing solutions. SRS is the safety net; ARC is the added context.

Setting up ARC signing

If you operate a mail server that forwards email, implementing ARC signing involves:

Generate a key pair — Similar to DKIM, you need an RSA key pair. The public key goes in a DNS TXT record under an _domainkey selector.
Configure your MTA — Most modern MTAs support ARC. OpenDKIM has ARC support, Rspamd can sign ARC headers, and Postfix can be configured to work with either.
Record authentication results before signing — Your server must evaluate SPF, DKIM, and DMARC on the inbound message and include those results in the AAR header before signing.
Validate existing ARC chains — If the inbound message already has ARC headers, validate them and set the cv field accordingly in your ARC-Seal.

The DNS record looks like a standard DKIM record:

arc-20240101._domainkey.forwarder.example.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

ARC limitations and criticisms

ARC is not without its critics. Several concerns have been raised since the protocol was defined in RFC 8617:

Trust bootstrapping — There is no standardized way to establish which ARC signers should be trusted. Each receiver maintains its own list, leading to inconsistent behavior across providers.
Abuse potential — A malicious forwarder could sign ARC headers claiming the original authentication passed when it did not. The trust model is supposed to prevent this, but it relies on receivers correctly maintaining their trust lists.
Complexity — ARC adds three headers per hop. For messages that pass through multiple intermediaries, the header bloat becomes significant. Debugging ARC chain failures requires understanding the entire chain.
Experimental status — RFC 8617 was published as "Experimental," not "Standards Track." This reflects the IETF's uncertainty about the trust model. While adoption has grown, the experimental status remains.

Checking ARC headers in your email

You can inspect ARC headers in any email client that shows raw headers. In Gmail, click the three dots on a message and select "Show original." Look for headers starting with ARC-. The Authentication-Results header from Gmail will also show the ARC evaluation result:

Authentication-Results: mx.google.com;
    arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
    spf=fail;
    dmarc=fail

In this example, SPF and DMARC failed (expected for forwarded mail), but the ARC chain passed and showed that authentication was valid at the first hop. Gmail can use this to override the DMARC failure.

The future of ARC

ARC adoption continues to grow, driven primarily by the major mailbox providers. As more forwarders implement ARC signing and more receivers learn to evaluate it, the protocol becomes more useful. However, it is unlikely to become a standalone solution. The email ecosystem is too fragmented for any single trust mechanism to work universally.

The most likely future is one where ARC works alongside SRS, DKIM, and DMARC as part of a layered authentication stack. Each protocol covers a different failure mode, and together they provide reasonable assurance that forwarded email can be both authenticated and delivered.

How Cleanbox handles ARC

Cleanbox implements both ARC signing and SRS for forwarded email. When a message arrives at Cleanbox and is forwarded to your destination server, the original authentication results are recorded in ARC headers and signed with Cleanbox's key. Simultaneously, SRS rewrites the envelope sender to ensure SPF passes regardless of whether the destination server evaluates ARC.

This dual approach means forwarded mail through Cleanbox maintains authentication context for providers that support ARC (like Gmail and Microsoft 365) while remaining compatible with every other mail server through SRS. You do not need to configure anything — both mechanisms are applied automatically during forwarding.

For more on how SRS works in practice, see Why Your Email Forwarder Breaks SPF and How SRS Fixes It.