ARC — the protocol that survives forwarders.

The forwarding problem

SPF (RFC 7208) authenticates the sending IP against the envelope MAIL FROM domain. DKIM (RFC 6376) authenticates the message body and a selected set of headers against a published public key. DMARC (RFC 7489) requires the authenticated domain to align with the visible From: header. All three were specified against the implicit assumption that mail flows in a single hop from sending infrastructure to receiving infrastructure.

That assumption is false in roughly 3 to 8% of B2B mail volume. A meaningful fraction of legitimate messages traverse at least one intermediate forwarder: a mailing-list server expanding a list address, a personal forwarding service consolidating multiple addresses, a corporate mail tenant relaying mail from an acquired-company domain, or a recipient's manually configured forwarding rule.

The concrete failure case is mundane. A cold-outreach sender at sender.com dispatches a message to a recipient at recipient-corp.com. The message passes SPF and DKIM. The recipient, finding the pitch relevant, forwards it to a colleague at partner-corp.com via an auto-forwarding rule.

At partner-corp.com, the message arrives from recipient-corp.com's outbound IP — not from sender.com. SPF, evaluated against the MAIL FROM domain that is still sender.com, fails: recipient-corp.com's IP is not in sender.com's SPF record. DKIM may also fail if the forwarder modified the body (adding a list footer, rewriting links, prepending a security banner) or canonicalized headers in a way the original signature did not anticipate. DMARC concludes the message is unauthenticated, and if sender.com publishes p=reject, the receiver at partner-corp.com rejects it. A legitimate forwarded message — the highest-intent signal in a cold sequence, a recipient actively distributing the pitch to a colleague — does not arrive.

The pre-ARC fallback

Before ARC was specified in 2019, the operational response to the forwarding problem was a set of progressively worse compromises, all still observable in long-tail mailing-list software and corporate forwarders that have not been updated.

The first fallback is From: rewriting. The forwarder, recognizing that the original From: header will fail DMARC at the next receiver, rewrites it to a forwarder-owned address. The message arrives with a From: line like list-name@mailing-list.example via original-sender.com, or an opaque noreply@forwarder.example with the original sender's identity demoted to a Reply-To header that many mail clients render in small grey type at the bottom of the message. The user-experience degradation is observable: the recipient sees a forwarder's brand instead of the sender they actually correspond with, reply behavior breaks, threading breaks, and the legitimate sender becomes indistinguishable from the spam mailing list the forwarder also relays.

The second fallback is DKIM removal. The forwarder strips the original signature entirely and re-signs under its own key. The receiver sees a DKIM-authenticated message from the forwarder, but with no cryptographic link to the original sender. DMARC alignment is, by construction, satisfied by the forwarder's identity rather than the sender's — the wrong identity to evaluate legitimacy against. The deliverability cliff for senders at p=reject is not subtle: forwarded mail either fails DMARC and is rejected outright, or passes under the forwarder's identity and is evaluated against the forwarder's reputation — typically worse, because forwarders aggregate traffic across thousands of unrelated senders.

What ARC adds

ARC, specified in RFC 8617, attaches a cryptographically signed record of authentication results to the message at each forwarding hop. The final receiver evaluates not only the SPF and DKIM results at its own hop — which may have been invalidated by forwarder modifications — but also the ARC-attested results observed at every previous hop, including the original one.

Each forwarder participating in ARC adds a new set of headers attesting to: the authentication results it observed on arrival, a signature over the message as it existed at that point, and a seal binding the chain together up to and including this hop. A receiver can determine, with cryptographic certainty subject to the trust model below, whether the original message passed authentication at the original receiver and whether the chain has been tampered with downstream. The practical consequence: a cold-outreach message that originally passed SPF and DKIM at the recipient's mail server, then was forwarded to a colleague at a different organization, can be accepted by the final receiver on the basis of the original authentication results — even though those results would no longer validate if recomputed locally.

The three ARC headers

Each ARC participant adds three headers to the message. The headers are indexed by an instance counter i= that increments with each hop:

ARC-Authentication-Results

A snapshot of the authentication results observed by this hop at the moment the message arrived. The header captures the SPF result, the DKIM result, the DMARC result, and any other authentication mechanisms the receiver evaluated (BIMI, DKIM2, ARC chain validation from the prior hop). The format is the same as the standard Authentication-Results header defined by RFC 8601, prefixed with the ARC instance counter.

ARC-Message-Signature

