April 29, 2026 by DMARCguard Team

ARC Email Authentication in 2026: How Forwarded Mail Actually Passes DMARC

Q: 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.

Q: 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 are body-hash mismatches, missing AAR fields, and broken canonicalization upstream.

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, 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 (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).

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.

What ARC Email Authentication Actually Is

ARC email authentication, formally the Authenticated Received Chain, is specified in RFC 8617 (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 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).

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 that breaks SPF at the first hop.

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. — 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 [email protected] ... spf=pass ... dmarc=pass.

ARC-Authentication-Results — Postmark→Gmail single hop, i=1 email

ARC-Authentication-Results: i=1; mx.google.com;
    dkim=pass header.i=@postmarkapp.com header.s=20210112 header.b=Hk2pQwLs;
    spf=pass (google.com: domain of pm-bounces@postmarkapp.com designates
        198.51.100.21 as permitted sender) smtp.mailfrom=pm-bounces@postmarkapp.com;
    dmarc=pass (p=quarantine sp=quarantine dis=none) header.from=postmarkapp.com

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).

Two-hop ARC chain — Microsoft 365 → Mimecast → Microsoft 365 (annotated) email

Authentication-Results: spf=pass (sender IP is 203.0.113.45)
    smtp.mailfrom=contoso.com; dkim=pass (signature was verified)
    header.d=contoso.com; dmarc=pass action=none header.from=contoso.com;
    compauth=pass reason=130

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass
    smtp.mailfrom=eu-smtp-1.mimecast.com; dkim=pass header.d=contoso.com;
    dmarc=pass action=none header.from=contoso.com; arc=pass (0 oda=1 ltdi=1
    spf=[1,1,smtp.mailfrom=contoso.com] dkim=[1,1,header.d=contoso.com]
    dmarc=[1,1,header.from=contoso.com])

ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
    s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
    bh=Lf3M+8oM2W3K6mZcQp0xS5RmU2nT4bA7vXk1qY9zG0c=; b=...truncated

ARC-Seal: i=2; a=rsa-sha256; t=1745404820; cv=pass; d=microsoft.com;
    s=arcselector9901; b=...truncated

ARC-Authentication-Results: i=1; mimecast.com;
    spf=pass smtp.mailfrom=contoso.com;
    dkim=pass header.d=contoso.com header.s=selector1;
    dmarc=pass header.from=contoso.com

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=eu-smtp-1.mimecast.com; s=2024; h=From:To:Subject:Date:Message-ID;
    bh=R7yY1pQ8sN2mZ4kT9oW6cVbX3uHlA5gE0fK2rM7nC1d=; b=...truncated

ARC-Seal: i=1; a=rsa-sha256; t=1745404810; cv=none;
    d=eu-smtp-1.mimecast.com; s=2024; b=...truncated

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.

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. — 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 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). 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, indirect mail flow rules apply. Configure via the Set-ArcConfig PowerShell cmdlet.

Microsoft 365 — add a trusted ARC sealer and verify powershell

# Connect to Exchange Online first (Connect-ExchangeOnline)

# Add a trusted ARC sealer (only legitimate, required services).
Set-ArcConfig -Identity Default `
    -ArcTrustedSealers "eu-smtp-1.mimecast.com","mailgun.org"

# Verify the configured sealers.
Get-ArcConfig | Format-List ArcTrustedSealers

# After the change propagates (allow up to an hour), forwarded mail from
# a trusted sealer will produce: arc=pass, oda=1, compauth=pass reason=130.

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). Apple iCloud went further on 2025-02-25, making ARC headers a hard rejection trigger (support.apple.com). ARC sits inside the joint Google’s bulk-sender enforcement 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 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 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.

OpenARC #128 — arc=fail (missing mandatory fields) on Hotmail→OpenARC→Gmail email

# Hotmail (i=1) -> OpenARC relay -> Gmail (final receiver)
# Gmail emits arc=fail because the i=1 AAR did not enumerate the DKIM
# signature it could verify independently — see OpenARC issue #128.

Authentication-Results: mx.google.com;
    dkim=pass header.i=@hotmail.com header.s=selector1;
    spf=neutral (google.com: 192.0.2.10 is neither permitted nor denied);
    dmarc=fail (p=none sp=none dis=none) header.from=hotmail.com;
    arc=fail (missing mandatory fields)

ARC-Authentication-Results: i=2; relay.example.org;
    spf=pass smtp.mailfrom=user@hotmail.com;
    dkim=pass header.d=hotmail.com;
    dmarc=pass header.from=hotmail.com

ARC-Authentication-Results: i=1; hotmail.com;
    spf=pass smtp.mailfrom=user@hotmail.com;
    dmarc=pass header.from=hotmail.com
    # NOTE: no dkim= line here, even though the message carried a valid
    # DKIM signature signed by hotmail.com. Gmail expects the i=1 AAR to
    # enumerate every authenticator it can independently verify; the
    # missing dkim= line is what triggers "missing mandatory fields".

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. — 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). 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 covers the surrounding workflow. Or check ARC headers on a single message 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 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 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, 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), and Red Sift recorded 2.5% at p=reject across 73.3 million apex domains in December 2025 (redsift.com). 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.

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.