April 29, 2026 (Updated September 16, 2026 ) by Meysam Azad

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, July 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; that effort has stalled short of a Working Group Last Call.

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 forwarded messages landing in Outlook.com with arc=fail (35) and arc=fail (47) — numeric codes that appear nowhere in Microsoft’s published header reference (learn.microsoft.com, asked 2024-02-15). The thread drew two replies and no accepted answer, 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 in April 2026 the IETF rechartered the DMARC working group specifically to retire it, an effort that has stalled short of a Working Group Last Call. ARC is a bulk-sender requirement on forwarded mail at iCloud (since 2025-02-25), a February 2024 Gmail guideline that Google has since dropped from the live text, and a configurable trust anchor at Microsoft 365. Across the 5,499,028 domains DMARCguard scanned in February 2026, 12.8% (702,000) publish DMARC at p=quarantine or p=reject — each one asks receivers to quarantine or reject forwarded mail that arrives 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 three-seal 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, July 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 2017 production capture shows Gmail’s arc-20160816 selector signing a clean i=1 set (postmarkapp.com, 11 September 2017); the same selector still answers a dig TXT arc-20160816._domainkey.google.com today.

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 ARC sets 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 ARC set plus the current hop's AAR and AMS. The receiver validates from i=N backwards.

Real ARC Headers — A Three-Seal 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. Postmark’s 2017 Postmark-to-Gmail capture reads i=1; mx.google.com; dkim=pass header.i=@postmarkapp.com ... spf=pass ... dmarc=pass — two DKIM evaluations, one SPF, one DMARC, all at the first hop.

 ARC-Seal + ARC-Authentication-Results — Postmark→Gmail, i=1 (postmarkapp.com, 2017) email 

ARC-Seal: i=1; a=rsa-sha256; t=1504715872; cv=none;
        d=google.com; s=arc-20160816;
        b=Nz9pPmKDifg+wmSdwCnUjXvG9jG9WFoF6fghYY1QdGolnG/TZoGeuJHkzDl8KQyVtt
         (remaining base64 omitted)
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
       dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
       spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender) smtp.mailfrom=pm_bounces@pmbounces.postmarkapp.com;
       dmarc=pass (p=NONE sp=NONE 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 characters 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 signs every prior ARC set — AAR, AMS, and AS — plus this hop’s own AAR and AMS (RFC 8617 §5.1.1). Tags: a=, d=, s=, t= (Unix timestamp), cv= (chain validity), b= (signature over the seal graph).

A real chain: Microsoft 365 → Mimecast → Microsoft 365

Brian Reid’s c7solutions trace (20 June 2022) captures the canonical Microsoft 365 → Mimecast → Microsoft 365 path after the receiving tenant added Mimecast’s dkim.mimecast.com as a trusted sealer. Mimecast sealed i=2 and the receiving tenant sealed i=3. Reid did not reproduce the i=1 set; his article notes that Microsoft also places its own ARC-Seal and ARC-Message-Signature in the message, and the i=2 AAR’s header.s=selector1 DKIM pass points at the sending tenant’s Microsoft 365. The most recent set sits at the top; reading top-down reads backwards through time. Reid published the headers with b= values and one IP redacted; they are reproduced as published (c7solutions.com).

 ARC chain, i=3 and i=2 — Microsoft 365 → Mimecast → Microsoft 365 (c7solutions.com, June 2022) email 

# Headers as published by Brian Reid (c7solutions.com, 20 June 2022) after
# adding dkim.mimecast.com as a trusted ARC sealer. b= values and one IP were
# redacted by the author. Read top-down: i=3 (receiving tenant) is newest,
# i=2 is Mimecast, i=1 (the sending tenant's own Microsoft seal) sits deeper.

Authentication-Results: spf=pass (sender IP is 40.107.8.127)
    smtp.mailfrom=c7solutions.com; dkim=fail (body hash did not verify)
    header.d=c7solutions.com;dmarc=fail action=none
    header.from=c7solutions.com;compauth=pass reason=130

ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is
    40.107.8.127) smtp.rcpttodomain=contoso.com smtp.mailfrom=c7solutions.com;
    dmarc=pass (p=reject sp=reject pct=100) action=none
    header.from=c7solutions.com; dkim=fail (body hash did not verify)
    header.d=c7solutions.com; arc=pass (0 oda=1 ltdi=1
    spf=[1,2,smtp.mailfrom=brian.reid@c7solutions.com]
    dkim=[1,2,header.d=c7solutions.com] dmarc=1,2,header.from=c7solutions.com])

