ARC Explained: Authenticated Received Chain (2026)

ARC email authentication — the Authenticated Received Chain — exists to solve one frustrating problem: legitimate mail that fails DMARC after it passes through a mailing list or forwarder. When an intermediary modifies a message or relays it from a new IP, it breaks SPF and DKIM, so DMARC fails even though the mail was genuine. ARC email authentication preserves the original “this was authentic when it arrived” verdict so the final receiver can trust it anyway. This guide explains what ARC is, how ARC email authentication works, the three ARC headers, and why — unlike SPF or DMARC — it is not something you publish in DNS. It is part of our email authentication hub.

What is ARC email authentication?

ARC stands for Authenticated Received Chain, defined in RFC 8617 (an Experimental standard). It creates an authenticated chain of custody for email: each mail server that handles a message can record the authentication results it observed and cryptographically pass that judgment to the next hop. The reason ARC email authentication matters is that intermediaries routinely break ordinary authentication — a mailing list adds a footer (breaking DKIM’s body hash) and relays from its own server (breaking SPF). Without ARC, the receiving domain’s DMARC policy would reject perfectly legitimate list and forwarded mail. With it, the final receiver can see the message was authentic when it first entered the chain.

How ARC email authentication works

1. A message passes SPF, DKIM and DMARC at its origin.
2. Each ARC-participating intermediary, before modifying or relaying the message, adds one “ARC set” of headers recording the authentication results it currently sees and sealing them.
3. Each hop increments an instance number and attests whether the chain it received was valid.
4. At the final destination, SPF and DKIM may now fail, so plain DMARC fails too.
5. The receiver validates the ARC chain; if it is intact and the sealing party is trusted, it can use the sealed original results to override the DMARC failure and deliver the message.

The crucial word is trusted: an override only happens when the receiver trusts the intermediary that sealed the chain, because a chain could otherwise be forged.

The three ARC headers

Each hop adds a set of three ARC headers. Together these are what later servers validate:

An instance tag (i=) numbers each set in order, starting at 1, so the receiver can reassemble the chain. The cv= value on the ARC-Seal tells the next hop whether the chain it received was valid — cv=pass means intact, cv=fail means a prior seal could not be verified.

Why ARC is not a DNS record you publish

This is the most common misconception, so it is worth stating plainly: there is no _arc TXT record and no “set up ARC on my domain” step like there is for SPF or DMARC. ARC is implemented by the intermediaries — mailing lists, forwarders and security gateways — which add and sign the ARC headers using their own DKIM keys. The only DNS involved is the DKIM key record that lets a receiver verify a sealer’s signature. For the vast majority of domain owners, ARC is therefore provider-managed: Google, Microsoft and the major security gateways add ARC for you. Your only ARC-related decision is on the receiving side — which sealers you choose to trust.

Who uses ARC, and its limits

ARC is used in production by Google (Gmail, Workspace and Groups), Microsoft (Exchange Online and Defender, with a configurable list of trusted ARC sealers), the major security gateways such as Proofpoint and Mimecast, and modern mailing-list managers. But it has real limits. An ARC pass does not guarantee inbox placement — it can rescue a DMARC failure, but spam, bulk and content filtering still apply. It carries no reputation data of its own. And because chains can be forged, trusting the wrong sealer expands your attack surface, so trust should be granted sparingly and reviewed periodically.

A real-world ARC scenario

Picture a subscriber who belongs to an industry mailing list. You send a message that passes SPF, DKIM and DMARC perfectly. It arrives at the mailing list server, which appends a “you are receiving this because…” footer and a subject-line tag, then relays the message to every member from its own servers. By the time your message reaches another member’s mailbox, two things have happened: the body changed (breaking your DKIM signature) and the sending IP is the list’s, not yours (breaking SPF). Plain DMARC now fails, and under a strict DMARC policy that legitimate message would be quarantined or rejected.

This is exactly where the authenticated received chain earns its place. The mailing list, acting as an ARC participant, recorded that your message passed authentication before it made its changes, and sealed that result into the message. The receiving server sees the broken SPF and DKIM, but it also sees an intact ARC chain from a list it trusts, and it uses the sealed “this was authentic on arrival” verdict to deliver the message anyway. Without ARC, well-run mailing lists would either mangle every member’s From address or quietly lose mail to DMARC — which is why the protocol was created.

Trusting ARC sealers on the receiving side

