「このメール、なんとなく怪しい……」
迷惑メールやフィッシングメールを受信したとき、送信者名や本文を見るだけでは判断できないことがあります。
そんなとき確認したいのがメールヘッダーです。
メールヘッダーには、
From:
Return-Path:
Reply-To:
Received:
Message-ID:
Authentication-Results:
など、メールがどこから送られてきたのかを調査するための情報が記録されています。
さらに、
spf=pass
dkim=pass
dmarc=pass
といったメール認証の結果が記録されていることもあります。
しかし、実際にメールヘッダーを開いてみると情報量が多く、
「結局どこを見ればいいの?」
となりがちです。
そこで今回は、メールヘッダーをChatGPTに解析してもらい、迷惑メールやなりすましメールの調査を補助してもらう方法を紹介します。
ただし、メールヘッダーにはメールアドレスやサーバー名、IPアドレスなどが含まれることがあります。
会社のメールヘッダーなどを、そのままChatGPTへコピーするのは避け、内容を確認してから利用します。
メールヘッダーには何が書かれている?
例えばメールヘッダーには、次のような情報があります。
From: sender@example.com
To: user@example.net
Reply-To: contact@example.org
Return-Path: bounce@example.com
Authentication-Results:
spf=pass
dkim=pass
dmarc=pass
実際には、これよりはるかに多くの情報が記録されています。
特に確認したいのが、
- From
- Reply-To
- Return-Path
- Received
- Authentication-Results
などです。
Fromは普段目にする送信者
From:は、通常メールソフトで送信者として表示されるアドレスに関係する項目です。
例えば、
From: Support <support@example.com>
です。
メールソフトでは、
Support
だけが大きく表示されることもあります。
そのため、
表示名だけを見て送信者を信用しない
ことが重要です。
表示名は正規企業と同じような名称にすることも可能だからです。
Reply-Toも確認する
個人的に不審メールを調査するときに確認したい項目の一つが、
Reply-To:
です。
例えば、
From: support@example.com
Reply-To: another@example.net
のようになっていたとします。
この場合、そのメールへ返信すると、From:とは異なるアドレスへ送信される可能性があります。
ただし、
FromとReply-Toが違う=迷惑メール
と断定することはできません。
問い合わせシステムやメール配信サービスなど、正当な理由で異なるアドレスを使用している場合もあります。
重要なのは、
「なぜ違うのか確認する材料にする」
ことです。
Return-Pathとは?
メールには、
Return-Path:
という項目もあります。
例えば、
Return-Path: <bounce@example.net>
です。
From:とは異なるアドレスになっていることがあります。
これもメール配信サービスなどでは珍しいことではありません。
そのため、
Fromが違う
Return-Pathが違う
だけで迷惑メールと判断するのではなく、
SPF
DKIM
DMARC
Received
ドメイン
本文
URL
など、複数の情報を組み合わせて確認します。
Receivedはメールの配送経路を調べる手掛かり
メールヘッダーには複数の、
Received:
が記録されていることがあります。
例えば、
Received: from mail-a.example.net
by mail-b.example.net;
Received: from mail-b.example.net
by mail-c.example.net;
といった形です。
これはメールがサーバーを経由するたびに追加されていく情報です。
そのためReceivedを確認すると、
メールがどのような経路を通ってきたのか
を調査する手掛かりになります。
ただし、Receivedヘッダーは読み方に注意が必要です。
一般的には、受信側で新しいReceivedが上に追加されていくため、配送経路を追う際には下側から確認していくことがあります。
また、送信元側が付与した情報を無条件に信用できるとは限りません。
Authentication-Resultsを確認する
迷惑メール調査で非常に参考になるのが、
Authentication-Results:
です。
例えば、
Authentication-Results:
spf=pass
dkim=pass
dmarc=pass
のような情報があります。
ここから、
SPF
DKIM
DMARC
の認証結果を確認できます。
SPFとは?
SPFは簡単にいうと、
「このIPアドレスから、このドメインのメールを送信してよいか」
を確認する仕組みです。
メールヘッダーには、
spf=pass
や、
spf=fail
などが記録されることがあります。
ほかにも、
softfail
neutral
none
temperror
permerror
などの結果があります。
DKIMとは?
DKIMでは、メールに電子署名を付け、受信側で検証します。
例えば、
dkim=pass
なら、DKIM署名の検証に成功していることを示します。
一方、
dkim=fail
なら、署名検証に失敗しています。
ただし、
DKIM=passだから、そのメールの内容まで安全だと保証されるわけではありません。
ここは注意が必要です。
DMARCとは?
DMARCはSPFやDKIMの結果に加えて、メールに表示されるFromドメインとの整合性などを利用して認証します。
メールヘッダーには、
dmarc=pass
や、
dmarc=fail
などが記録されることがあります。
SPF・DKIM・DMARCについては、それぞれ別記事で詳しく解説しておくと内部リンクを作りやすくなります。
【ここにSPF/DKIM/DMARC関連記事への内部リンク】
SPF・DKIM・DMARCがpassなら安全?
ここは非常に重要です。
例えば、
spf=pass
dkim=pass
dmarc=pass
だったとします。
それだけを見て、
「安全なメールだ」
と判断するのはおすすめできません。
攻撃者が自分で取得したドメインを正しく設定してメールを送信すれば、そのドメインについてSPF・DKIM・DMARCがpassになることもあり得ます。
つまり認証結果は、
「このメールは安全か?」
そのものを判定する仕組みではありません。
送信ドメインやURL、メール本文、送信者との関係なども確認する必要があります。
ChatGPTにメールヘッダーを解析させる
メールヘッダーは非常に長いため、人間がすべて読むのは大変です。
そこでChatGPTを補助的に利用します。
例えば、
以下のメールヘッダーを解析してください。
1. From
2. Reply-To
3. Return-Path
4. Receivedから分かる配送経路
5. SPFの結果
6. DKIMの結果
7. DMARCの結果
8. 不自然と思われる点
9. このヘッダーだけでは判断できないこと
を分けて説明してください。
推測とヘッダーから確認できる事実は
明確に分けてください。
という形で質問します。
いきなりメールヘッダーを貼らない
ここで注意したいのが情報漏えいです。
メールヘッダーには、
送信者メールアドレス
受信者メールアドレス
IPアドレス
メールサーバー名
社内ドメイン名
Message-ID
内部システムの情報
などが含まれている可能性があります。
業務メールの場合は、組織の生成AI利用ルールも確認する必要があります。
メールヘッダーを匿名化する
例えば、
From: taro@example-company.jp
To: hanako@example-office.jp
Reply-To: contact@example-company.jp
を、
From: USER-A@example-a.test
To: USER-B@example-b.test
Reply-To: CONTACT@example-a.test
のように置き換えます。
サーバーについても、
mail01.example-company.jp
を、
MAIL-A
のように変更できます。
IPアドレスも、解析に実際の値が必要なければ、
192.168.10.20
を、
192.168.x.x
などに変更できます。
匿名化しすぎにも注意
例えばReceivedをすべて、
Received: from XXXXX by XXXXX
Received: from XXXXX by XXXXX
Received: from XXXXX by XXXXX
としてしまうと、配送経路が分からなくなります。
そこで、
Received: from MAIL-A by MAIL-B
Received: from MAIL-B by MAIL-C
のように関係性を残します。
これはWindowsやLinuxのログをChatGPTへ渡す場合と同じ考え方です。
Message-IDにも注意
メールヘッダーには、
Message-ID:
があります。
例えば、
Message-ID: <xxxxxxxx@example.com>
です。
Message-IDにはドメイン名などが含まれる場合があります。
ブログへメールヘッダーを掲載したり、外部サービスへ渡したりする場合は、Message-IDも確認します。
ReceivedのIPアドレスを全部消すべき?
これは調査目的によります。
例えば、
外部
↓
メールゲートウェイ
↓
内部メールサーバー
という配送経路を確認したい場合、IPアドレスやホスト名の関係が重要になることがあります。
その場合は、
PUBLIC-MAIL-A
MAIL-GATEWAY-A
INTERNAL-MAIL-A
などに置き換えます。
重要なのは、
実際の情報を隠しながら関係性を残すこと
です。
ChatGPTに時系列で整理してもらう
Receivedが大量にある場合は、
Receivedヘッダーを配送順に整理してください。
それぞれについて、
・送信元
・受信先
・日時
・不自然な点
を表にしてください。
ヘッダーから確認できないことは
推測で埋めないでください。
と依頼できます。
メール配送経路が複雑な場合に便利です。
FromとReply-Toが違う場合も聞いてみる
例えば、
From: support@example-a.test
Reply-To: user@gmail.example
となっていたとします。
ChatGPTには、
FromとReply-Toが異なっています。
この違いから分かることと、
この情報だけでは判断できないことを
分けて説明してください。
と質問します。
ここで、
Reply-Toが違う
=
フィッシングメール
と即断しないことが重要です。
URLの確認にも注意
怪しいメールにはURLが記載されていることがあります。
しかし、
不審なURLを実際にブラウザで開いて確認するのは避けます。
表示文字列と実際のリンク先が異なる場合もあります。
例えば、
表示:
https://example-bank.test
実際:

