ARC チェーンビューアー
メーリングリストや転送サーバーはメッセージを変更し、DKIM を壊します。ARC を使うと、それぞれの中継者が受信時に確認した内容を記録し、シールできます。転送されたメッセージを貼り付けると、チェーンをホップごとに確認し、DNS-over-HTTPS で取得した鍵ですべてのシールと署名を検証して、メッセージが変更された箇所を特定できます。
メッセージがこのブラウザーの外に送信されることはありません。Cloudflare の DNS-over-HTTPS リゾルバーに送信されるのは、シールと署名が参照する鍵の名前（セレクター._domainkey.ドメイン）だけで、それも鍵を照会するボタンを押したときに限られます。
メッセージはこのブラウザー内にとどまります。チェーンの解析と検証はここで行います。
Why forwarded mail needs ARC
DKIM and SPF authenticate the server that sent a message, and DMARC requires one of them to pass for the domain in the From field. A mailing list or a forwarding service breaks both. It sends the message from its own servers, so SPF checks the wrong host, and it usually changes the message — a footer, a tag in the Subject, a re-encoded body — so the original DKIM signature no longer verifies. A receiver that applies DMARC strictly then rejects perfectly legitimate mail.
The Authenticated Received Chain, ARC (RFC 8617), lets each intermediary say what it saw before it changed anything, and seal that statement so the next hop can trust it.
What each hop adds
Every intermediary that takes part adds one ARC set of three header fields, numbered by the instance tag i= (1 for the first intermediary, up to 50):
- ARC-Authentication-Results records the authentication results the hop computed when the message arrived: SPF, DKIM, DMARC and the ARC status of the chain so far, in the syntax of Authentication-Results (RFC 8601).
- ARC-Message-Signature is a DKIM-style signature over the message as the hop forwards it: the body and a list of header fields, with the same canonicalization rules as RFC 6376.
- ARC-Seal signs the ARC header fields themselves — every set up to and including its own — and records in
cv=what the hop concluded about the chain it received:nonefor the first hop,passorfailafter that.
The viewer lists the sets from the first hop to the last. For each hop it shows who sealed it, with which key and algorithm and when, which header fields its message signature covers, and the results it recorded, method by method.
How the chain is validated
The viewer follows the validation steps of RFC 8617 §5.2. The chain fails at once if the newest seal already says cv=fail, if a set is missing a field or has two of one, if the instances do not run 1, 2, 3 without a gap, or if a cv= value contradicts the hop's position. Then the newest ARC-Message-Signature must verify against the message as it is now, and every ARC-Seal, newest first, must verify over the ARC fields it covers. The keys are published like DKIM keys, at selector._domainkey.domain.
Two answers come out of that. The first is the verdict: the chain is valid, broken, or cannot be checked until the keys are known. The second is the oldest pass: going back from the newest hop, the oldest ARC-Message-Signature that still verifies. If hop 2's signature verifies but hop 1's does not, the message was changed after hop 1 signed it and before hop 2 did — the viewer marks that spot in the chain.
What a valid chain proves
A valid chain proves that each hop's record of what it saw is intact. It does not prove that the hops are honest: a receiver decides which intermediaries it trusts, typically large mailbox providers and mailing lists it knows. When the first hop recorded dkim=pass for the From domain, the message's DKIM signature fails now, and the chain is valid, the viewer says so explicitly: a receiver that trusts that hop can use its record instead of the broken result. When the chain is broken, the same record proves nothing, and the viewer says that too.
It also flags what looks wrong: seals dated out of order, and results produced by a server outside the sealing domain. The message's own DKIM signatures are verified alongside the chain; the DKIM debugger shows step by step why one of them fails.
What runs in your browser
Parsing, canonicalization, every signature and seal check, and the comparison with the recorded results run in this page; the message is never uploaded. When you press the button that looks up the keys, the page asks Cloudflare's resolver over DNS-over-HTTPS for the key records the seals and signatures name — those public names are the only thing sent. You can also paste a key record or a PEM public key for each name, which is how the bundled examples work: their keys belong to example domains and are not in DNS. The example from RFC 8617 Appendix B can be read but not verified, because the RFC publishes no keys for it.