ARC Email Authentication: How It Rescues Forwarded Mail

ARC (Authenticated Received Chain) is a protocol, published as RFC 8617 in July 2019, that lets forwarders and mailing lists record the SPF, DKIM and DMARC results a message had when they received it, and sign that record. A later receiver can then trust that the message authenticated before it was modified. ARC does not make anyone trusted on its own: each receiver decides which sealers it believes.

That last point is the one most explanations skip. ARC is plumbing for carrying evidence, not a pass that overrides DMARC. Below is how the chain works, using the RFC's own example, and what Google and Microsoft say they do with it.

The problem ARC exists to fix

Forwarding and mailing lists break DMARC for legitimate mail, because they change either the sending IP or the message. The IETF documented this in RFC 7960 (Informational, September 2016), which describes the trap forwarders are in:

"If the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email infrastructure. If the forwarder replaces the RFC5321.MailFrom with its own domain, SPF might pass, but Identifier Alignment with the RFC5322.From header field will fail."

DKIM normally survives plain forwarding, because the signature travels with the message. Mailing lists are a different story. RFC 7960 lists the usual changes: prefixing the Subject with a list tag, "adding a footer to the email body to contain administrative instructions", and removing MIME parts. Any of those invalidates the DKIM signature.

With SPF failing alignment and DKIM broken, a domain with p=reject gets its mail rejected when it reaches a list member, through no fault of its own. If you need a refresher on why alignment is the deciding factor, see the DMARC glossary entry and our guide to moving DMARC from p=none to p=reject, where mailing lists are one of the main things that break.

The three ARC headers

Each intermediary adds one "ARC set" of three headers, numbered with the same instance value. RFC 8617 defines them as:

Header	Short name	What it holds
ARC-Authentication-Results	AAR	The authentication results this intermediary saw on arrival (SPF, DKIM, DMARC, and any earlier ARC result)
ARC-Message-Signature	AMS	A DKIM-style signature over the message as this intermediary passes it on, including any changes it made
ARC-Seal	AS	A signature over all the ARC headers so far, plus the cv= chain validation status

Google's ARC page for Workspace admins describes the same three parts in plainer words: the results header "indicates the forwarding server's DKIM and SPF results", the message signature is "a DKIM message signature" over the message, and the seal "adds a DKIM signature for all three ARC headers".

The i= instance tag

The i= tag ties the three headers of one set together and records the order of hops. RFC 8617 says instance values "are integers that begin at 1 and are incremented by each addition of an ARC Set", with a valid range of 1 to 50. The first intermediary writes i=1, the next i=2, and so on. Each set must contain exactly one of each header.

The cv= chain validation tag

Only the ARC-Seal carries cv=, and it has exactly three values. From the RFC:

• cv=none: there was no chain when the message arrived. This must be the value on the first set (i=1).
• cv=pass: the intermediary validated the existing chain. Every later set in a healthy chain carries pass.
• cv=fail: validation failed. Once a chain has failed, it stays failed. The RFC adds that during validation "all errors, including DNS failures, become unrecoverable and are considered permanent."

A real example, from the RFC

The clearest genuine ARC headers available are the ones in RFC 8617's appendix, so here is its third-hop set, unedited.

ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
        clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
        +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
        clochette.example.org; h=message-id:date:from:to:subject; s=
        clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
        LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
        K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
    smtp.from=jqd@d1.example; dkim=fail (512-bit key)
    header.i=@d1.example; dmarc=fail; arc=pass

Read it the way a receiver would. At the third hop, SPF, DKIM and DMARC all fail against the original domain d1.example. But arc=pass and cv=pass say the two earlier sets validated. A receiver that trusts the sealers at i=1 and i=2 can look back at the first AAR to see what the message's authentication looked like before anything touched it.

To find these headers in your own mail, open the raw source and search for ARC-Seal. Our guide to reading email headers explains where they sit relative to the Received lines.

How validation works

A receiver checks the chain from the newest set backwards, and any break fails the whole chain. RFC 8617's algorithm, condensed:

1. Collect every ARC set. More than 50 is a failure.
2. If the newest ARC-Seal already says cv=fail, stop: the chain is failed.
3. Check the structure: instances run 1 to N with no gaps, i=1 says cv=none, and every later seal says cv=pass.
4. Validate the newest ARC-Message-Signature against the message as received.
5. Optionally, validate older AMS headers to find the oldest hop where the message was still intact.
6. Validate every ARC-Seal, newest to oldest.
7. If all of that holds, the chain passes.

Notice what is not in the list: anything about whether the sealers are honest. The RFC says it directly: "ARC is not a trust framework," and ARC "authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness." A spammer can produce a perfectly valid ARC chain for mail it forged at hop one.

What Google says about ARC

Google documents ARC for Workspace admins, but its forwarding advice centres on SPF and DKIM. The Workspace ARC page explains that ARC helps "by saving previous authentication results for forwarded messages, verifying forwarding servers, and adding headers to messages to indicate message authentication status." It is equally clear about the limits. ARC does not:

• "Evaluate or provide information about sender and forwarder reputation."
• "Prevent forwarding servers from adding harmful content to messages."
• "Prevent forwarding servers from removing ARC headers from messages."

Google's best practices for forwarding email to Gmail, checked on 7 October 2026, do not mention ARC at all. They tell forwarders to "change the envelope sender to reference your forwarding domain", set up SPF and DKIM for that domain, and "avoid changing the body and message headers protected by DKIM". Several blog posts claim Google requires ARC from forwarders. We could not find that requirement on Google's current pages, so we are not repeating it.

What Microsoft 365 does: trusted ARC sealers

Microsoft 365 only uses an ARC result to override a DMARC failure when an admin has named the sealer as trusted. Microsoft's trusted ARC sealers documentation explains the setting for organisations whose inbound mail passes through a service that modifies it, such as a security gateway, before it reaches Exchange Online.

The setup is a list of signing domains. In the Defender portal it lives under Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > ARC, and in PowerShell:

Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"

Three points from Microsoft's page are worth knowing:

• The domain to add is the vendor's d= in the ARC-Seal, not your own domain. Microsoft lists adding your own domain as a common mistake.
• -ArcTrustedSealers replaces the whole list. Include existing entries when adding a new one.
• Success shows up as compauth=pass reason=130 in the Authentication-Results header, with arc=pass and oda=1 in the ARC-Authentication-Results.

Microsoft also notes that ARC "overrides DMARC authentication failures only". It does not bypass spam filtering, bulk filtering or anti-spam policy, so a message can pass ARC and still land in Junk.

What this means if you send email

If you are the original sender, ARC is not something you configure, and it will not fix your own authentication. It is added by forwarders, lists and gateways downstream. What you control:

1. Sign with DKIM using your own domain, so there is a signature for an ARC-aware intermediary to record. Check it with the DKIM checker.
2. Publish DMARC and understand what it will do to forwarded mail before you move to p=reject. The rua aggregate reports show forwarded traffic failing from IPs you do not recognise, and those failures are often the cases ARC exists for.
3. Do not treat an ARC pass as proof your setup is fine. If mail fails DMARC on direct delivery, ARC cannot help, because there is no earlier passing result to carry.

If you run a forwarder or a mailing list, enable ARC sealing in your MTA or list software if it supports it. On a list, rewriting the From address to the list's own domain is the fallback RFC 7960 discusses for domains with strict DMARC policies. You can confirm what a domain publishes with the DMARC checker.