ARC-Authentication-Results: i=2; relay.mimecast.com;
    dkim=pass header.d=c7solutions.com header.s=selector1 header.b=xxxxxxx;
    dmarc=pass (policy=none) header.from=c7solutions.com;
    spf=pass (relay.mimecast.com: domain of brian.reid@c7solutions.com
    designates w.x.y.z as permitted sender)
    smtp.mailfrom=brian.reid@c7solutions.com

# Before the sealer was trusted, the same i=3 line ended in
# "arc=pass (0 oda=0 ltdi=0 93)" and the final verdict was compauth=pass
# reason=100 with DMARC passing on SPF alone.

Three Microsoft tokens matter in the final hop. Microsoft documents arc=pass with oda=1 in the last ARC-Authentication-Results header as meaning the previous ARC chain verified, the previous sealer is trusted, and the previous pass result can override the current DMARC failure; it never expands the acronym. ltdi=1 sits next to it in Microsoft’s own example and is defined nowhere. compauth=pass reason=130 in the final Authentication-Results header is the code Microsoft documents as “The ARC result from a trusted ARC sealer overrode the DMARC failure” — note that DKIM and DMARC still read fail on that line, which is exactly the point.

Three stacked annotated cards from Brian Reid's June 2022 trace: the final Authentication-Results line (dkim=fail, dmarc=fail, compauth=pass reason=130), the i=3 ARC-Authentication-Results from Microsoft 365 with arc=pass oda=1 ltdi=1, and the i=2 ARC-Authentication-Results from relay.mimecast.com. — Top card is the final receiver's verdict; bottom card is what Mimecast saw. i=1, the sending tenant's own Microsoft seal, sits below the frame.

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

Microsoft’s failure table on the same page gives the two symptoms that matter: arc=pass with oda=0 means the sealer is not on the tenant’s trusted list, and compauth=fail reason=000 despite a trusted sealer means the chain itself failed validation. A reason=4xx value means composite authentication was bypassed altogether and says nothing about ARC (Microsoft’s reason-code table, updated 2026-07-27). For broader Microsoft 365 DMARC enforcement, indirect mail flow rules apply. Configure via the Set-ArcConfig PowerShell cmdlet.

The value to add is the d= domain in the gateway’s ARC-Seal: header — the vendor’s signing domain, never your own — and Microsoft’s page says to read it off a message that came through the gateway before you run the command. Mimecast documents dkim.mimecast.com (Mimecast KB 34000599190291); Email Security Cloud Integrated tenants get it registered automatically (new tenants from 2024-03-13, existing tenants 2024-03-25 to 28), so the recipe is for Cloud Gateway tenants. -ArcTrustedSealers replaces the whole list, which is why it appends.

Microsoft 365 — add a trusted ARC sealer and verify powershell

# Connect to Exchange Online first (Connect-ExchangeOnline)

# The trusted sealer is the d= domain in the ARC-Seal header the gateway
# stamps, never your own domain. Mimecast documents dkim.mimecast.com;
# confirm it against an ARC-Seal: from your own mail before you run this.
# Email Security Cloud Integrated registers itself, so this recipe is for
# Cloud Gateway tenants.

# -ArcTrustedSealers replaces the whole list, so append to what is there.
$sealers = @(Get-ArcConfig | Select-Object -ExpandProperty ArcTrustedSealers)
$sealers += "dkim.mimecast.com"
Set-ArcConfig -Identity Default -ArcTrustedSealers $sealers

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

# Microsoft documents up to 30 minutes for the change to take effect. After
# that, mail sealed by a trusted sealer shows: arc=pass, oda=1,
# compauth=pass reason=130.

If Mimecast is the gateway and the symptom is inbound mail held with “DNS Authentication: DMARC Fail”, the Mimecast-side diagnosis — the hold verdict, the console workflow, and this trusted-sealer step in the Microsoft 365 topology — is in fixing DMARC fail in Mimecast.

Gmail — implicit trust, copy-forward signaling

Gmail validates ARC on inbound mail and writes the result into Authentication-Results from mx.google.com as arc=pass (i=N ...) or arc=fail (reason); OpenARC issue #128 below shows the fail form with its reason string. The parenthesized comment is the load-bearing diagnostic.