If you operate inbound mail — for example through Microsoft 365 — the one ARC decision you genuinely make is which sealers to trust. A receiver will only let an ARC chain override a DMARC failure if it trusts the party that sealed it, because an untrusted or forged chain must not be allowed to rescue spoofed mail. Platforms therefore let you maintain a list of trusted ARC sealers, identified by the signing domain in their ARC-Seal headers.

Treat that list with care. Add a sealer only when you have a concrete reason — typically a security gateway in front of your mail flow, or a mailing-list service your users rely on — and always confirm the real signing domain from an actual ARC-Seal header rather than guessing or entering your own domain. Every trusted sealer is, in effect, a party you are allowing to vouch for mail that otherwise failed DMARC, so review the list periodically and keep it as short as it can be. This is the receiving-side counterpart to getting your own SPF, DKIM and DMARC right, which our authentication hub covers in order.

ARC email authentication best practices

• Fix the basics first. ARC only helps once SPF, DKIM and DMARC are correct at the source — see the setup order in our authentication hub.
• Trust sealers sparingly. On the receiving side, add a trusted sealer only when you have a clear reason, and verify the real signing domain from the actual ARC-Seal header rather than guessing.
• Verify via headers. A rescued message typically shows arc=pass in the authentication results; inspect the cv= value of each instance to confirm an intact chain.
• Treat ARC as provider-managed. For most senders there is nothing to “install” — the value is understanding it, not configuring it.
• Keep it in perspective. ARC supplements DMARC for indirect mail; it does not replace any of the core standards or improve your deliverability on its own.

The limits and future of ARC

For all its usefulness, it is important to keep ARC email authentication in proportion. RFC 8617 is an Experimental specification, not a ratified standard, even though Google and Microsoft run it in production. An intact ARC chain conveys a prior authentication verdict, but it carries no reputation of its own and offers no guarantee of inbox placement — a message can have a flawless chain and still be filtered as spam on content or volume grounds. And because the entire mechanism rests on trust in the sealer, it is only as strong as your discipline about which sealers you trust: an over-broad trust list lets a compromised or malicious intermediary launder spoofed mail past your DMARC policy. ARC reduces false rejections of legitimate indirect mail; it does not harden your domain against impersonation the way DMARC at enforcement does.

There is also active debate about ARC’s future. The standards community has discussed folding its ideas into a next-generation signing scheme sometimes referred to as “DKIM2,” which could eventually supersede the current approach. Nothing is settled — RFC 8617 has not been obsoleted, and the major providers continue to rely on it — but it is a reminder that this corner of email authentication is still evolving. For the foreseeable future the right posture is the one this guide describes: get SPF, DKIM and DMARC correct at the source, let your provider handle ARC sealing, and trust sealers sparingly on the receiving side.

Check it yourself: paste a message’s raw headers into our free email header analyzer to see its Authentication-Results and ARC chain, all in your browser.

Related reading

• Email authentication statistics 2026
• SPF records guide
• DKIM records guide
• DMARC records guide
• MX records guide

ARC email authentication FAQ

Do I need to set up an ARC DNS record?

No. ARC is not published as a DNS record. It is a set of headers that intermediaries add and sign with their own DKIM keys; the only DNS involved is the sealer’s DKIM key record. For most domain owners ARC is handled entirely by their email provider.

Does ARC replace SPF, DKIM and DMARC?

No. ARC supplements them. Its job is to rescue legitimate forwarded and mailing-list mail that would otherwise fail DMARC, by preserving the authentication results from when the message was first sent. The core standards still do the actual authenticating.

What are the three ARC headers?

They are the ARC-Authentication-Results (the SPF/DKIM/DMARC results seen at that hop), the ARC-Message-Signature (a DKIM-style signature over the message), and the ARC-Seal (a signature binding the whole chain together with a cv= validity value).

Does an ARC pass guarantee my email reaches the inbox?

No. A valid ARC chain from a trusted sealer can override a DMARC failure, but spam, bulk and content filtering still apply. ARC restores an authentication verdict; it does not bypass the rest of a receiver’s filtering.

Who actually implements ARC — me or my provider?

Almost always your provider or the intermediary. Google, Microsoft and major security gateways seal messages automatically. Your only ARC action, if any, is choosing which sealers to trust on the receiving side.

What does cv=fail mean in an ARC header?

It means a prior seal in the chain could not be verified — usually because the message was modified after sealing, or because of a DNS or key-rotation problem. A chain marked cv=fail is considered broken and cannot be used to override a DMARC failure, so the message falls back to being judged on its plain SPF, DKIM and DMARC results alone, exactly as if no ARC chain were present.