---
title: "ARC Email Authentication: Forwarded Mail in 2026"
description: "ARC email authentication preserves SPF, DKIM, and DMARC verdicts across forwarding hops in 2026. See real i=1 and i=2 headers, cv=fail debugging, and trusted-sealer fixes. Analyze a chain free."
publishedAt: 2026-04-29
tags: ["arc", "email-authentication", "dmarc", "forwarding", "rfc-8617"]
faq:
  - question: "What is ARC in email authentication?"
    answer: "ARC is the Authenticated Received Chain, defined in RFC 8617 (Experimental, 2019). It records SPF, DKIM, and DMARC verdicts at each forwarding hop and binds them cryptographically. The IETF rechartered the DMARC working group on 2026-04-16 to move ARC to Historic by November 2026."
  - question: "How does the ARC chain actually work?"
    answer: "Each hop runs SPF, DKIM, and DMARC, writes the verdict into an ARC-Authentication-Results header, signs the body with an ARC-Message-Signature, and signs prior chain state with an ARC-Seal. The cv= tag records chain validity, and a trusted-sealer override is possible when every link validates."
  - question: "What are the three ARC headers?"
    answer: "ARC-Authentication-Results snapshots SPF, DKIM, and DMARC verdicts at this hop. ARC-Message-Signature is a DKIM-style signature over the body and a chosen header list. ARC-Seal is the chain-binding signature with a cv= tag — none at i=1, pass when the prior chain validated, fail when not."
  - question: "What does cv=fail mean in an ARC chain?"
    answer: "cv=fail is a deliberate signal. A relay that validates the prior chain and detects malformation must seal cv=fail and stop signing prior state, forcing downstream receivers to write arc=fail. Common causes are body-hash mismatches, missing AAR fields, and broken canonicalization upstream."
  - question: "Is ARC the same as DMARC?"
    answer: "No. DMARC is the policy a receiver applies — quarantine, reject, or monitor. ARC (RFC 8617) is the chain-of-custody metadata that lets the DMARC verdict survive forwarder modification. DMARC decides; ARC preserves the evidence."
  - question: "Is ARC being deprecated by the IETF?"
    answer: "Yes at the chartering layer, no in operation. The DMARC working group was rechartered on 2026-04-16 to move RFC 8617 to Historic by November 2026 or close. Gmail, Microsoft 365, and Apple iCloud continue honoring ARC."
  - question: "Do I need to set up ARC for my domain?"
    answer: "Individual domain owners do not configure ARC. Forwarders seal it; receivers validate. Domain owners publish DMARC and align DKIM. Forwarder operators can use Mailman 3.3.8+, OpenARC, rspamd, or Halon."
---
# ARC Email Authentication in 2026: How Forwarded Mail Actually Passes DMARC

