Inputs
Example
Paste headers to distinguish structural completeness and recorded cv=pass/cv=fail from cryptographic validation, which is not performed.
ARC Chain Validator
Check ARC instance structure, continuity, and recorded cv state without claiming cryptographic validation or sealer trust.
Use it when forwarded mail needs a structural ARC check before cryptographic validation and sealer-trust review.
Why forwarded mail fails authentication
Mail forwarding breaks the two pillars of sender authentication in different ways. SPF fails because the forwarder sends from its own servers, which the original domain never authorized. DKIM often survives — until a mailing list adds a subject tag or a footer, at which point the signature dies too. The receiving system then sees a DMARC failure on a message that was, at its origin, perfectly authentic.
ARC exists to carry the evidence across those hops. Each intermediary adds a numbered set of three headers: ARC-Authentication-Results records what the hop observed, ARC-Message-Signature signs the message as it looked at that hop, and ARC-Seal seals the chain so later hops can tell whether it was extended honestly. This validator parses pasted headers into those sets and checks what can be checked structurally: instance numbering, required tags, chain-validation values, and continuity from one hop to the next.
Working through a pasted ARC chain
Paste the complete header block of the delivered message, not a fragment. Read the instance sequence first: sets must count 1, 2, 3 without gaps, each instance needs all three members, and the first seal must carry cv=none. Every later seal records cv=pass or cv=fail. A recorded cv=fail is valid syntax and reports that the sealer judged the prior chain failed; it does not by itself make the ARC tag list malformed.
Then look at who signed. The d= domains in the chain tell you which infrastructure actually handled the message, which is often more interesting than the validation state itself. A chain is only as useful as the trustworthiness of its sealers: cv=pass from a domain you have never heard of is a claim, not a credential. Cross-reading with the Received chain in the Email Header Analyzer shows whether the ARC story and the transport story agree.
Structural validation versus cryptographic proof
Headers stay in the browser; nothing is uploaded. The validator checks structure, required tags, ordering, and continuity — the failure modes that account for most real-world ARC breakage. It does not fetch DNS keys or verify the signatures cryptographically, because honest verification requires resolver access and exact canonicalization of the message body, which a pasted header block cannot provide. For a final verdict, check what your receiving MTA's authentication results say about the same chain.
Frequently asked questions
Does a structurally valid chain mean the mail is trustworthy?
No. It means the parsed fields satisfy the structural rules. The tool does not verify signatures or sealer identity, and a structurally valid chain may legitimately record cv=fail. Trust requires separate cryptographic validation and receiver policy.
Can ARC make a failing DMARC message deliverable?
Sometimes. Large receivers may override a DMARC failure when a sealer they trust attests that authentication passed upstream. That is a per-receiver policy decision, not a protocol guarantee, and small receivers often ignore ARC entirely.
What does cv=fail in the middle of a chain tell me?
That the seal at that instance could not validate the chain before it. Everything after that point inherits the failure; ARC has no repair mechanism. The hop to investigate is the one just before the first fail.
Why do mailing lists show up so often in ARC chains?
Because they are the classic case that breaks both SPF and DKIM at once: they resend from their own infrastructure and modify the message. Lists were a major motivation for ARC, so chains sealed by list providers are extremely common.
The instance numbers jump from 1 to 3. What happened?
An intermediary either stripped a set or numbered its own set wrongly. Both invalidate the chain as evidence, because continuity is exactly what the numbering is supposed to guarantee.
Do I need to publish anything in DNS to receive ARC mail?
No. ARC sealing is done by intermediaries with their own keys. You only need DNS records for ARC if your infrastructure seals messages itself — receiving and evaluating chains requires nothing.