ARC (Authenticated Received Chain)

ARC (Authenticated Received Chain, RFC 8617) solves a specific problem: when a legitimate intermediary modifies an email in transit, DKIM signatures break, SPF fails because the relay's IP isn't on the original sender's list, and DMARC fails. The receiver assumes the message is spoofed. ARC preserves the original auth results so the final receiver can trust them.

The problem ARC solves

Imagine alice@example.com sends a message to a mailing list at lists.org. The mailing list adds a [List-Name] prefix to the subject and a footer. Then it relays the message to bob@gmail.com.

• Original DKIM signature: broken (subject and body were modified).
• SPF for example.com: fails (mail came from lists.org's IP, not example.com's).
• DMARC alignment: fails.
• If example.com has p=reject, Gmail drops the message.

Both Alice and Bob were sending legitimately. The list operator is legitimate. Everyone followed the rules. Mail breaks anyway because DMARC didn't expect this relay pattern.

How ARC fixes it

When lists.org modifies the message, it adds three headers:

• ARC-Authentication-Results: — what auth results lists.org itself saw (DKIM pass, SPF pass for example.com).
• ARC-Message-Signature: — DKIM-style signature over the message as lists.org is forwarding it.
• ARC-Seal: — signature over the previous two headers, plus any prior ARC headers from earlier hops.

The final receiver can:

1. See the chain of ARC seals.
2. Verify each seal against the intermediary's published ARC key (just like DKIM, via DNS TXT under _domainkey).
3. Trust the original Authentication-Results recorded by lists.org if the chain is intact and lists.org is a known good actor.

Who actually does this

Gmail, Microsoft 365, Yahoo, Fastmail all add ARC headers when forwarding or relaying mail. Most modern mailing list software (Mailman 3, Sympa, Discourse with mail-in) does too.

Most receivers don't yet trust ARC signals from arbitrary domains. The current state is: if Gmail forwards a message to Microsoft 365 with ARC headers, Microsoft trusts Gmail's ARC results. If a random domain signs ARC headers, receivers might log them but not act on them.

What to do in a SaaS

If your platform modifies forwarded messages (group chat that emails members, ticketing system that distributes replies), you should be adding ARC headers. Most modern mail libraries (OpenDKIM, Authlib) support it. Not adding ARC means recipients with strict DMARC will lose mail from your platform.