What is ARC (Authenticated Received Chain), and how does it work?

Forwarding and mailing lists break SPF, and often DKIM, so legitimate mail fails DMARC through no fault of the sender. ARC, the Authenticated Received Chain, is the protocol designed to carry the original authentication results across those hops. This guide explains what each ARC header does, how a chain is validated, how Microsoft 365 and Gmail use it, and its limits. For why forwarding breaks authentication in the first place, and the step-by-step trusted sealer setup in Microsoft 365, read why email forwarding breaks SPF and DMARC first.

What problem does ARC solve?

When a message passes through an intermediary, the final receiver sees the intermediary's IP address, so SPF fails. If the intermediary edits the message, adding a subject tag, a footer or a warning banner, the original DKIM signature fails too. DMARC then fails, and the sender's p=quarantine or p=reject policy may junk or bounce a message that was genuine when it left.

The final receiver has no way to know the message was fine two hops ago. ARC fixes that information gap. Each intermediary that supports ARC records what it saw when the message arrived, signs the message as it leaves, and seals both into a chain. RFC 8617 describes the result as an authenticated "chain of custody" that lets each handler "see what entities handled it before and what the message's authentication assessment was at each step".

Microsoft summarizes it the same way: ARC "preserves original email authentication information by known services that modify messages in transit", which a receiver "can use ... to authenticate messages that would otherwise fail DMARC".

What are the three ARC headers?

Each intermediary adds three headers together, which RFC 8617 calls an ARC Set. Every header in a set carries the same instance number, i=, starting at 1 for the first sealer and going up by one at each hop. Instance values range from 1 to 50, and RFC 8617 caps a message at 50 ARC Sets.

A few details matter when you read them:

• The AMS has "the same syntax and semantics as the DKIM-Signature field", with an instance tag instead of DKIM's i= user identifier. RFC 8617 says it should be added as the message leaves, so it covers the intermediary's own edits, and it SHOULD include any existing DKIM-Signature headers.
• The ARC-Seal doesn't cover the body and has no bh= tag. It uses only relaxed header canonicalization, and an h= tag in a seal makes the chain fail.
• Both signatures use the sealer's own domain in d= and a public key published in DNS, just like DKIM. Nothing in ARC needs to match your From domain.

A sealed message might carry headers like these (shortened):

ARC-Seal: i=1; a=rsa-sha256; d=list.example.org; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example.org; s=arc1;
  h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; mx.list.example.org;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com; dmarc=pass header.from=example.com

How is an ARC chain validated?

Each new sealer, and the final receiver, checks the chain it received before trusting it. The ARC-Seal's cv= tag records the result:

Failure is final. RFC 8617 says "once broken, the chain cannot be continued", that a message whose chain status is fail must be treated the same as one with no chain at all, and that all errors, "including DNS failures, become unrecoverable and are considered permanent". A receiver records the overall result in its own Authentication-Results header as arc=pass, arc=fail or arc=none. If a validator refuses the message over it, RFC 8617 lets it signal the failure with the enhanced status code 5.7.29, "ARC validation failure", or the more general 5.7.26.

The most common causes of a broken chain, per Microsoft's troubleshooting guidance, are a hop that modified the message after an earlier seal, a DNS problem fetching a sealer's key, and a key that was rotated while old records were still cached.

How do receivers use ARC results?

A valid chain proves which domains handled the message and what they claimed to see. It doesn't prove those domains are honest. RFC 8617 says plainly: "ARC is not a trust framework," and "It does not make any assessment of their trustworthiness."

So the decision is local. RFC 8617 says that "as a matter of local policy, a DMARC processor MAY choose to accept the authentication assessments provided by an Authenticated Received Chain". In practice, a receiver uses an ARC result only when the chain passes and it trusts the sealer, usually the most recent one. When ARC changes a DMARC decision, RFC 8617 suggests reporting it in DMARC aggregate reports as a local_policy override with a comment listing the chain status and sealers. You'll see these in your DMARC reports.

