ARC (Authenticated Received Chain)

ARC (Authenticated Received Chain) solves a genuinely absurd problem: the authentication systems you set up to prevent spoofing end up rejecting your own legitimate mail.

Here's the trap. You configure SPF, DKIM, and DMARC properly. Everything works. Then someone forwards your message through a mailing list, and suddenly it fails authentication and gets quarantined. The stricter your policies, the more this happens.

ARC provides a way out. It lets intermediaries—forwarding servers, mailing lists—vouch for messages they verified before modifying them. The destination server sees a chain of witnesses saying "I checked this message when it arrived, and it was legitimate."

Why Forwarding Breaks Everything

Email authentication wasn't designed for a world where messages bounce through intermediaries.

SPF breaks immediately. When alice@company.com forwards a message to her personal Gmail, Gmail receives mail claiming to be from company.com but arriving from Alice's forwarding server. That server isn't in company.com's SPF record. Fail.

DKIM breaks on modification. Mailing lists add footers. Forwarding services add headers. Security gateways strip attachments. Any change invalidates the DKIM signature because the content no longer matches the original hash.

DMARC fails when both break. And with a strict DMARC policy, the message gets quarantined or rejected—even though it was completely legitimate.

This creates an impossible choice: strict authentication that breaks forwarding, or loose authentication that allows spoofing. ARC offers a third option.

How ARC Works

ARC doesn't replace SPF, DKIM, or DMARC. It augments them by creating a chain of vouching through intermediaries.

Think of it like a package being handed from courier to courier. Each courier signs for the package when they receive it, noting its condition. If the package arrives damaged, you can trace back through the signatures to see who had it when it was still intact.

The chain in action:

1. Original message arrives at mailing list. SPF passes, DKIM passes, DMARC passes. The list server records these results in ARC headers, signs the record with its own key, then modifies the message (adds a footer) and sends it on.

2. Modified message arrives at forwarding server. DKIM now fails (message was modified), but the ARC chain is intact. The forwarding server validates the ARC headers, sees the message originally passed authentication, records its own results, signs the updated chain, and forwards to the final destination.

3. Message arrives at destination. SPF fails (wrong server). DKIM fails (modified content). DMARC fails. But the ARC chain validates—there's a clear record showing trusted intermediaries who verified the message when it was still intact.

The destination server can now make an informed decision: reject based on current failures, or trust based on the ARC chain showing original legitimacy.

The Three ARC Headers

Each intermediary adds three headers, numbered sequentially (i=1, i=2, etc.):

ARC-Authentication-Results records what this intermediary saw:

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

ARC-Message-Signature is a DKIM-style signature of the message as this intermediary received it:

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

ARC-Seal signs the entire ARC chain, preventing tampering:

ARC-Seal: i=1; a=rsa-sha256; d=list.example.com; s=arc-selector;
    cv=none; t=1702166400; b=ghi789...

The cv= (chain validation) value tells you the state of the chain:

• cv=none — First intermediary, no previous chain
• cv=pass — Previous chain validated successfully
• cv=fail — Previous chain validation failed (something's wrong)

Who Needs ARC

ARC is for intermediaries that touch mail in transit:

Mailing lists that add footers, headers, or subject prefixes. Every modification breaks DKIM, so the list must vouch for what it received.

Forwarding services that route mail from one address to another. The forwarding breaks SPF, so the service must vouch.

Corporate mail gateways that scan, filter, or modify messages before delivery.

Email security services that process mail in transit.

If you're just sending or receiving mail without modifying or forwarding it, you don't need to implement ARC signing. But you should implement ARC validation to benefit from the chains others create.

Setting Up ARC Signing

ARC uses DKIM-style keys. If you already have DKIM configured, you're halfway there.

Publish an ARC selector in DNS:

arc-selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GC..."

This is identical to a DKIM record—ARC reuses the DKIM key format.

Configure your mail software:

For Postfix, install OpenARC and configure /etc/openarc.conf:

Domain              example.com
Selector            arc-selector
KeyFile             /etc/openarc/keys/arc-selector.private
Mode                sv
Canonicalization    relaxed/relaxed

For mailing list software like Mailman 3, ARC support is built-in when DKIM is configured.

Cloud email services typically enable ARC automatically when you configure DKIM.

ARC Validation

Receiving servers validate ARC chains before trusting them:

1. Extract all ARC header sets (i=1, i=2, ...)
2. Verify the numbers are sequential starting from 1
3. For each set, verify the ARC-Seal and ARC-Message-Signature
4. Check that cv= values match expected results
5. If everything validates, the chain is trustworthy

Then comes the trust decision. ARC only works if you trust the intermediaries in the chain. You typically trust major email providers, well-known list services, and your own infrastructure. Unknown intermediaries provide less assurance.

ARC vs. SRS

SRS (Sender Rewriting Scheme) is an older, simpler approach to the forwarding problem:

SRS rewrites the envelope sender when forwarding, so SPF checks against the forwarding server instead of the original sender. It's simpler and more widely deployed, but it doesn't help when DKIM breaks.

ARC preserves the full authentication chain, addressing both SPF and DKIM failures. It's more comprehensive but newer and less widely deployed.

Some systems use both—SRS for SPF compatibility, ARC for complete chain preservation.

Limitations

ARC doesn't solve everything.

Trust is required. If you don't trust the intermediaries in the chain, the chain doesn't help you. And determining which intermediaries to trust is a policy decision, not a technical one.

Adoption is incomplete. Many forwarding services and mailing lists don't implement ARC yet. Messages that pass through non-ARC intermediaries lose the chain.

Complexity. ARC is harder to implement correctly than SPF or DKIM. Mistakes can break the chain or, worse, create false assurance.

Chain fragility. If any intermediary in the path doesn't support ARC or implements it incorrectly, the chain breaks at that point.

The State of ARC

Major email providers—Gmail, Microsoft, Yahoo—validate ARC chains. Modern mailing list software includes ARC support. The standard (RFC 8617) is established.

But universal deployment is years away. ARC helps when it's present, but you can't rely on it being present. It's a tool that improves deliverability for forwarded mail when the chain exists—not a complete solution to the forwarding problem.

The forwarding problem itself may never fully disappear. Email authentication was designed for a simpler world, and ARC is an elegant patch on a system that wasn't built for how email actually flows.