Gmail’s February 2024 sender guidelines told forwarders to add ARC headers: “If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email” (archived 2024-03-10 copy). The live guidelines and the forwarding best-practices page no longer mention ARC at all — Gmail still validates it, but the written requirement is gone. Apple iCloud went the other way on 2025-02-25, listing “Add ARC headers to forwarded emails” among the requirements bulk senders must meet or be rejected (support.apple.com). ARC sits inside the joint Google’s bulk-sender enforcement rule set.

Yahoo, Fastmail, and Proton

Yahoo reversed itself in public. Its sender best practices still say “If you forward emails, implement ARC.” But in an official statement relayed to the IETF dmarc list on 30 July 2026, Yahoo said it has “not been applying ARC headers to any email and we will not be doing so in the future.” Accepting other senders’ ARC, it added, “has DECREASED our ability to identify email that our users do not wish to receive,” and its trusted-sealer list is “now extremely short” (mailarchive.ietf.org). Yahoo also publishes ARF feedback loops; what abuse reports look like alongside ARC is a separate piece of the deliverability picture.

Fastmail began implementing ARC at the 2017 IETF 99 hackathon, interop-tested it with other providers after the October 2018 M3AAWG meeting, and by its March 2023 write-up was “not only validating and adding ARC headers” but using them between trusted systems (fastmail.com). Its CEO, Bron Gondwana, on the dmarc list on 1 February 2026: “Fastmail ALSO adds ARC headers and verifies ARC, but (still) doesn’t treat it as having any spam prediction value” (mailarchive.ietf.org).

