機能の説明

メールヘッダー分析は、メールメッセージの生ヘッダー（RFC 5322）を解析し、読みやすいフォレンジックレポートに変換します。すべての調査結果をひと目で判断できる評決バナー（なりすましの兆候を検出 / 不審な兆候 / クリーン）、メッセージが通過したすべての Received サーバーをホップ間の遅延つきで追う配送タイムライン、SPF / DKIM / DMARC の認証評決、そして**異常（anomalies）**の完全なリスト - From アドレスと Return-Path の不一致、想定外の場所を指す Reply-To、不審なメーラー文字列、時刻の逆行といったなりすましシグナル - が揃います。

レイアウトは左右分割です。左に生ヘッダーの入力、右に調査結果をスクロールしても見える位置に固定されたスティッキーパネルでライブ分析レポートを表示します。メッセージがフィッシングらしく見えて、直感ではなく証拠が欲しいときに使うツールです。

使い方

生ヘッダーを取得します: Gmail ならメッセージを開いて ⋮ → 元のメールを表示 で、本文より上のすべてをコピーします。Outlook では ファイル → プロパティ → インターネットヘッダー です。
メールの生ヘッダー に貼り付けます（またはサンプルを押すと内蔵のデモメッセージを読み込みます）。
ヘッダーを分析 を押します。レポートは右側に、評決バナーの下から表示されます。
まず評決バナーを読みます: 赤（危険）= 少なくとも 1 つの重大ななりすまし指標、琥珀色 = 警告のみ、緑 = 異常なし。バナーの右側には重大度の内訳があります（critical × 1、warnings × 2、notices × 1）。
各セクションを確認します: 配送経路（最も古いホップから順に、遅延バッジは色分け表示）、認証（SPF/DKIM/DMARC の各行）、異常（各調査結果とその証拠）、すべてのヘッダー（折り返しを展開した完全なヘッダー表）。
共有リンクをコピーを押すと、入力内容をそのまま運ぶ URL が得られます - 開いた人には同じ分析が表示されます。

認証行の読み方。 各行にはメカニズム名、結果の語、根拠となった句が表示されます:

SPF - 送信サーバーの IP は、エンベロープのドメイン（smtp.mailfrom）から認可されていたか? pass = 認可済み。softfail = 認可されていないが、ドメインは受信側に「不審扱い」することしか求めていない。fail = 明示的に認可なし、なりすましの可能性大。neutral = ドメインは何も主張しない。none = ポリシー未公開。temperror = 一時的な DNS 障害。permerror = レコードが破損・不正。行の追加テキストには、検査されたエンベロープアドレスが示されます。
DKIM - メッセージは暗号署名されているか、その署名は検証されるか? pass = 署名は有効（行には署名した selector と、公開されていれば header.d の署名ドメインを表示）。fail = 署名はあるが破損 - ヘッダーか本文が転送中に改変された。none = 未署名。temperror/permerror = 公開鍵を取得できなかった。詳細行には生の句、たとえば dkim=pass header.s=sel2026 header.b=AbCdEf が表示されます。
DMARC - 表示上の From: ドメインのポリシーはこのメッセージを受け入れたか? pass = アライメントと基礎チェックの両方が満たされた（行には評価された header.from ドメインと、そのドメインの p= ポリシー none、quarantine、reject を表示）。fail = メッセージが主張するアイデンティティを、そのドメイン自身のポリシーは受け入れない。none = From ドメインは DMARC レコードを公開していない。

サンプルが実演する重要な注意点: 3 つすべてが pass でも、メッセージはフィッシングの餌でありうる。 SPF/DKIM/DMARC が検証するのは送信ドメインが本当にこのメッセージを送ったということであり、送信者が信頼できることでも、Reply-To が思っている場所を指すことでもありません。だからこそ、認証パネルが完全に「緑」でも異常リストが意味を持ちます。

Received チェーンの読み方。 メールサーバーはそれぞれの Received ヘッダーを先頭に追記するため、ツールは下から上へ解析します: ホップ 1 が発生元サーバー、最後のホップがあなたのメールボックスです。連続するホップ間には遅延バッジ - 2 つのホップのタイムスタンプから計算された経過時間 - が表示されます:

