最終更新日:2026年6月6日
sg sg-security-measures network mail-security incident_management
まず結論
メールヘッダの読み方で大切なのは、送信者が自由に名乗れる情報と、メールサーバが接続時に記録した情報を分けることです。
SG試験では、迷惑メールの配送経路や通報先を調べる場面で、次のように切り分けます。
From、Return-Path、MAIL FROM、HELOは詐称される可能性があるReceivedヘッダに記録された接続元IPアドレスは、配送経路をたどる手掛かりになる- IPアドレスの逆引き結果は、関係するネットワーク事業者を推定する材料になる
迷ったら、「送信者が名乗った情報か、受信側サーバが接続元から得た情報か」を見ます。
このページで切り分けること(先にここだけ)
このページは、迷惑メール調査でメールヘッダのどこを見るかを中心に整理します。
FromやHELO:送信側が名乗れるため、詐称されやすいReceived:メールサーバの通過記録として、接続元IPアドレスを確認しやすい- 逆引きDNS:IPアドレスから管理元や通報先の手掛かりを得る
迷ったら、「名乗り」か「接続元の記録」かを見ます。
SG試験で選択肢を切る判断軸(メールヘッダ編)
-
「
MAIL FROMで通知されたドメイン」「HELOで名乗ったホスト名」 → 送信側が指定できるため、信頼しすぎない -
「
Fromヘッダに書かれた送信者」 → 表示上の送信者であり、詐称される可能性がある -
「接続元IPアドレス」「逆引きされたホスト名・ドメイン名」 → 配送経路や通報先を調べる手掛かりとして優先する
関連記事との役割分担(混同防止)
- 送信元IPが許可されたメールサーバか確認する仕組みを学びたい → SPFとは?送信元IPでなりすましを防ぐ仕組み【SG試験】
- メール送信時の利用者認証を確認したい → SMTP-AUTHとは?メール送信時の認証方式【SG試験】
- メールサーバが踏み台にされる第三者中継を確認したい → 第三者中継とは?メールサーバを踏み台にされる仕組み【SG試験】
直感的な説明
メールヘッダは、メールの「配送記録」のようなものです。
ただし、そこに書かれている情報には、信頼しやすいものと信頼しにくいものがあります。
たとえば、荷物に貼られた差出人名は、差出人が自分で書けます。悪意があれば、別人の名前を書くこともできます。
一方で、配送センターを通過したときの記録は、配送側が残すため、差出人が自由に書き換える情報よりは調査の手掛かりになりやすいです。
メールでも同じように、送信者が名乗った From や HELO だけを信じるのではなく、どのメールサーバから受信したか、どのIPアドレスから接続されたかを見ます。
定義・仕組み
メールヘッダには、送信者や配送経路に関する複数の情報が記録されます。
代表的な項目は次のとおりです。
| 項目 | 何を示すか | SG試験での見方 |
|---|---|---|
From |
メールソフトなどで表示される送信者 | 詐称される可能性がある |
Return-Path |
エラー通知の戻り先として使われるアドレス | 詐称・なりすましの可能性を考える |
SMTP MAIL FROM |
SMTP通信で通知されるエンベロープ送信者 | 送信側が指定できるため過信しない |
SMTP HELO / EHLO |
SMTP通信の開始時に送信側が名乗るホスト名 | 任意に名乗れるため過信しない |
Received |
メールサーバが受信・中継時に追加する通過記録 | 接続元IPアドレスを確認する手掛かりになる |
特に迷惑メール調査では、Received ヘッダに含まれる接続元IPアドレスを確認します。
そのIPアドレスから逆引きDNSを行うと、対応するホスト名やドメイン名が分かる場合があります。これにより、関係するネットワーク事業者や管理元を推定し、必要に応じて通報や対策依頼につなげられます。
ただし、Received ヘッダも全てを無条件に信用するわけではありません。攻撃者が古い経路情報のように見える行を挿入することもあり得るため、自組織の受信メールサーバが追加した直近の記録から確認すると考えると安全です。
メールの配送手順やメッセージ形式は、RFC Editorの RFC 5321 や RFC 5322 で確認できます。
どんな場面で使う?
メールヘッダの読み方は、次のような場面で使います。
- 迷惑メールの配送経路や通報先を調べる
- フィッシングメールの通報先を確認する
- メールサーバが第三者中継に悪用されていないか確認する
- SPFやDKIMの検証結果と配送経路を合わせて確認する
- インシデント対応で、メールの到達経路を調査する
SG試験では、メールヘッダの細かい文法を覚えるよりも、詐称されやすい項目と、調査で優先する項目を分けることが大切です。
たとえば、選択肢に次のような表現がある場合は注意します。
| 選択肢の表現 | 判断 |
|---|---|
Fromヘッダのドメインを送信元組織として信頼する |
詐称される可能性があるため注意 |
HELOで名乗ったホスト名を送信元として信頼する |
任意に名乗れるため注意 |
MAIL FROMのアドレスを送信元として信頼する |
詐称される可能性があるため注意 |
| 接続元IPアドレスと逆引き結果を確認する | 配送経路や通報先調査の手掛かりになりやすい |
よくある誤解・混同
誤解1:Fromヘッダが本当の送信者である
From ヘッダは、利用者に表示される送信者情報です。
しかし、悪意のある送信者は、別の組織や人物を名乗って From を設定することがあります。
SG試験では、From に有名企業のドメインが書かれていても、それだけで正規メールとは判断しません。
誤解2:HELOで名乗ったホスト名は信頼できる
SMTPの HELO / EHLO は、送信側が通信開始時に名乗る情報です。
名乗りである以上、詐称される可能性があります。
選択肢で「HELOで通知されたホスト名を最も信頼できる」とあれば、慎重に判断します。
誤解3:Return-PathやMAIL FROMなら信頼できる
Return-Path や SMTPの MAIL FROM は、エラー通知の戻り先などに関係する情報です。
これらも送信側が指定できるため、迷惑メールでは詐称されている可能性があります。
送信元の調査では、Return-Path や MAIL FROM だけでなく、Received の接続元IPアドレスを確認します。
誤解4:Receivedヘッダなら全て安全に信用できる
Received ヘッダは重要な手掛かりですが、全ての行を無条件に信用するわけではありません。
メールは複数のサーバを経由するため、ヘッダには複数の Received 行が並ぶことがあります。
調査では、自組織の受信メールサーバが追加した行や、信頼できるサーバが追加した行を起点に確認します。
試験での言い換えに注意
この論点は、過去問では具体的なヘッダ項目名を並べて、どれを調査の起点にするかを問う形で出ることがあります。
ただし、記事では特定の過去問表現を丸暗記するのではなく、次の考え方で判断します。
- 送信者が自分で書ける情報は、なりすましを疑う
- 受信側のサーバが接続時に記録した情報を優先する
- IPアドレスと逆引き結果は、配送経路や通報先を考える材料にする
まとめ(試験直前用)
- メールヘッダ調査では、
From、Return-Path、MAIL FROM、HELOを過信しない。 Receivedヘッダの接続元IPアドレスは、配送経路調査の重要な手掛かりになる。- IPアドレスの逆引き結果は、関係するネットワーク事業者を推定する材料になる。
- SPF/DKIMは送信元や署名の検証、メールヘッダ解析は配送経路の調査、と切り分ける。