Microsoft 365: trusted ARC sealers

Microsoft 365 lets admins name the sealers it should trust. Our forwarding guide has the portal path and the Set-ArcConfig command. Here's how to interpret the results once it's set up, from Microsoft Learn:

Microsoft is careful about scope. "ARC overrides DMARC authentication failures only." It doesn't bypass spam filtering, bulk filtering, anti-spam policy actions, mail flow rule actions or safe and blocked sender lists. And it warns that adding unnecessary sealers "increases your attack surface because a compromised vendor could pass spoofed messages through your authentication checks." If an intermediary in front of Microsoft 365 doesn't seal at all, Microsoft points to Enhanced Filtering for Connectors instead.

Gmail and Google Workspace

Google's ARC page describes the standard: ARC saves "previous authentication results for forwarded messages", verifies forwarding servers, and adds headers showing authentication status. It also lists three things ARC does not do: evaluate "sender and forwarder reputation", prevent forwarding servers "from adding harmful content", or prevent them "from removing ARC headers".

At the time of writing (October 2026), Google publishes no admin setting for trusted sealers and doesn't say which sealers Gmail trusts. Its current forwarding best practices for administrators don't mention ARC at all. Instead they ask forwarders to:

1. Change the envelope sender to reference the forwarding domain, and cover forwarding servers in SPF.
2. Avoid breaking DKIM: don't modify the subject, the body, MIME boundaries or signed headers such as To, Cc, Date and Message-ID.
3. Add an X-Forwarded-For: or X-Forwarded-To: header so receivers know the message was forwarded.
4. Filter spam before forwarding it.

Google also notes that "Gmail doesn't automatically authenticate forwarded messages that previously passed authentication" and runs its own checks. Treat ARC as a help at Gmail, not something you can configure or count on.

What are ARC's limits?

• It's experimental. RFC 8617 is an Experimental RFC from 2019. RFC 9989, the current DMARC standard, names ARC as the prominent attempt to keep mailing lists working without rewriting From, then adds that "none of the methods have become widely used." Rewriting From is still the workaround lists rely on; see DMARC and mailing lists.
• Trust is the hard part. RFC 8617 tells recipients to "treat every Sealer of the ARC Chain with suspicion", so that "a malicious actor cannot seal spam or other fraudulent messages to aid their delivery, too."
• It says nothing about safety. RFC 8617 notes that "forwarding that information through the mechanism of ARC is also not an indication of message safety."
• It needs every hop. One intermediary that modifies mail without sealing, or strips ARC headers, leaves later receivers with nothing to use.
• It only helps indirect mail. If your own services send without aligned DKIM, ARC can't fix that. Start with DKIM for your own domain.

Who should add ARC seals?

How to check ARC on a real message

1. Get the full headers of a message that went through a forwarder or list. Paste them into the Email Header Analyzer, which runs in your browser, or follow how to read email headers.
2. Find every ARC-Seal. Note each i= and d=. The highest instance is the most recent sealer.
3. Read each cv=. The first fail tells you which hop broke the chain.
4. Read the matching ARC-Authentication-Results to see what that sealer saw on arrival, especially dkim= and dmarc= for the original sender.
5. Check the final Authentication-Results for arc= and, in Microsoft 365, compauth and reason.
6. If the sealer's key lookup failed, check its selector with the DKIM Checker; ARC keys live under _domainkey like DKIM keys.

Next steps

• Make sure every service sending as your domain signs with aligned DKIM, then check your policy with the DMARC Checker.
• If Microsoft 365 users receive mail through a list or service that seals, add that sealer's d= domain as a trusted ARC sealer, and nothing more.
• Look for local_policy, mailing_list and trusted_forwarder overrides in your reports with the DMARC Report Analyzer.
• If you use iBlockSpam for inbound filtering in front of Microsoft 365, the guided setup configures the inbound connector with Enhanced Filtering for Connectors, so Microsoft evaluates the original sender.

Browse our other SPF, DKIM and DMARC guides.