--- title: "ARC Email Authentication: Forwarded Mail in 2026" description: "ARC email authentication carries SPF, DKIM, and DMARC verdicts across forwarding hops. Real headers, cv=fail debugging, trusted-sealer fixes, IETF status." publishedAt: 2026-04-29 lastUpdatedAt: 2026-09-16 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, 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." - 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: "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." - 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.6+, rspamd, Halon, or OpenARC, and should test the chain against Gmail before production." --- # ARC Email Authentication in 2026: How Forwarded Mail Actually Passes DMARC ARC (Authenticated Received Chain, RFC 8617) lets forwarded mail pass DMARC by recording SPF, DKIM, and DMARC verdicts at every hop and sealing them cryptographically in three headers — ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. A receiver that trusts the sealer can honor an earlier pass even after a forwarder breaks alignment, overriding a late-hop DMARC failure. Gmail and Microsoft 365 still validate ARC in 2026; Yahoo told the IETF it neither seals nor trusts it. The IETF's move to retire RFC 8617 to Historic has stalled short of a Working Group Last Call. Debug a live chain with the [ARC chain analyzer](/tools/arc-chain-analyzer/). 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](https://learn.microsoft.com/en-us/answers/questions/1533705/arc-failures-when-delivering-to-my-outlook-com-acc), 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](https://datatracker.ietf.org/doc/html/rfc8617) (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](/research/email-authentication/)). 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](/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, 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](/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 2017 production capture shows Gmail's `arc-20160816` selector signing a clean i=1 set ([postmarkapp.com](https://postmarkapp.com/blog/what-is-arc-or-authenticated-received-chain), 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](/blog/dmarc-forwarding-arc-fix/) that breaks SPF at the first hop.
## 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. ```email ``` 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](https://c7solutions.com/2022/06/improving-exchange-online-email-deliverability-through-third-party-filtering-services-trusted-arc-senders)). ```email ``` 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.
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-08-03) 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`. 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](/blog/microsoft-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](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000599190291-DMARC-Analyzer-Authenticated-Received-Chain)); Email Security Cloud Integrated tenants get it registered automatically ([new tenants from 2024-03-13, existing tenants 2024-03-25 to 28](https://mimecastsupport.zendesk.com/hc/en-us/articles/34000321250579-Email-Security-Cloud-Integrated-Trusted-ARC-Sealer-Mar-2024)), so the recipe is for Cloud Gateway tenants. `-ArcTrustedSealers` replaces the whole list, which is why it appends. ```powershell ``` 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](/blog/dmarc-fail-mimecast-fix/). ### 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](https://web.archive.org/web/20240310044438/https://support.google.com/a/answer/81126?hl=en)). 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](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** 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](https://mailarchive.ietf.org/arch/msg/dmarc/i4hyRvcGLghdMVOWkWqUaJV5E3U/)). Yahoo 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** 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](https://www.fastmail.com/blog/what-is-arc/)). 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](https://mailarchive.ietf.org/arch/msg/dmarc/PtRLCRSKg_YFG2v2n_OeSjxBhGI/)). **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](https://proton.me/blog/what-is-authenticated-received-chain-arc), 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](https://github.com/trusteddomainproject/OpenARC/issues/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. ```email ```
### 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](https://gangw.cs.illinois.edu/arc-www22.pdf)). GNU Mailman 3 signed ARC over the body before adding footers ([issue 896](https://gitlab.com/mailman/mailman/-/issues/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](https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/docs/NEWS.rst)), not 3.3.5. 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 since April 2026 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. 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, and on 2026-04-22 the working-group version, [`draft-ietf-dmarc-arc-to-historic-00`](https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-to-historic/), 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](https://mailarchive.ietf.org/arch/msg/dmarc/cmW5mXo3jR2CwaTNzk8lXaOKkyY/) ("It is too early to make ARC Historic at this point") and [Zone.ee](https://mailarchive.ietf.org/arch/msg/dmarc/UX8yUn1sQJzwByh7O5j8E_yUUP0/) ("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](https://mailarchive.ietf.org/arch/msg/dmarc/MXP2kursIfNK2cVc_3uaYbpRXTc/) 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](/blog/arc-to-dkim2-future/). ## 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](https://www.fortra.com/blog/dmarc-adoption-trends-q2-2025)), and Red Sift recorded 2.5% at `p=reject` across 73.3 million 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 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](https://gangw.cs.illinois.edu/arc-www22.pdf) 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](/tools/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.