A Microsoft Q&A thread from February 2024 shows a forwarded message landing in
Outlook.com with `arc=fail (47)` — a numeric error Microsoft has never
documented
([learn.microsoft.com](https://learn.microsoft.com/en-us/answers/questions/1533705/arc-failures-when-delivering-to-my-outlook-com-acc),
2024-02-15). The thread is still unanswered, and it is the shape of every ARC
email authentication question reaching admins today: a chain validated
upstream, broke downstream, produced a verdict the receiver refuses to explain.

ARC email authentication is the chain-of-custody mechanism defined in
[RFC 8617](https://datatracker.ietf.org/doc/html/rfc8617) (Experimental) that
lets forwarders preserve SPF, DKIM, and DMARC verdicts across hops — and as of
April 2026 the IETF has rechartered the DMARC working group specifically to
retire it. ARC is a hard bulk-sender requirement at iCloud (since 2025-02-25),
a forwarder requirement at Gmail, and a configurable trust anchor at Microsoft
365. Across the 5,499,028 domains DMARCguard scanned through 2026, 12.8%
(702,000) publish DMARC at `p=quarantine` or `p=reject` — every one will
reject forwarded mail without aligned DKIM or a trusted ARC chain (denominator
math:
[State of Email Authentication 2026](/research/email-authentication/)).

This post walks the three ARC headers through a real two-hop chain, debugs
common `cv=fail` symptoms, and covers where the IETF is taking ARC next. For
foundations, see
[the full RFC 8617 protocol breakdown](/learn/arc/).

## What ARC Email Authentication Actually Is

ARC email authentication, formally the Authenticated Received Chain, is
specified in
[RFC 8617](https://datatracker.ietf.org/doc/html/rfc8617) (Experimental,
September 2019). At every intermediate mail server that forwards a message,
ARC writes three new headers recording what the host saw for SPF, DKIM, and
DMARC, and binds those statements cryptographically to every prior hop's. A
downstream receiver that trusts the sealer can read the chain, see the
original verdict, and override a late-hop authentication failure.

ARC is RFC 8617 Experimental, not Standards Track — a distinction that matters
for the deprecation discussion later.

ARC and DMARC do not overlap. DMARC is the policy a receiver applies to an
unaligned message; ARC is the chain-of-custody metadata that lets the policy
survive forwarder modification. DMARC decides; ARC says what authentication
looked like before the relay touched the message.
[How DMARC evaluates forwarded messages](/learn/dmarc/) covers alignment
mechanics.

## How the ARC Chain Works in 2026

The arc protocol turns a sequence of forwarders into a verifiable chain. Each
hop runs SPF, DKIM, and DMARC; writes the verdict into an
ARC-Authentication-Results (AAR) header; signs the body and headers with an
ARC-Message-Signature (AMS); and signs all prior chain state plus its own AAR
and AMS with an ARC-Seal (AS). The instance counter `i=1` marks the chain
origin, `i=2` the second hop.

The `cv=` evolution is the most informative part of the chain. At `i=1` no
predecessor exists, so the seal carries `cv=none`. Later hops that validate
the prior chain seal `cv=pass`. A relay that detects malformation upstream
must seal `cv=fail` and stop signing the prior chain — `cv=fail` is a
deliberate signal, not an accident. Postmark's production capture shows
Gmail's outbound `arc-20160816` selector signing a clean i=1 set
([postmarkapp.com](https://postmarkapp.com/blog/what-is-arc-or-authenticated-received-chain)).

A receiver validates the chain from the highest `i=N` backwards and trusts the
i=1 AAR only if every link validates and the sealer is on the trust list.
This applies to any
[forwarded-mail DMARC failure pattern](/blog/dmarc-forwarding-arc-fix/) that
breaks SPF at the first hop.

<Figure
  src="/images/blog/arc-email-authentication/arc-email-authentication_chain-validation-flow_diagram.svg"
  alt="Three stage cards labeled Hop 1 (i=1, cv=none), Hop 2 (i=2, cv=pass), and Final receiver. Each shows the AAR/AMS/AS triple with arrows depicting that each AS covers all prior seals plus the current hop's AAR and AMS. Teal indicates pass, red indicates cv=fail, amber indicates cv=none."
  caption="Each ARC-Seal covers every prior seal plus the current hop's AAR and AMS. The receiver validates from i=N backwards."
/>

## Real ARC Headers — A Two-Hop Chain

The arc email header set is three headers per hop. Diagnostic value lives in
the AAR; cryptography in the AMS and AS.

### ARC-Authentication-Results

The arc-authentication-results header is the diagnostic line. Each hop writes
one with its instance counter, authserv-id, and the verdicts that hop saw. A
Postmark-to-Gmail single-hop capture shows
`i=1; mx.google.com; dkim=pass header.i=@postmarkapp.com ... spf=pass ...
dmarc=pass`.

<CodeBlock
  lang="email"
  filename="ARC-Authentication-Results — Postmark→Gmail single hop, i=1"
  code={aarPostmarkGmail}
/>

The `i=` field is the instance counter, the authserv-id is the verifying host,
and the DKIM evaluation lists signing domain, selector, and the first eight
bytes of `b=`.

### ARC-Message-Signature

The arc-message-signature is a DKIM-style signature over the body and a chosen
list of headers, including the AAR itself. `a=rsa-sha256` is the algorithm,
`c=relaxed/relaxed` is canonicalization, `d=` and `s=` identify signing domain
and selector, `h=` lists covered headers, `bh=` is the body hash, `b=` the RSA
signature. Any whitespace difference downstream produces a `bh=` mismatch, and
the next sealer must seal `cv=fail` — list footers, gateway banners, and
quoted-printable re-encoding all break the body hash.

### ARC-Seal

The arc-seal email header makes ARC a chain instead of three independent
signatures. The AS at hop N covers the AAR and AMS at this hop plus every
prior AS. Tags: `a=`, `d=`, `s=`, `t=` (Unix timestamp), `cv=` (chain
validity), `b=` (signature over the seal graph).

### A two-hop chain end-to-end (i=1 then i=2)

Brian Reid's c7solutions trace captures the canonical Microsoft 365 →
Mimecast → Microsoft 365 path where the tenant has marked Mimecast as
Trusted. The most recent set sits at the top; `i=1` deepest. Reading top-down
reads backwards through time
([c7solutions.com](https://c7solutions.com/2022/06/improving-exchange-online-email-deliverability-through-third-party-filtering-services-trusted-arc-senders)).

<CodeBlock
  lang="email"
  filename="Two-hop ARC chain — Microsoft 365 → Mimecast → Microsoft 365 (annotated)"
  code={twoHopChain}
/>

Three Microsoft tokens appear in the final hop. `oda=1` is Override DMARC
Allowed — Microsoft confirms it means "previous ARC has been verified, the
previous ARC sealer is trusted, and previous pass result can be used to
override the current DMARC failure." `ltdi=1` is an empirical co-indicator.
`compauth=pass reason=130` confirms the trusted-sealer override fired.

<Figure
  src="/images/blog/arc-email-authentication/arc-email-authentication_two-hop-headers_diagram.svg"
  alt="Three stacked annotated cards showing the i=1 AAR from Mimecast, the i=2 AAR from Microsoft 365, and the final Authentication-Results line, with callouts for oda=1, ltdi=1, and compauth=pass reason=130."
  caption="Top card is the final receiver's verdict; bottom card is what the chain origin saw. The middle band carries the trusted-sealer override fingerprint."
/>

Paste forwarded headers into our
[ARC chain analyzer](/tools/arc-chain-analyzer/) and see the AAR, AMS, and AS
at every hop with `cv=` per seal — no signup.

## Trusted ARC Sealers in Microsoft 365, Gmail, and the Rest

Trusted arc sealers behavior is not uniform. Microsoft 365 exposes a
tenant-editable trust list. Gmail validates ARC implicitly and copy-forwards
the verdict in a documented comment. Yahoo, Fastmail, and Proton each take a
different position.

### Microsoft 365 — the only tenant-editable trust list

Microsoft Learn's "Configure trusted ARC sealers" page (last updated
2026-02-11) is authoritative
([learn.microsoft.com](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-arc-configure)).
Microsoft: "The ARC result pass from a trusted ARC sealer can potentially
override failures in SPF, DKIM, or DMARC caused by message modification during
transit." Success fingerprint: `arc=pass`, `oda=1`, `ltdi=1`, `compauth=pass
reason=130`.

`compauth=none reason=452` means the chain was present but bypassed — sealer
not on the trust list, or `oda=0` blocked the override. For broader
[Microsoft 365 DMARC enforcement](/blog/microsoft-dmarc-enforcement/),
indirect mail flow rules apply. Configure via the `Set-ArcConfig` PowerShell
cmdlet.

<CodeBlock
  lang="powershell"
  filename="Microsoft 365 — add a trusted ARC sealer and verify"
  code={m365PowerShell}
/>

### Gmail — implicit trust, copy-forward signaling

Gmail validates ARC on every inbound message and writes the result into
Authentication-Results from `mx.google.com`. Production captures show three
forms: minimal `arc=pass (i=N)`, full `arc=pass (i=N spf=... dkim=... dmarc=...
fromdomain=...)` copy-forwarding the trusted chain's results, or `arc=fail
(...)` when the chain breaks. The parenthesized comment is the load-bearing
diagnostic.

Gmail's bulk-sender rules (February 2024) require forwarders sending more than
5,000 messages per day to ARC-seal
([support.google.com](https://support.google.com/mail/answer/81126)). Apple
iCloud went further on 2025-02-25, making ARC headers a hard rejection trigger
([support.apple.com](https://support.apple.com/en-us/102322)). ARC sits inside
the joint
[Google's bulk-sender enforcement](/blog/google-yahoo-dmarc-requirements/)
rule set.

### Yahoo, Fastmail, and Proton

Yahoo recommends ARC for forwarders but uses no documented `arc=` token in
published Authentication-Results. It also publishes ARF feedback loops;
[what abuse reports look like alongside ARC](/blog/what-is-arf/) is a separate
piece of the deliverability picture. Fastmail has sealed ARC since October
2018. Bron Gondwana (Fastmail) at the IETF: "Fastmail ALSO adds ARC headers
and verifies ARC, but (still) doesn't treat it as having any spam prediction
value."

## Debugging cv=fail and arc=fail in the Wild

When ARC email authentication failed in your aggregate reports, the reason
string is the primary debugging hook. Most failures resolve to one of five
patterns.

### Symptom matrix — read the reason string first

| Symptom                            | Root cause                                                                            | Fix                                          |
| ---------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------- |
| `arc=fail (signature failed)`      | AS or AMS broke at the relay; relay re-canonicalized headers after signing            | Sign after every body modification           |
| `arc=fail (missing mandatory fields)` | AAR omits a DKIM signature the receiver can verify (Microsoft `arcselector9901`)   | Enumerate every signature in the AAR         |
| `arc=fail (body hash mismatch)`    | Forwarder modified the body after AMS computed; Mailman pre-3.3.6 regression          | Mailman 3.3.8+; sign after personalization   |
| `arc=fail (47)` / `arc=fail (35)`  | Microsoft-specific, undocumented codes; first sighted in 2020 mailman-users archive   | Observed-but-undocumented; rebuild from i=1  |
| `compauth=none reason=452`         | Chain present but Microsoft bypassed it; sealer not on tenant trust list, or `oda=0` | Add the legitimate sealer via `Set-ArcConfig` |

OpenARC issue
[#128](https://github.com/trusteddomainproject/OpenARC/issues/128) captures
`arc=fail (missing mandatory fields)` on a Hotmail → OpenARC → Gmail chain
where the i=1 AAR did not enumerate the DKIM signature Gmail could verify
independently.

<CodeBlock
  lang="email"
  filename="OpenARC #128 — arc=fail (missing mandatory fields) on Hotmail→OpenARC→Gmail"
  code={cvFailOpenarc}
/>

<Figure
  src="/images/blog/arc-email-authentication/arc-email-authentication_cv-fail-symptom-matrix_table.svg"
  alt="Five-row comparison grid mapping each cv= or arc= failure symptom (signature failed, missing mandatory fields, body hash mismatch, arc=fail 47, compauth=none reason=452) to its root cause and remediation."
  caption="Read the parenthesized reason string first — it points at the breaking hop."
/>

### Forwarder failure modes worth knowing

Apple Hide My Email and Firefox Relay break ARC by design — both strip
authentication headers in ways that invalidate the chain
([gangw.cs.illinois.edu](https://gangw.cs.illinois.edu/arc-www22.pdf)). GNU
Mailman 3 shipped a body-hash regression fixed in 3.3.6 on 2022-10-26, not
3.3.5 as commonly stated. The
[forwarding-induced DMARC failure playbook](/blog/dmarc-failed-how-to-fix/)
covers the surrounding workflow. Or
[check ARC headers on a single message](/tools/arc-checker/) for a quick look
at the chain's shape.

## Is ARC Being Deprecated? The IETF arc-to-historic Story

ARC is on a documented IETF glide path. The headline "ARC is being deprecated"
is true at the chartering layer and false in operational reality. Both
statements need to coexist in any honest 2026 explainer.

### What changed in the last 90 days

On 2025-12-04, J. Trent Adams (Proofpoint) and John R. Levine (Taughannock
Networks) posted
[`draft-adams-arc-experiment-conclusion-01`](https://datatracker.ietf.org/doc/draft-adams-arc-experiment-conclusion/)
to the IETF datatracker (Informational, expiring 2026-06-07). On 2026-01-30
Adams proposed a recharter; on 2026-04-16 the IESG issued the
[WG Action: Rechartered](https://datatracker.ietf.org/doc/charter-ietf-dmarc/writeup/)
announcement.

The chartering language is bluntly worded. ARC "has enjoyed neither noteworthy
uptake nor sufficient impact, though it continues to develop momentum that is
believed to be unsupportable by evidence." The working group must produce the
status-change document by November 2026 or close.

### Two events, often conflated — keep them separate

Event 1 is the working group producing an adopted status-change document by
November 2026. Event 2 is `RFC 8617` reclassified to Historic in the RFC
index — earliest plausible late Q4 2026 to Q1 2027 (the draft asks for
"Obsolete" but the charter requires "Historic," which are different IETF
mechanisms).

Operator behavior is bound to neither event. No major mailbox provider has
committed in the IETF record to a dated end of ARC honoring. Gmail and
Microsoft 365 will continue validating chains they already process. The IETF
is telling implementers to stop adding new ARC reliance, not forcing receivers
to remove deployed code. DKIM2 picks up where ARC leaves off in
[the future-state companion](/blog/arc-to-dkim2-future/), publishing
2026-05-04.

## Why ARC Matters Right Now (Despite the Retirement Plan)

Across the 5,499,028 domains DMARCguard scanned through 2026, 12.8% publish
DMARC at `p=reject` or `p=quarantine`. Public crawls reach the same
denominator differently — Fortra reported 7.6% enforcement across the top 10
million domains in Q2 2025
([fortra.com](https://emailsecurity.fortra.com/blog/dmarc-adoption-trends-q2-2025)),
and Red Sift recorded 2.5% at `p=reject` across 73.3 million apex domains in
December 2025
([redsift.com](https://redsift.com/guides/red-sifts-guide-to-global-dmarc-adoption)).
The denominators differ; do not treat these as ranked. DMARCguard's scanner
reflects domains submitted to our lookup tool — a self-selected investigator
audience, not a random sample of the internet.

We cannot tell you the percentage of forwarded mail today carrying valid ARC
headers, because no one publishes that number. Wang and Wang's WWW 2022 paper
sampled a single disposable-inbox service and found 23.2% ARC carriage in
November 2020 and 13.4% in November 2021 — the authors describe their own
data as "not necessarily representative." Mailbox providers do not release
chain-validation telemetry, and unlike DMARC, ARC cannot be observed via DNS.

## Frequently Asked Questions

### What is ARC in email authentication?

ARC is the Authenticated Received Chain, defined in `RFC 8617` (Experimental,
2019). It records SPF, DKIM, and DMARC verdicts at each forwarding hop and
binds them cryptographically. The IETF rechartered the DMARC working group on
2026-04-16 to move ARC to Historic by November 2026.

### How does the ARC chain actually work?

Each hop runs SPF, DKIM, and DMARC, writes the verdict into an
ARC-Authentication-Results header, signs the body with an
ARC-Message-Signature, and signs prior chain state with an ARC-Seal. The `cv=`
tag records chain validity; a trusted-sealer override is possible when every
link validates.

### What are the three ARC headers?

ARC-Authentication-Results snapshots SPF, DKIM, and DMARC verdicts at this
hop. ARC-Message-Signature is a DKIM-style signature over the body and a
chosen header list. ARC-Seal is the chain-binding signature with a `cv=` tag —
`none` at i=1, `pass` when the prior chain validated, `fail` when not.

### What does cv=fail mean in an ARC chain?

`cv=fail` is a deliberate signal. A relay that validates the prior chain and
detects malformation must seal `cv=fail` and stop signing prior state, forcing
downstream receivers to write `arc=fail`. Common causes: body-hash mismatches,
missing AAR fields, broken canonicalization upstream.

### Is ARC the same as DMARC?

No. DMARC is the policy a receiver applies — quarantine, reject, or monitor.
ARC (`RFC 8617`) is the chain-of-custody metadata that lets the DMARC verdict
survive forwarder modification. DMARC decides; ARC preserves evidence.

### Is ARC being deprecated by the IETF?

Yes at the chartering layer, no in operation. The DMARC working group was
rechartered on 2026-04-16 to move `RFC 8617` to Historic by November 2026 or
close. Gmail, Microsoft 365, and Apple iCloud continue honoring ARC.

### Do I need to set up ARC for my domain?

Individual domain owners do not configure ARC. Forwarders seal it; receivers
validate. Domain owners publish DMARC and align DKIM. Forwarder operators can
use Mailman 3.3.8+, OpenARC, rspamd, or Halon. Audit your DMARC posture first
with our [DMARC checker](/tools/dmarc-checker/).

## Conclusion

Four operational truths sit underneath every ARC email authentication failure
in 2026. ARC is `RFC 8617` Experimental, and the IETF has begun retiring it.
The three headers — AAR, AMS, AS — repeat at every hop with an `i=` counter.
Microsoft 365 honors trusted-sealer chains via `compauth=pass reason=130` plus
`oda=1`; Gmail copy-forwards the verdict in `arc=pass (...)`. And `cv=fail` is
a deliberate signal — debug from the reason string back to the breaking hop.

Paste a forwarded message into the chain analyzer linked above for every
hop's AAR, AMS, and AS with `cv=` per seal. The DKIM2 follow-up publishes
2026-05-04.