Proton accepts DMARC-failing mail only from “a limited set of parties that we trust to implement ARC correctly,” and only when the message passes ARC and the first-hop AAR shows a DMARC pass (proton.me, 30 June 2023). Whether Proton seals its own outbound mail is undocumented.

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)`	Gmail verdict on a Hotmail → OpenARC → Gmail chain (OpenARC #128, 2020); root cause never diagnosed in the public record	Test your sealer against Gmail before production; the reporter replaced OpenARC with rspamd
`arc=fail (body hash mismatch)`	Forwarder modified the body after AMS computed; Mailman before 3.3.6 signed before adding footers	Mailman 3.3.6+; sign after personalization
`arc=fail (47)` / `arc=fail (35)`	Microsoft-specific numeric codes, absent from Microsoft’s header reference; on Microsoft Q&A since February 2024	Observed-but-undocumented; rebuild from i=1
`arc=pass` with `oda=0`	Sealer not on the tenant’s trusted list (Microsoft’s failure table)	Add the ARC-Seal `d=` domain via `Set-ArcConfig`

OpenARC issue #128 (13 January 2020) captures arc=fail (missing mandatory fields) on a Hotmail → OpenARC → Gmail chain. Microsoft’s outbound seal at i=1 carries an AAR of spf=none; dmarc=none; dkim=none; arc=none, the OpenARC relay sealed i=2 with cv=fail, and Gmail — which passed DKIM, SPF, and DMARC on the same message — still rejected the chain. Nobody in the issue identified the cause; the reporter said in July 2026 he never resolved it and replaced OpenARC with rspamd.

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

# Headers as posted in OpenARC issue #128 (13 January 2020), trimmed to the
# authentication lines. Hotmail (Microsoft seal, i=1) -> OpenARC relay
# nc1.example.org (i=2) -> Gmail. The cause was never identified in the issue.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@hotmail.com header.s=selector1 header.b=YSz+76Ay;
       arc=fail (missing mandatory fields);
       spf=pass (google.com: domain of srs0=tv9s=3c=hotmail.com=andy@example.org designates 12.345.67.12 as permitted sender) smtp.mailfrom="srs0=tv9s=3c=hotmail.com=andy@example.org";
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=hotmail.com

ARC-Seal: i=2; a=rsa-sha256; d=nc1.example.org; s=nc1-2020-1; t=1578922760;
	cv=fail; b=...
ARC-Authentication-Results: i=2; nc1.example.org; dmarc=pass (p=none dis=none) header.from=hotmail.com; dkim=pass (2048-bit key; unprotected) header.d=hotmail.com header.i=@hotmail.com header.b=YSz+76Ay; dkim-atps=neutral

ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=...
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none

# The relay's own seal already says cv=fail against Microsoft's i=1 set, and
# Microsoft's i=1 AAR records no authentication at all. Gmail passed DKIM, SPF
# and DMARC on the same message and still rejected the chain.

Five-row comparison grid mapping each cv= or arc= failure symptom (signature failed, missing mandatory fields, body hash mismatch, arc=fail 47, arc=pass with oda=0) to its root cause and remediation. — Read the parenthesized reason string first — it points at the breaking hop.

Forwarder failure modes worth knowing

Firefox Relay strips authentication headers outright, and iCloud Hide My Email rewrites the From header without re-sealing — either way the ARC chain breaks (gangw.cs.illinois.edu). GNU Mailman 3 signed ARC over the body before adding footers (issue 896, May 2021); the fix — “ARC signing now signs after the message has been personalized and decorated” — shipped in 3.3.6 on 2022-10-26 (NEWS), not 3.3.5. 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 since April 2026

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. On 2026-01-30 Adams proposed a recharter; on 2026-04-16 the IESG issued the WG Action: Rechartered announcement, and on 2026-04-22 the working-group version, draft-ietf-dmarc-arc-to-historic-00, replaced it. That -00 — “Obsoletes: 8617 (if approved)”, intended status Informational — is still the only revision, and it expires on 2026-10-24.

The chartering language is bluntly worded: “Industry experience has shown that this proposal has enjoyed neither noteworthy uptake nor sufficient impact.” The charter gives the group six months from rechartering — 16 October 2026 — and states that if it “fails to meet this deadline, the group will close at that time.” The datatracker milestone reads 30 November 2026.

Then the consensus call stalled. Chair Barry Leiba asked on 3 July 2026 for objections by 17 July. Seth Blank objected within the hour: “I think we should NOT make ARC historic, yet,” because “ARC is actively deployed and utilized” and “No interoperable replacement is yet published.” Internet Initiative Japan (“It is too early to make ARC Historic at this point”) and Zone.ee (“We use it in a limited scope with good results”) backed him on 6 July. On 18 July Leiba wrote that there was “clear consensus on Seth’s objection, among those objecting” and gave proponents until 7 August to answer with data from “some of the major email services.” Two operators did, both against ARC: Comcast’s Alex Brotman on 20 July (“While others have found value in ARC, I found the opposite”) and Yahoo on 30 July (quoted above). No chair determination followed, there is no Working Group Last Call, and the DMARC working group held no session at IETF 126.

Two events, often conflated — keep them separate

Event 1 is the working group reaching consensus on the status-change document before its charter clock runs out on 16 October 2026. Event 2 is RFC 8617 actually reclassified to Historic in the RFC index, which cannot happen before Event 1 and needs IESG approval after it. We previously expected Event 1 by the end of Q3 2026. There is no Last Call, so that was wrong.

Operator behavior is bound to neither event. Yahoo has said it does not seal and barely trusts ARC; no other major mailbox provider has committed in the IETF record to a dated end of ARC honoring. Gmail and Microsoft 365 still validate chains today. 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.

Why ARC Matters Right Now (Despite the Retirement Plan)

Across the 5,499,028 domains DMARCguard scanned in February 2026, 12.8% publish DMARC at p=reject or p=quarantine. Public crawls measure different populations — 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 domains in December 2025 (redsift.com). The denominators differ; do not treat these as ranked. DMARCguard’s scan covers the complete Tranco Top Sites list, a ranking biased toward web traffic — low-traffic and newly registered domains may differ.

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 (mailsac.com) and found ARC headers on 23.2% of messages 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, July 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; that effort has stalled short of a Working Group Last Call.

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?

Proposed, not decided. The DMARC working group was rechartered on 2026-04-16 to move RFC 8617 to Historic within six months or close; the deadline is 2026-10-16, there is no Working Group Last Call, and the chair’s July consensus call stalled. Gmail and Microsoft 365 still validate ARC; Yahoo told the IETF in July 2026 it neither seals nor trusts it much.

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.6+, rspamd, Halon, or OpenARC, and should test the chain against Gmail before production. 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’s attempt to retire it has stalled at the consensus stage. 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.

The DKIM2 companion covers what replaces ARC. For the message in front of you right now, the analyzer below breaks out every hop’s AAR, AMS, and AS with cv= per seal.