What Is ARC? Authenticated Received Chain Explained

If you have ever wondered what ARC email authentication is, the short version is this: ARC, or Authenticated Received Chain, is a way for a mail server to attach the authentication results it saw to a message, so the next server in the chain can trust them even after the message has been changed. It is defined in RFC 8617, an Experimental specification published in July 2019.

ARC exists for one situation — indirect mail flows. That is when a message does not travel straight from sender to recipient, but passes through a mailing list, a forwarder, or a scanning service that rewrites it along the way. Those intermediaries routinely break the two signatures email relies on, and that is the exact problem ARC was written to solve.

How ARC works#

Every time an ARC-aware server handles a message, it adds a set of three header fields. One instance of all three is called an ARC Set, and each set is numbered with an instance tag (i=1, i=2, and so on) so the chain stays in order. A message that has crossed three ARC-aware hops carries three ARC Sets, oldest first.

The three fields divide the work between them. Two protect the message and its authentication results at a single hop; the third protects the chain as a whole.

• ARC-Authentication-Results (AAR) — records the authentication assessment (the SPF, DKIM, and DMARC results) exactly as that hop saw them when the message arrived.
• ARC-Message-Signature (AMS) — signs the message headers and body, much like a DKIM signature, capturing the message as that hop is passing it on.
• ARC-Seal (AS) — signs and binds the earlier ARC header fields together, and carries a chain validation (cv) tag reporting whether the chain so far is valid.

Reading the chain#

The ARC-Seal's cv tag is how a later server reads the chain's health. The first seal in a chain reports cv=none. Each seal after that reports cv=pass when every prior set still validates, or cv=fail when the chain was tampered with.

A receiver at the end of the path can verify the whole sequence and see the original authentication results — even though its own SPF and DKIM checks now fail because of the intermediary's edits. The chain is the evidence; whether to act on it is a separate decision.

Why ARC matters: what breaks without it#

To see why ARC matters, follow a message into a mailing list. DKIM signs specific headers plus the body; a list usually prepends a tag to the Subject line and appends a footer to the body. RFC 7960 — the document describing exactly these interoperability problems — notes that such changes fall outside DKIM canonicalization and invalidate the signature.

SPF breaks a different way. SPF checks the envelope sender against the sending server's IP. When a forwarder relays the message unchanged, that check fails; if the forwarder rewrites the envelope to its own domain, SPF may pass but no longer aligns with the visible From address. Either way, DMARC alignment is lost.

The consequence is blunt. A strict policy (p=reject) tells the receiver to reject a message that fails both checks — including legitimate list mail the subscriber asked for. ARC gives the receiver a way out: it can read the sealed chain, see that SPF and DKIM passed before the list touched the message, decide it trusts that list, and deliver anyway. (DMARC itself was updated in 2026 by RFC 9989, which supersedes RFC 7489; ARC's role alongside it is unchanged.)

ARC vs DKIM: the difference#

ARC is often confused with DKIM because both attach a cryptographic signature to a message. The difference is what they sign and when. DKIM is one signature from the author's domain that must survive untouched; ARC is a running record, re-signed at every hop, of what each server saw.

Common misconceptions#

ARC is narrow by design, and most confusion comes from expecting it to do more than it does. Four claims are worth correcting directly.

• "ARC fixes forwarding DMARC failures automatically." It does not. ARC preserves the evidence; whether a failing message is delivered still depends on the receiver choosing to trust the chain — a local policy decision, per RFC 8617.
• "ARC replaces SPF, DKIM, or DMARC." No. It sits alongside them and depends on them. ARC records their results and only helps when the original message actually passed them.
• "Every sender should turn ARC on." ARC is applied by intermediaries and receivers, not published by ordinary sending domains the way DKIM keys are. If you only send mail, there is nothing to switch on.
• "A broken ARC chain means the message is malicious." RFC 8617 explicitly warns against that conclusion. A broken chain is inconclusive, not proof of anything.

How this shows up in AI Emaily#

ARC is enforced by the receiving mail server, not by the app you read mail in. Google, Microsoft, and other large receivers evaluate the chain when a message arrives and decide whether to deliver it; a client only ever sees the result after that decision is made. So AI Emaily does not seal ARC, publish DNS records, or run your MTA — that work belongs to your provider and to the intermediaries in the path, and we are not going to imply otherwise.

What a client-side layer does is downstream of all that. AI Emaily connects to your existing Gmail, Outlook, or IMAP mailbox and triages the mail that already arrived. The discipline it inherits from authentication is a defensive one: it treats every message body as untrusted input regardless of what passed SPF, DKIM, DMARC, or ARC, because a valid chain proves a message was not altered in transit — not that its contents are safe. Our spam and phishing defense reasons about sender behaviour and domain rather than trusting a green authentication badge. We build AI Emaily.