メールヘッダー解析ツール
受信したメールの生ヘッダー（Received:・Authentication-Results: 等）を貼り付けると、配送経路をホップごとに解析し、SPF/DKIM/DMARCの認証結果も一覧表示します。解析は100%ブラウザ内で完結します。
Received: ヘッダーの節（clause）の意味
| 節（clause） | 意味 |
|---|---|
| from | このメールを渡してきた直前のサーバーのホスト名・IPアドレスで、この行を書いた受信側サーバーが記録したものです。送信者は偽の Received 行をいくらでも書き足せるため、最も古い行ほど偽装されやすくなります。実際の送信元IPの判断には、自分の管理下の受信サーバーが書いた行のうち最も古いもの（本ツールの一覧では、自分側のサーバーが by に初めて現れるホップ）の from を使ってください |
| by | このホップでメールを受け取ったサーバー（自分のメールサーバー等）のホスト名 |
| with | 使用された配送プロトコル（例: ESMTP・ESMTPS・SMTP）。ESMTPSはTLSで暗号化された配送を意味する |
| for | 配送先の受信者メールアドレス。メーリングリストや複数宛先の場合は省略されることが多い |
| timestamp | このホップがメールを受信した日時。時刻とタイムゾーンを記録するのは、この行を書いた受信側のサーバーです（RFC 5321 §4.4）。ホップ間の日時差分が配送遅延の目安になります |
Authentication-Results: の各フィールドの意味
| フィールド | 意味 |
|---|---|
| SPF | SPF（Sender Policy Framework）認証結果。送信元IPが、送信元ドメインがDNSで許可したIPアドレス一覧に含まれるかを検証する |
| DKIM | DKIM（DomainKeys Identified Mail）認証結果。メール本文・主要ヘッダーへの電子署名が、送信ドメインの公開鍵で検証できたかを示す |
| DMARC | DMARC（Domain-based Message Authentication, Reporting & Conformance）認証結果。SPF・DKIMの結果とFromヘッダーのドメインの整合性（アライメント）を検証した総合判定 |
メールヘッダーから配送経路をたどる
受信したメールの生ヘッダーを貼り付けると、Received: をホップごとに分解して配送経路を示し、Authentication-Results: に記録された SPF・DKIM・DMARC の判定結果も一覧にします。解析はすべてブラウザ内で終わるため、貼り付けた内容が外部へ送られることはありません。
読み方で最初に押さえるべきは、Received: は下から上へ読むという点です。 各サーバーはメールを受け取るたびに自分の行を一番上へ足していくため、最も古い経路が一番下、最後に受け取ったサーバーが一番上になります。そしてより重要なのが、これらのヘッダーは誰でも偽装できるという点です。 送信元は好きなだけ Received: を捏造して先頭に並べられます。信用してよいのは、自分の管理下にあるサーバーが書いた行と、そこから上だけで、それより下は「そう名乗っている」以上の意味を持ちません。Authentication-Results: も同じで、どのサーバーが書いた判定なのかを見ないと、判定そのものが偽物でありえます。
使い方
- 生ヘッダーを貼り付ける メールソフトの「元のメッセージを表示」「ソースを表示」から取れます。
- Receivedを下から上へ読む 一番下が最初の送信元、一番上が最後に受け取ったサーバーです。
- 認証結果を確かめる SPF・DKIM・DMARC の判定が並びます。
- どこから信用できるかを見極める 自分の管理下のサーバーが書いた行より下は、偽装されている可能性があります。
使いこなすためのヒント
- Gmailでは「メッセージを開く」→右上の縦三点メニュー→「メッセージのソースを表示」から生ヘッダーを取得できます。Outlookでは「ファイル」→「プロパティ」→「インターネットヘッダー」に表示されます。
- Received: ヘッダーは新しい順（受信側が先頭）にメール本文へ追加されるため、本ツールはこれを送信元→受信側の時系列順に並べ替えて表示します。
- 中継サーバーの時計がずれていると「前ホップからの遅延」がマイナスになることがあります。マイナス表示は必ずしも異常な遅延ではなく、単なる時刻同期のズレの可能性が高いです。
- SPF/DKIM/DMARCがすべて「合格」でも、なりすましメールでない保証にはなりません。認証は送信ドメインの正当性を検証するものであり、ドメイン自体が悪意ある第三者に取得されているケースは検出できません。
- 複数のReceivedホップの間で急激に遅延が伸びている箇所があれば、その区間のメールサーバーで配送遅延・スパムフィルタでの足止めが発生している可能性があります。
活用シーン
迷惑メールの出所を調べる
本当の送信元IPは、信用できる最も下の Received: に現れます。
なりすましを見破る
表示名やFromは簡単に詐称できるため、認証結果を見て判断します。
配送の遅れを追う
各ホップの時刻を見ると、どこで滞ったかが分かります。
自社のメールが認証を通っているか確かめる
自分宛にテスト送信して、SPF・DKIM・DMARC が pass しているかを見ます。
メールヘッダーの用語
- Received
- メールを受け取ったサーバーが自分の行を一番上に足していくヘッダーです。 経路は下から上へ読みます。
- Authentication-Results
- 受信側が行った SPF・DKIM・DMARC の判定を記録するヘッダーです。誰が書いたかが重要です。
- Return-Path
- 配送に失敗したときの戻り先です。SPF はこのドメインに対して検査されます。
- From
- 表示される差出人です。ここは自由に書けるため、これだけでは送信者の証明になりません。
- Message-ID
- メールを一意に識別する文字列です。同じメールの重複を見分けるのに使われます。
- ホップ
- メールが経由した1つのサーバーのことです。各ホップが1行の
Received:を残します。
よくある質問
余談ですが ― メールヘッダーは「デジタルの消印」の集合体
手紙に押される消印が、投函した郵便局・日時を記録するのと同じように、電子メールのReceived:ヘッダーは、そのメールが経由したすべてのサーバーが自分自身のタイムスタンプを刻んで残す「デジタルの消印」です。SMTPプロトコル（RFC 5321）は、メールを中継するすべてのサーバーに対し、自分の情報をヘッダーの先頭に追加することを義務付けており、これによってメール1通ごとに配送経路の完全な記録が自然に蓄積されていきます。
この仕組みが実務で最も役立つのは、迷惑メールの送信元調査です。ただし注意が必要なのは、Received:ヘッダーも差出人欄（Fromヘッダー）と同じく、送信者が自由に捏造できるという点です。送信者は偽のReceived:行を好きなだけ書き足してからメールを送り出せるため、一番古い（一番下の）行ほど偽装されている可能性が高くなります。確実に信用できるのは、自分の管理下にある受信サーバーが書いた行だけです。そのうち最も古い行は、自分のサーバーが外部から接続を受けたときに記録したもので、その from に書かれた接続元IPアドレスは送信者が偽ることができません。迷惑メール対策の専門家がまず確認するのも、この「自分のサーバーが記録した最初の接続元」です。
SPF・DKIM・DMARCという3つの認証技術は、この「消印」だけでは防ぎきれないなりすまし対策として後から追加されました。SPFは送信元IPがドメインの許可リストに載っているかを、DKIMは電子署名でメール内容が改ざんされていないかを、DMARCはこの両者とFromヘッダーの整合性を総合判定します。2024年にGoogleとYahooが大量送信者に対しDMARC対応を事実上義務化したことで、Authentication-Results:ヘッダーは一般の受信メールでも当たり前に見られるようになりました。
普段は意識することのないメールヘッダーですが、一度中身を開いてみると、そのメール1通が地球上のどのサーバーを何秒かけて経由してきたのかという、目に見えないインターネットの旅路が克明に記録されていることに気づかされます。