ARC Chain Validator
Group ARC sets and inspect instance order, required tags, chain state and continuity.
Email SecurityHow ARC Helps Mail Survive Forwarding
Forwarding changes the machine that sends a message; mailing lists often change the message itself. ARC does not prevent those changes or turn a failure into a pass—it preserves authenticated observations so a later receiver can make a better, explicitly local decision.
SPF breaks at the new SMTP hop
SPF authenticates the connecting IP against the envelope sender domain. A forwarder accepts the original message and opens a new SMTP session from its own infrastructure. Unless that infrastructure happens to be authorized by the original envelope domain, the downstream SPF check fails. Nothing was forged; the identity that SPF evaluates simply crossed a boundary the original policy did not authorize. DMARC only counts SPF when that authenticated envelope domain also aligns with the visible From domain.
Sender Rewriting Scheme can give the forwarder an envelope domain it controls, allowing SPF to pass for the rewritten identity. That protects bounce handling and removes the raw SPF failure, but the rewritten domain normally does not align with the author’s From domain, so it does not by itself make DMARC pass. SPF was designed around the immediate transport hop. Expecting it to attest an author unchanged across arbitrary forwarding is asking the mechanism to remember evidence it never carried.
DKIM survives transport—until content moves
DKIM signs selected headers and a body hash, so ordinary forwarding can leave it valid. That is the useful contrast with SPF: a new connecting IP does not matter to the signature. Mailing lists, security gateways and forwarding services frequently modify what was signed, however. A subject prefix, footer, MIME conversion, line wrapping or rewritten link can invalidate the body hash or a signed header. Relaxed canonicalization tolerates limited whitespace changes, not editorial changes.
A list can remove the original signature and add its own, but a valid signature from the list domain does not necessarily align with the author’s From domain. Rewriting From to the list’s domain restores alignment at the cost of changing visible identity and reply behavior. No single repair is transparent. Use the Email Message Header Analyzer to separate the current receiver’s SPF, DKIM and DMARC verdicts from list headers and recorded transport hops; it parses evidence locally but does not re-verify signatures.
ARC carries observations, not immunity
An ARC-participating intermediary adds a numbered set of three fields. ARC-Authentication-Results records what it observed before making further changes. ARC-Message-Signature signs the message in the form that intermediary handled. ARC-Seal covers the ARC set and the preceding chain, making removal, reordering or dishonest extension detectable when signatures are validated. The instance number i= starts at one and increases by one at each sealing hop.
The first seal uses cv=none because there is no earlier ARC chain to validate. Later sealers state cv=pass or cv=fail for the chain they received. A downstream receiver can therefore see that a trusted intermediary observed aligned DKIM before a list footer broke it. ARC has conserved the observation and custody trail. It has not restored the original DKIM signature, changed DMARC evaluation rules, or compelled the receiver to deliver the message.
Trust the sealer, then consider the result
A cryptographically valid ARC chain proves that the listed sealers maintained that chain with the corresponding keys. It does not prove that their authentication engine was competent, that their account was not abused, or that their recorded result deserves policy weight. Receivers maintain their own trust models for ARC sealers, commonly informed by operational relationships, scale, reputation and observed accuracy. A familiar large forwarder may influence disposition; an unknown domain’s perfect chain may be ignored.
This distinction prevents a dangerous shortcut: “ARC pass” is not a universal authentication result. A receiver may use trusted upstream evidence to override a DMARC failure caused by known forwarding, may feed it only into spam scoring, or may disregard ARC completely. The original domain’s DMARC policy remains meaningful, and the receiver owns the exception. Attackers cannot make themselves trusted merely by sealing their own claim, any more than signing a statement makes the statement true.
Read the first broken seam
Start with the complete delivered header block. Group the ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results fields by instance. Sets should be complete and count upward without gaps. The first seal should say cv=none; later seals should report the prior chain. The ARC Chain Validator checks this structure, required tags and continuity locally. It does not fetch DNS keys or perform cryptographic verification.
Find the first cv=fail, missing member or numbering discontinuity and investigate the seam immediately before it. Everything later inherits a broken evidentiary chain; adding another seal cannot repair history. Then compare d= sealer domains with the Received path and read which authentication results each hop claimed. A clean structure from unexpected infrastructure is a trust question. A broken structure from a trusted provider is an implementation or message-handling incident. Those are different queues and should not share a generic “ARC failed” ticket.
Limits that ARC deliberately leaves in place
ARC does not stop malicious forwarding, guarantee inbox placement, rescue a message whose original authentication genuinely failed, or replace SPF, DKIM and DMARC at origin. It also cannot preserve evidence across a hop that strips ARC headers or refuses to seal. Privacy-sensitive systems may remove routing detail; legacy systems may know nothing about ARC. Even complete chains can accumulate signatures and header size through long paths, while one failed link makes later continuity unhelpful.
Origin senders should still maintain aligned DKIM as the forwarding-resistant primary path and a correct SPF policy for direct delivery. Forwarders should preserve the body where possible, implement SRS for envelope hygiene, authenticate before modifying, and seal after recording results. Receivers should validate cryptographically and apply a documented sealer trust policy. Cross-check the published origin controls with the SPF/DMARC/DKIM Checker; ARC explains a broken journey, but it cannot make a weak departure trustworthy.