Learn · Email authentication

What is ARC?

Forwarding is authentication's blind spot: a forwarded message arrives from an IP that fails SPF, and mailing lists that tag subjects or add footers break DKIM too. ARC — Authenticated Received Chain — lets each server that handles a message pass along, verifiably, what the authentication results looked like when it received it.

The problem it solves

Picture a message from you@example.com, perfectly authenticated, sent to a university alumni list. The list server re-sends it to 500 members, adding "[AlumniList]" to the subject and an unsubscribe footer. At each member's mailbox provider: SPF fails (the list's IP isn't in your record), DKIM fails (the subject and body changed), and under a DMARC policy of p=reject, your legitimate message gets refused.

That combination — SPF and DKIM both failing on mail you really did send — has three common causes, and forwarding is only one of them. Which one you are looking at decides whether there is anything to fix.

Before blaming forwarding, rule out configuration: run your domain through the SPF checker and DKIM checker — a syntax error or an unpublished selector produces the same two red badges without a forwarder in sight.

Before ARC, receivers handled this with guesswork — allow-listing known lists, or applying DMARC less strictly to traffic that looked like forwarding. ARC (RFC 8617) replaces the guesswork with cryptographic evidence.

How the chain works

Each intermediary that handles the message adds a sealed set of three headers:

• ARC-Authentication-Results — "here's what SPF, DKIM and DMARC looked like when the message reached me." For our mailing-list example: everything passing.
• ARC-Message-Signature — a DKIM-style signature over the message as this hop sends it on.
• ARC-Seal — a signature over the ARC headers themselves, chaining this hop to all previous ones, with a cv= (chain validation) tag saying whether the chain was intact so far.

The final receiver can now see: the message failed DMARC here, but a verifiable chain shows it passed at the moment a known mailing-list operator received it, and only that operator modified it since. If the receiver trusts that operator, it can choose to deliver the message despite the DMARC failure — an override the standard calls a local policy decision.

What you need to do about ARC

For most domain owners: nothing. ARC has no DNS record for you to publish and no setting to enable — sealing is done by the servers that forward and receive mail. Google, Microsoft, and the major list platforms already seal and evaluate it. What ARC changes for you:

• It makes strict DMARC policies safer. A chunk of the "legitimate mail that would break at p=reject" problem — the forwarding chunk — gets quietly rescued by receivers honoring ARC chains.
• It explains report anomalies. In your aggregate reports you'll see mail failing both SPF and DKIM from IPs belonging to universities, associations, or list services, yet with a disposition of none even under enforcement. That's often an ARC override at work — expected, benign, and no reason to delay tightening policy.
• If you run mail infrastructure that forwards (a list server, an alias service), implement ARC sealing — otherwise strict DMARC domains will break on your forwards.

ARC in one sentence

DMARC asks "does this message authenticate for the From domain, right now?" — ARC adds "…and if not, can anyone vouch, verifiably, that it did before it was forwarded?"