The ARC email protocol explained in a single sentence: it lets every intermediary in a mail delivery path sign what it saw, so the final receiving server can evaluate authentication history even when forwarding has broken SPF and DKIM. That one sentence hides a surprisingly deep chain-of-custody mechanism, live inside Gmail and Exchange Online today, yet almost entirely absent from accessible technical documentation. This article dissects every layer: the three headers, the seal chain, the cv= field, and exactly how a receiving MTA walks the chain to make a delivery decision.

Why Email Forwarding Breaks Authentication, and Why ARC Exists

Standard email authentication, SPF, DKIM, and DMARC, works well when a message travels directly from sender to recipient. Forwarding breaks that assumption immediately. Understanding how SPF, DKIM, and DMARC work together sets the baseline; the ARC problem starts precisely where those three protocols stop.

The SPF, DKIM, and DMARC Failure Chain in a Forwarding Hop

Here is the canonical failure sequence, step by step:

  1. A sender on a p=reject DMARC domain sends to a mailing list.
  2. The mailing list receives the message, verifies DKIM, it passes at this point.
  3. The list rewrites the envelope sender (MAIL FROM) to its own bounce address for bounce handling. SPF now aligns to the list domain, not the original sender.
  4. The list appends a subject tag like [List-Name] or adds a footer. That modifies the body, breaking the DKIM body hash.
  5. The list forwards to subscribers, keeping the original From: header.
  6. The subscriber's MTA runs authentication checks: SPF fails (the list's IP isn't in the original sender's SPF record), DKIM fails (body hash mismatch), DMARC sees neither mechanism passing with alignment, and the policy says reject.

The message is dead, and it was perfectly legitimate. No amount of tuning SPF or DKIM records at the original sender fixes this. The problem is structural: these protocols verify point-to-point integrity, and a forwarding hop is by definition a break in that chain.

ARC RFC 8617, published by the IETF in July 2019 as an Experimental Protocol, is the standards body's answer. Its core insight: treat forwarding as a chain-of-custody problem. Each intermediary signs what it witnessed, including the authentication results it observed before it touched the message, and hands that signed record to the next hop.

The Three ARC Headers: Seal, Signature, and Authentication-Results

Every intermediary that implements ARC adds exactly one ARC set to the message. A set always contains three headers, tagged with an instance number i= that increments with each hop.

ARC-Authentication-Results: Preserving What Each Hop Witnessed

The ARC-Authentication-Results (AAR) header is a snapshot. It records the authentication results the intermediary computed when it received the message, SPF result, DKIM result, DMARC result, before making any modifications.

ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass smtp.mailfrom=sender@original.example;
  dkim=pass header.d=original.example;
  dmarc=pass header.from=original.example

This is the testimony: "When I, the mailing list at lists.example.org, received this message, all three checks passed." The subsequent forwarding may break those checks, but the record of what passed before the break is now in the header, cryptographically tied to the chain.

ARC-Seal and ARC-Message-Signature: Locking the Chain

The ARC-Message-Signature (AMS) works like a DKIM signature. It signs a defined set of headers plus the message body at the moment the intermediary processes the message. If a later hop modifies the body, this signature breaks, which is intentional. It records the state of the message at that point in the chain.

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=lists.example.org; s=arc2024;
  h=from:to:subject:date:message-id:mime-version:arc-authentication-results;
  bh=<body-hash>; b=<signature>

The ARC-Seal (AS) is the tamper-evident wrapper for the entire ARC set. It does not sign the message body. Instead, it signs the previous ARC-Seals (all of them, forming the chain) plus the ARC-Authentication-Results and ARC-Message-Signature headers for its own instance. The cv= field it carries is critical:

  • cv=none, this is the first ARC set in the chain; there are no prior seals to validate.
  • cv=pass, the signing intermediary verified all previous ARC-Seal signatures and found them intact.
  • cv=fail, the signing intermediary found a broken seal in the prior chain.
ARC-Seal: i=1; a=rsa-sha256; t=1720000000; cv=none;
  d=lists.example.org; s=arc2024; b=<signature>

Once a seal carries cv=fail, every subsequent seal in the chain must also carry cv=fail. The chain is permanently broken from that point forward.

How the ARC Seal Chain Is Built Hop by Hop