緑、1 秒未満（ミリ秒で表示）: 通常の中継。
琥珀色、1〜60 秒: キューイングかグレイリスティング - 通常は問題ありません。
オレンジ、60 秒超: 遅い中継、メールプロバイダーのスロットリング、またはキューで滞留したメッセージ。
グレーの「不明な遅延」: そのホップに解析可能なタイムスタンプがなく、この区間を測定できない（同時に info 異常としても報告されます）。

時刻が逆行している場合（ホップ N がホップ N−1 より前の日時）、専用の警告が出ます: 2 台のサーバーの時計がずれているか、誰かが Received ヘッダーを偽造したかのどちらかです。

例

内蔵のサンプルを読み込んでヘッダーを分析を押すと、すべての機能が一度に確認できます。サンプルの検証済み出力:

配送経路 - 3 ホップ、古い順: sender.evil.example → mail.relay.example（ESMTP）、次に mail-sor-f41.google.com → mx.google.com（ESMTPS、+7.0 s）、そして mx.google.com（SMTP、+3.0 s）。
認証 - すべて pass: SPF は billing@legit-shop.com に対して pass、DKIM は selector sel2026 で pass、DMARC は legit-shop.com に対してポリシー quarantine で pass。
評決バナー - 赤: critical × 1、warnings × 2。異常は次のとおりです:

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Critical: Return-Path（bounce@evil.example）が From（support@legit-shop.com）と一致しない - エンベロープの送信者と表示上の送信者が異なる。 さらに、転送先を変えられた Reply-To と大量配信メーラーの X-Mailer に対する警告。認証が通ったのは、legit-shop.com が本当に送信したからです - それでもメッセージは、実態と異なる見た目に仕立てられています。

クリーンなメッセージ（エンベロープが From と一致、署名済み、認証済み）:

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ 緑の評決、「なりすましの兆候は検出されません」、異常ゼロ。

不合格パネル - 3 つのメカニズムすべてが赤く表示されます:

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ SPF は spoof@wrong.example に対して softfail、DKIM は fail（selector sel1）、DMARC はポリシー reject で fail - 厳格な受信側ならバウンスすべきメッセージです。

偽造ホップ - 時刻が逆行している例:

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ 警告: ホップ 2 のタイムスタンプはホップ 1 より 10.0 秒前 - サーバー間の時計ずれか、偽造された Received ヘッダー。

補足事項

アナライザーが検査するすべてのシグナル（括弧内は重大度）:

Return-Path と From の不一致（critical）- エンベロープの送信者（Return-Path、バウンスの宛先）が、表示上の From と異なるアドレスを使用。典型的ななりすまし。正当なメーリングリスト中継でもよく見られます。
Reply-To が From と異なる（warning）- 返信が第三のアドレスに転送されます。サポートデスクなら正当、From があなたの銀行なら致命的。
不審なメーラー文字列（warning）- X-Mailer または User-Agent に大量送信ツールに関連するトークンを含む: bulk、mass mail、massmail、storm、flood、bomber、grabber、harvest、spambot、stealth、anonymous、dark、crack（大文字小文字を区別せず部分一致）。
解析可能なタイムスタンプのないホップ（info）- その区間の遅延を計算できません。「不明な遅延」バッジとして表示されます。
時刻の逆行（warning）- 前のホップより前の時刻を持つホップ: 時計ずれか Received ヘッダーの偽造。
Authentication-Results ヘッダーなし（info）- SPF/DKIM/DMARC の状況をこのメッセージからはまったく検証できません。

知っておくべきパーサーの詳細:

プライベート: 解析は 100% クライアント側 - ヘッダーがブラウザーの外に出ることはありません。
ヘッダーは RFC 5322 に従って折り返しを展開します（継続行は空白で始まる）。解析は最初の空行（本文との区切り）で停止し、ヘッダー形式でないゴミ行は読み飛ばされます。
メッセージが複数の Authentication-Results ヘッダーを運ぶ場合、各メカニズムの最初の評決が採用され、残りは無視されます。
ホップのタイムスタンプは各行の Received の最後の ; の後ろから読まれます（日付らしき最初のトークンへのフォールバックつき）。（PDT）のような末尾のゾーンコメントは無視されます。
欠けている情報は推測されず報告されます: 不明な遅延、検証できない認証、チェーンの断片はすべて、黙って空白にするのではなく明示的な調査結果として表面化します。
関連ツール: PII Redactor、Defang / Refang、
Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.
。