A DKIM-style cryptographic signature over the message headers and body as they existed at this hop, after the hop's modifications were applied. The signature uses the same canonicalization and algorithm machinery as DKIM (RFC 6376), with the signing domain selected by the forwarder. This is the structural anchor — it allows downstream receivers to verify that the message has not been tampered with between this hop and the next ARC participant.

ARC-Seal

A signature that binds the chain together. The seal at hop i covers the ARC-Authentication-Results and ARC-Message-Signature headers added at this hop, plus all ARC headers added at every prior hop. The seal also carries the cv= tag — chain validation state — recording whether this hop considered the inbound chain valid.

The three-header structure is deliberate. The authentication results capture what was observed, the message signature anchors the message content at this hop, and the seal links the chain. A receiver evaluating the chain at the final destination verifies all three at every hop, walking the chain backward from the most recent hop to the original.

The instance counter

The i= tag orders the ARC sets. The first ARC participant adds i=1 headers, the second adds i=2, and so on. The chain continues, in principle, indefinitely, though the specification recommends receivers cap evaluation at i=50 as a defense against pathological cases.

A receiver validates the sets in instance order. The ARC-Seal at instance i must cover the ARC headers at instances 1 through i; if any header has been removed, modified, or reordered, the seal at the subsequent instance fails, and chain validation produces cv=fail. The stacking property is what makes the chain robust — a forwarder cannot retroactively rewrite an earlier authentication result without breaking every seal that came after it. A forwarder can only attest to what it observed at the moment the message arrived, and the receiver evaluates that attestation against the forwarder's reputation.

Chain validation at the final receiver

The final receiver computes the cv= value for the chain as a whole. The specification defines three values:

• cv=none. The message arrived with no ARC headers. The receiver evaluates exclusively under SPF, DKIM, and DMARC at its own hop. This is functionally identical to pre-ARC evaluation.
• cv=pass. The chain validates end to end — every ARC-Message-Signature verifies, every ARC-Seal verifies, and the instance counter is monotonic with no gaps. The receiver may now consider authentication results from earlier hops, subject to the trust model.
• cv=fail. The chain is present but does not validate — a signature or seal is broken, an instance has been removed or reordered. The receiver treats the chain as untrustworthy and evaluates exclusively under local SPF, DKIM, and DMARC.

A receiver observing cv=pass on a message that would otherwise fail DMARC at the local hop may consult the earliest ARC-Authentication-Results in the chain — the one attested by the receiver closest to the original sender. If that attested result shows SPF or DKIM passing under the original sender's domain, the message is treated as authenticated despite the local DMARC failure. This is the entire operational point of the protocol.

The trust model

ARC is only as trustworthy as the intermediate signers in the chain. A forwarder signing the chain is, in effect, vouching for the authentication results it observed. A receiver evaluating the chain must decide whether to trust each signer's attestation.

The major mailbox providers maintain reputation systems for ARC signers, analogous to those they already maintain for sending IPs and DKIM signing domains. A forwarder that consistently produces accurate attestations earns trust; one whose attestations diverge from what other signals would suggest loses it. The system is, like all of them in this protocol family, opaque and provider-specific.

ARC adoption among the major providers is now near-universal. The largest webmail platforms, the dominant business productivity suite, the legacy webmail incumbents, and the privacy-focused mail providers all both produce ARC headers on forwarded outbound mail and honor chains on inbound. The chain works in practice because the most-relevant 95% of forwarder volume is concentrated among signers whose reputation is established. The long tail is where it breaks — corporate mail tenants on older on-premise versions, niche mailing-list software, smaller hosted providers, and bespoke corporate forwarders may not participate, and messages traversing those hops still suffer the pre-ARC failure modes.

Production impact on cold outreach

The forwarded-mail fraction in B2B sending is typically 3 to 8% of total delivered volume, with the upper end concentrated in industries where the buyer routinely loops in procurement, legal, or technical evaluators. The fraction is invisible in standard sending-platform analytics, which track opens and replies at the original recipient address only; the downstream forwarded copy lives in mailboxes the sender never sees.

The conversion consequence is asymmetric. A forwarded message landing in the colleague's primary inbox produces a meeting with both the original recipient and the introduced colleague — a multi-stakeholder conversation that converts at roughly two to three times the rate of a single-stakeholder reply. A forwarded message landing in spam produces nothing, and the original recipient, observing no response, draws no further conclusions. The signal is silently lost. The operator never measures the conversion impact of ARC directly, because the alternative — sending without DMARC enforcement — is operationally worse for every other reason.