Each intermediary that adds an ARC set increments i= by one. The first hop uses i=1, the second uses i=2, and so on. The instance tag is what makes the chain ordered and verifiable.

Annotated Header Example: A Mailing List Forwarding Scenario

Imagine: sender@brand.example sends to announce@lists.example.org. The list forwards to subscriber@inbox.example via a secondary relay at relay.example.net.

After the mailing list processes the message (i=1 added by lists.example.org):

ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass smtp.mailfrom=sender@brand.example;
  dkim=pass header.d=brand.example;
  dmarc=pass header.from=brand.example

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=lists.example.org; s=arckey; bh=<hash-of-body-at-i1>; b=<ams-sig-1>

ARC-Seal: i=1; a=rsa-sha256; cv=none;
  d=lists.example.org; s=arckey; b=<as-sig-1>

cv=none because there is no prior chain. The list has recorded that when it received the message, all three authentication mechanisms passed.

After the relay processes the message (i=2 added by relay.example.net):

ARC-Authentication-Results: i=2; relay.example.net;
  spf=fail smtp.mailfrom=bounce@lists.example.org;
  dkim=fail header.d=brand.example;
  dmarc=fail header.from=brand.example

ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
  d=relay.example.net; s=arckey2; bh=<hash-of-body-at-i2>; b=<ams-sig-2>

ARC-Seal: i=2; a=rsa-sha256; cv=pass;
  d=relay.example.net; s=arckey2; b=<as-sig-2>

Notice: the relay's AAR at i=2 honestly records that SPF, DKIM, and DMARC all fail from its vantage point, because the list has already rewritten the envelope and modified the body. But cv=pass in the i=2 ARC-Seal means the relay verified the i=1 seal signature and found it intact. The chain is valid. The final MTA now has forensic evidence: at i=1, a known mailing list saw a clean message with passing authentication.

How a Receiving MTA Evaluates an ARC Chain

The verifier at inbox.example receives the message with two ARC sets. Its evaluation process:

  1. Find the highest instance number. Here, i=2.
  2. Verify the ARC-Seal at the highest instance. Retrieve the public key for relay.example.net via DNS (s=arckey2._domainkey.relay.example.net). Validate the signature. If it fails, the chain fails.
  3. Check cv= at each instance top-down. The i=2 seal says cv=pass, meaning the relay already verified i=1. The verifier independently checks i=1 ARC-Seal as well.
  4. Walk down to i=1. Verify the i=1 ARC-Seal signature for lists.example.org. Confirm that cv=none, correct for the first instance.
  5. If all seals verify and no cv=fail is present, the ARC chain is valid.

The result is an ARC chain validation outcome: valid or invalid. This outcome is separate from the DMARC policy result. A valid chain does not transform a DMARC fail into a DMARC pass. It gives the receiving MTA evidence, specifically, that a trusted intermediary vouches for the message's authentication state at an earlier point in the path. What the MTA does with that evidence is a local policy decision.

ARC vs DMARC: Complementary Roles, Not a Replacement

This is the most commonly misunderstood aspect of ARC. DMARC is a sender policy published in DNS: "Here is what to do with mail that fails alignment under my domain." ARC is an intermediary attestation mechanism: "Here is what I, an intermediary, observed about this message's authentication state when I handled it."

A valid ARC chain does not make DMARC pass. DMARC still evaluates SPF and DKIM alignment from its own vantage point. What ARC provides is a signal the receiving MTA can use to apply local leniency, to say, in effect, "this message failed DMARC at my boundary, but a trusted intermediary I recognize attests that it passed at an earlier hop, so I will deliver rather than reject."

Gmail and Exchange Online both evaluate ARC chains when making delivery decisions for mail arriving via mailing lists or indirect forwarders. Both maintain internal lists of ARC-trusted forwarders, intermediaries whose ARC signatures they weight in leniency decisions. A valid ARC chain from an untrusted or unknown signer carries less weight than one from a recognized provider.

This trust-list model is the practical mechanism. ARC does not create automatic forgiveness for DMARC failure. It creates a path for mail from known-good intermediaries to survive a forwarding-induced failure, but only if the intermediary is in the receiver's trust list and the chain is cryptographically intact.

