使い方
- メールソフトでメッセージを開き、元のメッセージやヘッダーを表示する機能を探して、最初の行から空行までをコピーします。
- 生のヘッダーに貼り付けます。ページはお使いのブラウザの中で読み取ります。
- 経路順のホップを最初のホップから最後まで読み、各ホップにかかった時間を遅延の列で読みます。
- SPFの結果、DKIMの結果、DMARCの結果を読みます。合格は緑、それ以外の結果は赤で示されます。
メールが経路を記録する仕組み
メッセージを扱うサーバーはそれぞれ、ヘッダーの一番上にReceived行を1行追加します（RFC 5321、4.4節）。その行には、受け取った相手のホスト（from）、渡し先のホスト（by）、プロトコル（with）、セミコロンの後の日付が書かれます（RFC 5322、3.6.7節）。下から読むと、行は経路を順番どおりに示します。
- ホップの遅延は、そのホップの時刻から、その前のホップの時刻を引いたものです。下から上へ読みます。
- サーバーの時計は狂うことがあるため、負の遅延や長すぎる遅延は、ネットワークより時計について多くを語ります。
アドレスとアライメント
Fromは作成者のアドレスです。Return-Pathはバウンスの送り先で、SPFが確かめるアドレスです（RFC 5322、3.6.2節と3.6.7節）。DMARCは、Fromのドメインを、SPFかDKIMが確かめたドメインと比べます。初期値の緩やかなアライメントでは、2つが組織ドメインを共有していれば足ります。厳格なアライメントでは、同じ名前でなければなりません（RFC 7489、3.1節と3.1.1節）。Reply-Toが設定されていれば、返信の送り先になります（RFC 5322、3.6.2節）。
認証の結果
受信側のサーバーは、確かめた結果をAuthentication-Resultsヘッダーに記録します。その最初の語は、そのサーバーのauthserv-idです。各結果は、spf=pass、dkim=pass、dmarc=passのように、方式と値の組です（RFC 8601、2.2節と2.7節）。Received-SPFは、SPFの確認を1つ記録する古いヘッダーです（RFC 7208、9.1節）。
例：3つのサーバーを通ったメッセージ
初期値のヘッダーは、client.example.netから出たメッセージが、relay.example.netとmx.example.orgを通って、mail.example.netに届いたことを示します。下から読むと、3つのReceived行の時刻は09:59:21、10:00:03、10:02:14です。そのため、2番目のホップは42秒、3番目のホップは2分11秒かかりました。
Authentication-Resultsヘッダーは、example.netについてspf=pass、dkim=pass、dmarc=passを報告しています。返信の送り先は[email protected]で、別のドメインです。送信者のドメインから外れる返信は確かめる価値があるため、ページはそれに印を付けます。
| 項目 | 値 |
|---|---|
| Received行の数 | 3 |
| 最初のホップから最後のホップまでの時間 | 2分53秒 |
| SPF | pass（example.net） |
| Reply-To | 返信はexample.orgに送られ、example.netには送られません。意図したものか確かめてください（RFC 5322、3.6.2節）。 |
よくある質問
なぜ、ホップはReceived行と逆の順番で表示されるのですか？
各サーバーは自分のReceived行を一番上に付けるため、最も新しいホップがヘッダーの最初に来ます（RFC 5321、4.4節）。ページはそれを逆にするため、最初の行はメールが最初に出たサーバーになります。
Received行は信頼できますか？
各サーバーは自分の行を書きますが、その中の名前とアドレスは、そのサーバーが報告したものです。送信者も独自の行を加えることがあります。一番上の行は最も新しく、受信側に最も近いサーバーが付けたもので、最も注意を払う価値があります。
遅延が負の値になるのは、何を意味しますか？
あるホップが、その前のホップより早い時刻になっているのは、2つのサーバーの時計が食い違っているか、タイムゾーンを誤って読んだことを意味します。ネットワークが速いのではなく、時計の誤りの兆候です。
Authentication-Resultsとは、何ですか？
受信側のサーバーが、SPF、DKIM、DMARCなど、確かめた内容と各結果を示すために加えるヘッダーです（RFC 8601）。最初の語がそのサーバーの名前を示し、信頼してよいのは、自分の受信サーバーのヘッダーだけです（2.5節）。
Reply-Toのドメインがなぜ重要なのですか？
Reply-Toが設定されていれば返信はそこに送られ、なければFromに送られます（RFC 5322、3.6.2節）。別のドメインを指していれば、返信はメッセージの送信元のドメインから外れます。それ自体は誤りではありませんが、確かめる価値があります。
このツールは、ヘッダーをどこかに送りますか？
いいえ。ヘッダーはお使いのブラウザの中で読み取られます。送られたり保存されたりすることはありません。
出典
- RFC 5322（英語）: Internet Message Format
- RFC 5321（英語）: Simple Mail Transfer Protocol、トレース情報
- RFC 8601（英語）: Message Header Field for Indicating Message Authentication Status
- RFC 7208（英語）: Sender Policy Framework（SPF）
- RFC 7489（英語）: DMARC
数値と文章の最終確認日：2026年11月10日火曜日。