メールヘッダー解析 & ホップタイムライン
ヘッダーを貼り付けると配信のタイムラインを組み立てます。認証結果はヘッダーの記載をそのまま読むもので、独自の検証は行いません。
ブラウザ内でローカルに実行ローカル処理 ·
ヘッダーを貼り付けると配信のタイムラインを組み立てます。認証結果はヘッダーの記載をそのまま読むもので、独自の検証は行いません。
ブラウザ内でローカルに実行メッセージのヘッダーブロック（Gmail の「元のメッセージを表示」、Outlook の「メッセージのソースを表示」、Apple Mail の「すべてのヘッダ」で見られるテキスト）を貼り付け、「ローカルで解析」を押します。Received 行を 1 つのホップとして並べ、隣り合うホップ間の時間を「遅延」列に出し、メッセージ自身が記載している認証結果を読み取ります。
処理はすべてタブ内で完結します。送信は行われず、保存もされず、ヘッダーが端末の外に出ることはありません。これは結果の限界でもあります。VoriTools はヘッダーの記載をそのまま表示するだけで、メールサーバーに接続せず、DNS レコードを照会せず、署名を検証しません。
各メールサーバーは自分の Received 行をメッセージの先頭に挿入します。だからブロックは新しい順に並び、本文に一番近い Received 行を書いたのは最初に処理したサーバー、一番上の行は受信サーバーです。解析側はブロックを下から読むため、ホップ 1 が最も古く、最後の行が受信サーバーになります。
遅延は 2 つのタイムスタンプの差であり、タイムスタンプはそれを書いたサーバーの時計とタイムゾーンに基づきます。大きな遅延は、グレイリスティング、スパムフィルター、再送キューなど、どこかで待ったことを意味します。パネルが知らせるのはホップであり原因ではありません。5 分（300 秒）を超える遅延は検出項目になり、一つ上のホップより古いタイムスタンプのホップは「タイムスタンプが逆戻りしている」として報告されます。これは遅れた時計であり、マイナスの遅延ではありません。
概要はヘッダーの記載を読んだもので、検証した結果ではありません。メカニズム=結果の組を記載順に並べ、bestguesspass はそのまま表示して失敗として扱いません。neutral と none には印を付けません。fail・softfail・temperror・permerror は、報告したメカニズムとともに検出項目に表示されます。
同じメカニズムが複数回出てくることもしばしばあります。メーリングリストを通ったメッセージはリストと差出人の両方の署名を持つため、dkim=pass の隣に dkim=fail が並ぶことがあります。中継サーバーが ARC-Authentication-Results に記録した結果には ARC の印が付き、受信サーバー自身の結果と並んで表示されます。ARC のみの場合はその旨を出します。受信したプロバイダーが出した結果ではないからです。確認するには、DKIM セレクター、SPF レコード、DMARC ポリシーを DNS ツールで調べる必要があります。
検出項目は、Message-ID や Date ヘッダーの欠落、From と異なる Reply-To ドメイン、遅延したホップ、逆戻りするタイムスタンプを抽出します。Authentication-Results ヘッダーが無い場合と、ヘッダーはあるが SPF・dkim・dmarc・arc の結果が入っていない場合は別々に知らせます。ヘッダー行がまったく無いテキストに対しては、欠落フィールドの一覧ではなく明確なエラー 1 件を返します。
知っておくべき限界が 2 つあります。ヘッダーは差出人が制作できるテキストです。偽造されたヘッダーブロックも書かれた通りに表示され、pass の行単体では何も証明しません。また、読み取るのはヘッダーブロックだけです（最初の空行で終わります）。X-Received や別名のトレースヘッダーはホップにならず、転送メッセージの本文に引用された古いヘッダーブロックも反映されません。