Where ARC Is Headed: The 2026 Reclassification Effort

Anything written about ARC's long-term role needs one important caveat, and it's recent enough that most existing documentation doesn't cover it yet: on April 22, 2026, the IETF's DMARC working group published draft-ietf-dmarc-arc-to-historic-00, "Reclassifying ARC as Historic." The draft, authored by contributors from Proofpoint and Taughannock Networks, proposes marking RFC 8617 as Historic, the IETF's formal signal that a protocol should not be the basis for new deployments.

The reasoning centers on exactly the trust-list dependency described above. ARC's chain-of-custody signal is only as good as the receiver's ability to know which intermediaries to trust, and there is no standardized mechanism for establishing that trust across the open internet. The draft cites limited real-world adoption, roughly 10,000 domains observed sending ARC-signed mail since the RFC's 2019 publication, as evidence that the experiment hasn't reached the scale needed to justify permanent standardization. As of this writing the draft remains an active Internet-Draft, not yet finalized, but the direction of travel is clear: the working group's recommendation is that ARC should no longer be relied upon for trust decisions between disparate senders and receivers. Narrower use, inside a single administrative domain or a tightly controlled partner relationship with a known audit trail, is explicitly carved out as still potentially useful.

Practically, this doesn't make anything in this article wrong today. Gmail and Exchange Online continue to evaluate ARC chains in production right now, and understanding the mechanism remains necessary for diagnosing inbox placement failures you'll encounter this year. But it does mean ARC is not a foundation to build new long-term trust architecture on. Treat it as forensic and diagnostic infrastructure, useful for understanding what happened to a message in transit, rather than as a mechanism your organization should invest in deploying as a forwarding-trust strategy going forward.

Reading ARC Headers in Practice: Diagnosing Forwarding Failures

Reading the full delivery path in raw headers is the prerequisite skill. ARC headers appear near the top of a raw message, immediately below the Received: headers added by each hop. In most mail clients, you access raw headers via "View Source," "Show Original," or equivalent.

A healthy chain looks like the example above: ordered instance tags, cv=none at i=1, cv=pass at every subsequent instance, and valid signatures across all sets.

A broken chain announces itself with cv=fail. When diagnosing delivery failures from email headers, start at the highest instance number and read backward:

ARC-Seal: i=2; a=rsa-sha256; cv=fail;
  d=relay.example.net; s=arckey2; b=<sig>

cv=fail at i=2 means the relay attempted to verify the i=1 seal, and it did not check out. The most common causes:

  • Body modification after i=1 was sealed. A mailing list adds a footer after signing, breaking the ARC-Message-Signature body hash. The next hop's verification fails.
  • Missing ARC implementation at an intermediate hop. A server between the ARC signer and the final recipient neither verifies nor adds its own ARC set. This does not break the chain cryptographically, the prior ARC sets travel through untouched, but it means the chain reflects the state at the last ARC-aware hop, not the actual last hop.
  • Misconfigured ARC signer. Wrong key selector in DNS, expired key, or a signing algorithm mismatch (a=rsa-sha256 in the header, different algorithm in the key record).
  • Clock skew. The t= timestamp in the ARC-Seal falls outside acceptable bounds at verification time, causing signature rejection.

For DMARC failure triage starting with the Authentication-Results header, a cv=fail ARC chain combined with a DMARC fail at the final hop is a strong indicator of a mailing list or forwarder in the path that either broke the chain or never implemented ARC at all.

The practical remediation path: confirm the intermediary supports ARC (major list managers like Mailman 3 and Google Groups do), check whether the intermediary is in the receiver's ARC trust list, and verify that no downstream hop is modifying the message after the ARC set is applied. If the intermediary is not in the receiver's trust list, a valid chain still helps, but the receiver's local policy ultimately determines the outcome.

ARC is not a magic fix for broken forwarding. It is forensic infrastructure: a signed record of what each hop witnessed, available to any verifier willing to walk the chain. Its Experimental status, and the 2026 proposal to mark it Historic, reflect an ecosystem that never reached the trust-framework maturity the original design assumed. With major providers still evaluating ARC chains in production today, understanding the mechanism remains necessary for anyone diagnosing inbox placement failures at scale, even as its long-term standardization future looks increasingly unlikely.