What the sending operator actually does

ARC is consumed, not produced, by the sending operator. It is attached by intermediate forwarders, not by the original sender. No DNS record to publish, no key to rotate, no policy to escalate.

The operational relevance is in downstream behaviors the sender does not control but does need to understand. A cold-outreach sender at p=reject is implicitly dependent on the major receivers honoring ARC, because a meaningful fraction of legitimate traffic will arrive via a forwarder. The sender does not configure that dependency; the sender verifies it exists. The major providers have all publicly committed to honoring ARC, and behavior is observable in seed-list testing (Chapter 13). Residual exposure is long-tail traffic to corporate tenants and niche providers — small enough in B2B sending to be tolerable.

The DMARC interaction

The deployability of p=reject in a B2B sending context is structurally dependent on ARC participation at the major receivers. A sender at p=reject without downstream ARC support loses 3 to 8% of forwarded legitimate traffic to rejection — a deliverability hit that, depending on the traffic mix, may exceed the entire margin of a successful campaign.

The reason p=reject is currently deployable at scale, and the reason DMARC enforcement progression (Chapter 3) is a realistic operational target rather than an aspirational security goal, is that ARC is now produced by every major forwarder and honored by every major receiver. The forwarding problem has been mitigated structurally, not eliminated. A sender deploying p=reject in 2026 is, in effect, betting that the residual long-tail of non-ARC-aware forwarders represents an acceptable fraction of their traffic. For B2B cold outreach to mid-market and enterprise prospects, the bet is safe. For senders concentrated in industries that still operate on older on-premise mail infrastructure, the deployment should be staged with explicit observation of forwarded-mail failure rates in aggregate reports.

Common deployment failures observed in production

• Long-tail mailing-list software that does not participate. Older self-hosted list-management packages neither produce ARC headers nor preserve the original DKIM signature. Forwarded mail through these lists fails DMARC at the destination with no chain to consult.
• Hybrid corporate mail deployments on older on-premise versions. Mail flowing through an on-premise relay before reaching cloud mailboxes may strip or invalidate ARC headers in transit. The cloud receiver, seeing a broken chain, produces cv=fail and evaluates the message under local DMARC only.
• Niche personal forwarding services. Smaller forwarding providers may not produce ARC headers, leaving forwarded mail dependent on whether SPF or DKIM survives by accident.
• Misconfigured ARC signing. A forwarder that signs the chain with a key that does not resolve in DNS, or canonicalizes headers in a way subsequent hops cannot reproduce, produces a chain that fails validation downstream. The message is then evaluated as if the forwarder had not participated — worse than the pre-ARC state, because the chain's presence may inhibit other reputation signals.
• Stripped ARC headers in transit. Aggressive corporate mail security appliances that normalize or strip non-standard headers may remove ARC headers without re-signing, breaking validation for every downstream hop. Observable in some financial-services and government inbound infrastructures.

Pre-deployment checklist

ARC has no sender-side configuration, so the checklist is one of downstream verification rather than local deployment:

• Confirm the recipient base is concentrated in receivers known to honor ARC — the major webmail platforms, business productivity suites, and privacy-focused providers
• Run a seed-list test (Chapter 13) that includes at least one forwarded path — a seed address auto-forwarding to a second seed at a different provider — to observe end-to-end ARC behavior
• In aggregate DMARC reports (Chapter 3), monitor the alignment-failure rate by source IP for IPs corresponding to known forwarders; a stable, low rate is the signal that ARC is functioning at the destinations that matter
• Before escalating to p=reject, confirm forwarded-mail failure rate is below 1% of total alignment failures
• For senders whose recipient base includes a meaningful fraction of corporate tenants on older on-premise versions, stage p=reject with explicit observation of forwarded-mail failure rates, and budget for the deliverability impact

Where ARC fits in the broader infrastructure

ARC is the protocol that makes the rest of the authentication stack operationally viable in a multi-hop mail environment. SPF, DKIM, and DMARC were specified against a single-hop assumption that does not hold in practice; ARC is the patch that preserves the original-sender authentication context across the hops the original specifications did not anticipate.

For a cold-sending estate specifically, ARC is the protocol that allows p=reject to be deployed without surrendering the 3 to 8% of legitimate traffic that traverses a forwarder before reaching its final reader. The operator does not configure ARC and does not need to understand the seal mechanics in operational depth. The operator does, however, need to understand that ARC's near-universal adoption among the major receivers is what makes DMARC enforcement a viable posture rather than a deliverability-destroying one.