このツールについて
メールヘッダーを見たくなるのは、だいたい三つの場面です。このメールはなぜ二時間も遅れて届いたのか、銀行を名乗るこのメールは本物なのか、自分のメールはなぜ迷惑メールに入ったのか。手で読むのは骨が折れます。逆順に並んだ十数行の Received、タイムゾーンがばらばらの時刻、略語だらけの Authentication-Results。このメールヘッダー解析ツールはブラウザの中でヘッダーを分解し、メールが通った経路、各ホップでの待ち時間、受信サーバーが SPF・DKIM・DMARC についてどう判断したか、そして DKIM 署名が今日検証し直しても通るかを並べて見せます。アップロードはしません。ページが行う唯一の通信は DKIM 公開鍵の問い合わせで、それも「DKIM を検証」ボタンを押したときだけです。selector._domainkey.ドメイン という名前を公開の DNS-over-HTTPS サービス（Cloudflare、失敗時は Google）に送るので、そのサービスにはあなたの IP アドレスが見えます。DNS の問い合わせとはそういうものです。メール本文、宛先、ヘッダーそのものはどこにも送られません。
経路をたどって、どこで止まったかを見つける
Received ヘッダー一行が一ホップです。ページは古い順に並べ直し、各ホップを、名乗っている送信ホスト、括弧内の逆引き名と IP、受け取ったホスト、プロトコル（SMTP、ESMTPS、ESMTPSA、LMTP など）、時刻に分解します。プロトコルの文字は RFC 3848 に従って読み解き、S があれば TLS 接続、A があれば送信側が認証済みなので、途中で暗号化されていたかどうかが分かります。ホップの遅延は前のホップとの時刻差で、横棒グラフにして最も長いホップを赤く示します。遅れたメールはたいていそこで待たされています。負の遅延はエラー扱いにせず「時計のずれ」と表示します。メールサーバーの時計は合っていないことが多いからです。時刻がない、または読めないホップは「計算不可」として、後続のホップには影響させません。プライベートアドレス（RFC 1918、127.*、::1）は「内部転送」と印を付けます。IP アドレスは文字として表示するだけで、位置情報の照会はしません。それには IP を第三者の API に送る必要があるからです。
Authentication-Results は、信じていい一行だけ信じる
Authentication-Results（RFC 8601）は受信サーバーが判断を書き残す場所で、spf=pass、dkim=fail、dmarc=none のほか、arc、iprev、bimi が付くこともあります。ページは各ヘッダーを authserv-id と方式ごとに分解し、結果ごとに平易な一文を添えます。softfail、temperror、permerror、neutral が実際に何を意味し、よくある原因は何か、という説明です。一覧の上には警告を一つ置いています。経路上のどのサーバーも、送信者自身も、Authentication-Results ヘッダーを追加できます。信用できるのはあなた自身の受信サーバーが書いた行だけで、途中のホップや送信者が書いた行は何の証明にもなりません。ARC ヘッダー（RFC 8617）はインスタンスごとにまとめて参考表示しますが、このバージョンでは ARC シールの検証は行いません。
ブラウザで DKIM を検証する。使うのは今日の鍵
このページの売りは、誰かの結論を写すのではなく、本物の DKIM 検証（RFC 6376）を行うことです。DKIM-Signature ごとにタグを解析し、s= と d= が示す公開鍵を取得し、署名対象のヘッダーを c= の指定どおりに正規化して、WebCrypto で署名を確かめます。h= に列挙されているのにメールに存在しないヘッダーは、規格どおり空文字列として扱うので、署名後に追加されたヘッダーが通ることはありません。rsa-sha256 は RSASSA-PKCS1-v1_5 で検証します。ed25519-sha256（RFC 8463）はブラウザの WebCrypto が Ed25519 に対応していれば検証し、対応していなければ失敗ではなく「検証不可」と報告します。rsa-sha1 は検証はしますが RFC 8301 で非推奨であることを示し、1024 ビット未満の RSA 鍵は同じ RFC の規定どおり拒否します。結論は四つのうちどれかです。通過、失敗（理由付き。鍵が見つからない、p= が空で鍵が失効済み、x= の期限切れ、署名不一致、本文ハッシュ不一致、鍵が短すぎる）、検証不可（DNS エラー、未対応のアルゴリズム、本文がない）、形式エラー。l= のある署名には、本文の先頭 N バイトしか署名されておらず、その後ろに付け足された内容は署名外だという警告を出します。取得する鍵は今公開されている鍵だということも忘れないでください。送信後に鍵が交換されていれば古いメールは検証に失敗しますが、偽物だからではありません。
ヘッダーだけ、.eml、.msg で、どこまで検証できるか
本文ハッシュ bh= を確かめられるのは、完全な .eml ファイルを入れたときだけです。本文の生のバイト列が必要だからです。ヘッダーだけを貼った場合でも、ヘッダー署名（bh= の値を含む）は検証できるので、「ヘッダーは改ざんされていない、本文は検証できない」という結論になります。.msg は常にこの状態です。受信したメールの .msg はトランスポートヘッダーをプロパティとして保存しますが元の MIME 本文は残さず、送信前に保存した .msg にはトランスポートヘッダー自体がないため、.msg の検証はヘッダー止まりです。EML ビューアーと MSG ビューアーからはワンクリックでこのページにメールを渡せます。受け渡しは sessionStorage 経由で、URL には乗せません。概要カードには送信者の三つの身元、From のドメイン、Return-Path のドメイン、DKIM の d= のドメインを並べ、DMARC の整合は RFC 7489 の relaxed モードで組織ドメインを基準に判定します。隣のボタンで From ドメインをメール DNS チェックのページに渡し、SPF・DKIM・DMARC の設定を確認できます。URL に入るのはそのドメインだけで、これは公開情報です。
このページが言わないこと
「このメールは安全」「本物」とは決して言いません。どの検査が通り、どれが失敗したかを言うだけです。DKIM が通っても、証明されるのは d= のドメインがこのメールに署名したことだけで、そのドメインがあなたの思う会社のものかどうかは別問題です。SPF は再検証しません。SPF はメールを受け渡した IP とその時点の DNS に依存するので、後からブラウザで実行し直しても意味がなく、受信サーバーが記録した結果を表示するにとどめます。転送されたメール、メーリングリストを経由したメール、会社のメールゲートウェイに書き換えられたメールで DKIM が失敗するのはよくあることで、失敗の説明にもそう書きます。X-Spam-Status や X-Microsoft-Antispam のような迷惑メール判定ヘッダーは、形式が公開されていないので原文のまま表示し、解釈はしません。Markdown レポートと JSON 出力は宛先アドレスを既定で伏せるので、そのまま共有できます。