https://example-phishing.test
というケースです。
メールソフトでリンク先を確認する場合も、誤クリックには注意します。
AIに「迷惑メールか判定して」は避ける
ChatGPTに、
このメールは迷惑メールですか?
とだけ聞くより、
このメールについて、
【確認できる事実】
【不審な点】
【正常なメールでも起こり得る点】
【追加確認が必要な点】
に分けてください。
安全・危険を断定せず、
判断材料を整理してください。
と質問する方が使いやすいです。
AIに最終判定を任せるのではなく、
調査材料を整理してもらう
という使い方です。
私ならこの順番で調査する
怪しいメールを受信した場合、私なら次のように確認します。
怪しいメールを受信
↓
Fromを確認
↓
Reply-Toを確認
↓
Return-Pathを確認
↓
Receivedを確認
↓
Authentication-Resultsを確認
↓
SPF / DKIM / DMARCを確認
↓
リンク先などを安全な方法で確認
↓
必要な情報を匿名化
↓
ChatGPTで情報を整理
↓
必要ならメール管理者側のログを確認
ChatGPTだけで安全性を判断するわけではありません。
ChatGPTへ渡すプロンプトのテンプレート
最後に、実際に使いやすい形にまとめます。
不審なメールを調査しています。
以下はメールヘッダーです。
メールアドレス、ドメイン名、IPアドレスなどは
必要に応じて匿名化しています。
【メールヘッダー】
ここに貼り付ける
以下について解析してください。
1. From
2. Reply-To
3. Return-Path
4. Receivedから読み取れる配送経路
5. SPFの結果
6. DKIMの結果
7. DMARCの結果
8. Fromドメインとの整合性
9. 不自然と思われる点
10. 正常なメールでも起こり得る点
11. このヘッダーだけでは判断できないこと
12. 次に確認すべき項目
「ヘッダーから確認できる事実」と
「推測」を明確に分けてください。
安全なメール・危険なメールと断定せず、
判断材料を整理してください。
この形にしておくと、AIの回答を整理しやすくなります。
WindowsやLinuxのログ解析と考え方は同じ
これまでWindowsやLinuxのログをChatGPTで解析する方法も紹介しました。
メールヘッダーについても基本的な考え方は同じです。
必要な情報を取得
↓
機密情報を確認
↓
匿名化
↓
ChatGPTへ渡す
↓
事実と推測を分ける
↓
原因候補を整理
↓
人間が確認する
という流れです。
【内部リンク】
ChatGPTにWindowsのエラーログを解析させる方法|どこまで貼って大丈夫?
【内部リンク】
ChatGPTにLinuxのエラーログを解析させる方法|journalctl・messagesをAIで調査
まとめ
メールヘッダーには、迷惑メールやなりすましメールを調査するためのさまざまな情報が含まれています。
特に、
From
Reply-To
Return-Path
Received
Authentication-Results
SPF
DKIM
DMARC
などは重要な確認ポイントです。
ただし、
SPF=pass
DKIM=pass
DMARC=pass
だから安全、
あるいは、
FromとReply-Toが違う
から迷惑メール、
という単純な判断はできません。
そこでChatGPTを使って、
「メールヘッダーから確認できる事実を整理する」
という使い方をすると便利です。
AIに安全・危険を決めてもらうのではなく、
大量のヘッダー情報を読み解くための調査補助
として利用するのがポイントです。
そして業務メールを扱う場合は、メールアドレス、IPアドレス、ホスト名などが含まれていないか確認し、組織のルールに従ったうえで利用しましょう。


コメント