ARC: Authenticated Received Chain (RFC 8617)

ARC (Authenticated Received Chain) exists to patch a specific, well-known hole: SPF and DKIM both break when a message passes through an intermediary, and DMARC has no way to know the message authenticated before it was relayed. ARC carries that earlier result forward as an authenticated “chain of custody,” so a final receiver can see what authentication looked like at each hop (RFC 8617 §1, §2). It is genuinely useful and genuinely limited, and this page is honest about both.

The 60-second version

• SPF fails when the IP changes; DKIM fails when content is modified. Forwarders, mailing lists, and scanners do both routinely (RFC 8617 §1, §2).
• ARC records, at each participating hop, what authentication looked like on arrival, in an ARC Set of three header fields sharing one instance number i= (RFC 8617 §4).
• The three fields: ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS), ARC-Seal (AS) (RFC 8617 §4.1.1-§4.1.3).
• A receiver MAY use a valid ARC chain to override a DMARC failure. It is not obligated to. ARC is advisory, not a pass (RFC 8617 §7).
• ARC “is not a trust framework” - a malicious actor can seal spam (RFC 8617 §9.3).
• As of 2026 it is still not widely deployed (RFC 9989 §7.4).

Why ARC exists

SPF and DKIM are both fragile across intermediaries, in different ways (RFC 8617 §1, §2):

• SPF breaks on the IP change. A forwarder relays from its own IP, which is not in your SPF record, so SPF fails for your domain.
• DKIM breaks on content modification. A mailing list that rewrites the Subject: or appends a footer changes bytes inside the signed region, so the signature fails.

When both break, DMARC fails at the final receiver even though the message was perfectly authentic when it left the origin. The receiver simply has no trustworthy record of that original result. RFC 8617 §7 names the concrete cases ARC targets: mailing lists conveying the original authentication state to subscribers, message-scanning services that break the SPF path and DKIM, multi-tier MTA processing, and giving receivers a basis for DMARC local-policy overrides.

The three header fields (one ARC Set)

Each participating intermediary adds exactly one ARC Set: three header fields that all share the same instance value i= (RFC 8617 §4).

ARC-Authentication-Results (AAR)

Records the authentication assessment as the ARC-participating ADMD saw it at arrival - essentially an Authentication-Results snapshot plus an instance tag (RFC 8617 §4.1.1).

ARC-Authentication-Results: i=1; mx.relay.example;
    spf=pass smtp.mailfrom=news@origin.example;
    dkim=pass header.d=origin.example;
    dmarc=pass header.from=origin.example

ARC-Message-Signature (AMS)

Conveys custodianship over the message. Same syntax and semantics as a DKIM signature, with key differences: no v= tag, the i= tag is the ARC instance, ARC header fields MUST NOT be included in its coverage, and Authentication-Results header fields MUST NOT be included (RFC 8617 §4.1.2).

ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example; s=arc2026;
    h=from:to:subject:date; bh=...; b=...

ARC-Seal (AS)

Protects the integrity of the AAR and AMS fields across the whole chain, in ascending instance order, and adds a cv= tag carrying the Chain Validation Status (RFC 8617 §4.1.3).

ARC-Seal: i=1; a=rsa-sha256; d=relay.example; s=arc2026; cv=none; b=...

The Seal differs from a DKIM signature in important ways (RFC 8617 §4.1.3):

• It does not cover the message body - there is no bh= tag.
• Only relaxed header canonicalization is used.
• Only the tags a, b, d, s, t, cv, and the instance i= are allowed; the h= tag is not allowed.

The chain

ARC Sets accumulate, one per hop, into a single ordered chain.

Origin sends ──► Relay A adds Set i=1 (cv=none)
                       │
                       ▼
                 List B adds Set i=2 (cv=pass), re-sealing the prior set
                       │
                       ▼
                 Final receiver validates the whole chain

Rules of the chain (RFC 8617 §4.2.1, §4.4, §5.2):

• Instance values are integers starting at 1, incremented by each new ARC Set, with a valid range of 1 to 50.
• A message can have at most 50 ARC Sets; more than that means Chain Validation Status fail.
• The first set (i=1) MUST carry cv=none; every later set MUST carry cv=pass (or cv=fail to mark a chain already broken).
• A message can have only one chain. Once it is broken (cv=fail), it cannot be continued or repaired.

Chain Validation Status (cv=)

Status	Meaning
none	No ARC chain existed on the message when it arrived.
pass	The chain validated successfully.
fail	The message has a chain whose validation failed.

All ARC validation failures, including DNS failures encountered during validation, are permanent - there is no retry (RFC 8617 §5.2.1). This is unlike SPF, where a DNS hiccup yields a retryable temperror.

ARC and DMARC: advisory, not a pass

This is the single most important point, and the one most likely to be oversold. ARC does not produce a DMARC pass. RFC 8617 §7 frames ARC chain assessment as something a receiver MAY use to override a DMARC failure disposition - permission, not obligation, and not a substitute for SPF/DKIM alignment.

RFC 9989 reinforces the limited expectation from the DMARC side: §7.4 notes ARC exists as a method to let mailing lists work without modifying the From: line, but adds that “as of this document’s publication, none of the methods have become widely used.” So in 2026 you should design as if most receivers will not act on your ARC chain.

The honest limits

• ARC is not a trust framework. A valid chain does not make any handler in it trustworthy; a malicious actor can seal spam to try to aid delivery (RFC 8617 §9.3). A receiver still has to decide whether it trusts the sealer.
• It adds DNS load. Validation costs up to 2*N DNS queries for a chain of N sets (validating N AMS plus N AS signatures) (RFC 8617 §9.4, §9.2).
• Failures are permanent. No retry, even on transient DNS errors (RFC 8617 §5.2.1).
• It is experimental and not widely used. RFC 8617 is Experimental, and adoption remains thin as of 2026 (RFC 9989 §7.4).

Common confusion / what does NOT change

• “ARC makes DMARC pass through a mailing list.” Only if a receiver chooses to honor your chain, which it is not required to do (RFC 8617 §7). It is advisory.
• “A valid ARC chain means the mail is trustworthy.” No. ARC conveys what authentication looked like, not whether the handler is honest (RFC 8617 §9.3).
• “ARC replaces SPF/DKIM/DMARC.” No. It sits alongside them to preserve their earlier result; it does not authenticate the origin itself.
• “You can re-start a broken chain.” No. Once cv=fail, the chain is over (RFC 8617 §5.2).

What Egressif does

ARC matters most as a receiving and intermediary concern, so where we relay or handle mail we seal correctly - one well-formed ARC Set per hop, AMS and AS built to spec, the chain left intact. But we are honest with senders about what it buys: ARC is advisory and thinly deployed, so we do not rely on it to rescue alignment. The durable fix for forwarded and list mail is aligned DKIM that survives the relay in the first place, with ARC as a supplement, not a substitute.