不審メールを受け取った時に、メールヘッダー、Authentication-Results、Received、SPF/DKIM/DMARCをどう確認し、何を保存・報告するかを整理。情シス・SaaS管理者が初動判断に使えるチェックリスト形式で解説します。
冒頭要約
不審メールを受け取ったとき、本文や表示名だけで安全・危険を判断すると誤りやすい。メールヘッダーには、配送経路、送信ドメイン認証、返信先、受信時刻など、初動判断に必要な証跡が残る。
ただし、メールヘッダーは「攻撃者を特定する決定打」ではない。見るべき目的は、クリックや添付開封の前に止まること、証跡を保全すること、情シスやCSIRTへ正しく渡すことだ。
この記事では、フィッシング疑いのメールを受け取った読者が、危険な調査に踏み込まずに、ヘッダーの確認方法、初動対応、エスカレーション判断を実務で使える形に整理する。
ここでは防御・確認・報告のための読み方に限定します。攻撃再現、送信元偽装の手順、悪用コード、実在組織を対象にした探索方法は扱いません。メール原本の転送やヘッダー共有は、自社の情報管理ルールに従ってください。
読者別の影響
メールヘッダーを読む目的は、立場によって少し違う。全員が細かい仕様を暗記する必要はないが、どこまで自分で確認し、どこから専門チームへ渡すかを分けておくと初動が速くなる。
| 読者 | 影響 | まずやること |
|---|---|---|
| 個人・一般社員 | 不審メールを削除するか、報告するか迷いやすい | リンクや添付を追加で開かず、ヘッダーまたは原本を保存して報告する |
| 情シス・ヘルプデスク | 同じメールが他社員にも届いたか、隔離が必要か判断する | From、Return-Path、Received、URL、添付、受信者範囲を記録する |
| 開発者 | GitHub、SaaS、CI/CD通知を装うメールの真正性を確認する | 通知元サービスの正規アプリや監査ログでも同じイベントがあるか確認する |
| SaaS管理者 | SaaSログイン通知、共有通知、OAuth同意通知の悪用を見落としやすい | メールだけでなく、SaaS監査ログ、MFA、セッション、転送ルールを確認する |
| CSIRT・SOC | 影響範囲、タイムライン、封じ込め判断が必要になる | ヘッダー全文、メール原本、クリック有無、対象アカウント、報告時刻を揃える |
特に重要なのは、ヘッダー確認を「一人で真偽を断定する作業」にしないことだ。迷ったメールほど、フィッシング確認チェックリストとフィッシング報告テンプレートに沿って証跡を残す。
まず確認すること
不審メールのヘッダーを見るときは、上から全部読むよりも、確認する順番を固定する方が安全だ。次の項目だけでも、初動判断に必要な材料をかなり揃えられる。
| 確認項目 | 見る理由 | 判断のポイント |
|---|---|---|
| From | 画面に表示される差出人 | 表示名ではなく、実際のメールアドレスとドメインを見る |
| Reply-To | 返信先 | Fromと違う場合は、正当な運用か、誘導先のすり替えかを確認する |
| Return-Path | バウンス先 | 送信基盤や配信サービスの手がかりになることがある |
| Received | 配送経路 | 受信までの経路と時刻を追う。ただし途中の記録だけで送信者を断定しない |
| Authentication-Results | 送信ドメイン認証の結果 | SPF、DKIM、DMARCの結果を確認する |
| Message-ID | メッセージ識別子 | 同一メール検索やメールゲートウェイ調査の手がかりにする |
| URL・添付 | ヘッダー外の確認対象 | 追加で開かず、メール本文・ゲートウェイ・サンドボックスなど社内手順で扱う |
Google Workspaceでは、Gmailの「メッセージのソースを表示」からヘッダー全文を確認できる。Microsoft 365では、メッセージヘッダーや管理画面の分析機能を使って確認できる。どちらの場合も、ヘッダーだけを見て終わらせず、受信者、添付、リンク、操作履歴と合わせて見る。
Authentication-Resultsは、受信側が見た認証結果を記録するヘッダーです。SPF、DKIM、DMARCのpass/failは重要な材料ですが、転送、メーリングリスト、正規の外部配信サービスでも期待通りに見えないことがあります。failだけで攻撃と断定せず、送信経路と業務文脈を合わせて確認します。
初動対応
やること
不審メールを受け取った直後は、調査より保全を優先する。証跡が残っていれば、後からメールゲートウェイ、SaaS監査ログ、端末ログへつなげられる。
| 順番 | やること | 目的 |
|---|---|---|
| 1 | リンク、添付、QRコード、返信を追加で行わない | 被害拡大を止める |
| 2 | メール原本、ヘッダー全文、受信時刻、差出人、件名を保存する | 後続調査の材料を残す |
| 3 | 自分が行った操作を時系列でメモする | クリック、入力、添付開封、返信の有無を明確にする |
| 4 | 社内の指定窓口へ報告する | 同報メールの検索、隔離、注意喚起へつなげる |
| 5 | 入力や同意をした場合はアカウント保護を依頼する | セッション失効、パスワード変更、MFA再登録、OAuth同意確認を進める |
手を動かす練習をしたい場合は、学習用のメールヘッダー分析ハンズオンとフィッシングメール判定ミニCTFで、架空メールを使って確認順序を試せる。
やらないこと
初動でよくある失敗は、善意で追加調査をしてしまうことだ。危険なURLを開いたり、添付を展開したり、外部サービスへヘッダー全文を貼り付けたりすると、被害や情報漏えいを広げる場合がある。
| やらないこと | 理由 |
|---|---|
| 不審リンクを開いて確認する | アクセスしただけで追跡、認証誘導、端末リスクにつながる可能性がある |
| 添付ファイルを個人端末で開く | マルウェアや情報漏えいのリスクがある |
| メールを削除してから相談する | ヘッダー、Message-ID、添付、受信者情報が失われる |
| SNSや外部チャットにヘッダー全文を貼る | 個人情報、社内ドメイン、メール基盤の情報が含まれることがある |
| fail判定だけで取引先を攻撃者扱いする | 正規配信サービス、転送、設定不備の可能性もある |
記録すべきこと
報告を受ける側が動きやすいように、次の項目を揃える。最初から完璧でなくてもよいが、時刻と操作有無だけは曖昧にしない。
| 記録項目 | 書き方の例 |
|---|---|
| 受信日時 | 2026-07-03 09:20 JST |
| 差出人表示名・メールアドレス | 表示名とアドレスを分けて記録する |
| 件名 | 原文のまま記録する |
| 自分の操作 | 開いていない / リンクを押した / 入力した / 添付を開いた |
| ヘッダー全文 | 社内指定の方法で添付または保存する |
| 気になった点 | 返信先が違う、DMARC fail、本文のURLが公式と違う、など |
| 追加で見たログ | サインインログ、メール転送ルール、SaaS監査ログの確認有無 |
メールヘッダー確認の後にサインインログやSaaS監査ログへ進む場合は、セキュリティログの読み方を併用すると、時刻、主体、起点、操作、結果の整理がしやすい。
判断基準
メールヘッダーは、1つの値だけで白黒を付けるものではない。危険度は、認証結果、要求内容、操作有無、対象アカウントの重要度、同報範囲を組み合わせて判断する。
| 危険度 | 状況 | 初動判断 |
|---|---|---|
| 高 | リンクを押した、認証情報を入力した、MFAを承認した、OAuth同意をした、添付を開いた | すぐに情シス/CSIRTへエスカレーションし、セッション失効やアカウント保護を検討する |
| 中 | ヘッダー上の認証結果が不自然、Reply-Toが別ドメイン、本文URLが公式と異なる、同報が多い | メール原本を保全し、メールゲートウェイや同一Message-ID検索へ進む |
| 低 | 開封のみで、リンク・添付・返信なし。正規通知の可能性もある | 削除だけで終わらせず、必要に応じて報告し、類似メールの有無を確認する |
エスカレーションすべき条件は、あらかじめ組織で決めておきたい。たとえば、管理者アカウント、経理、採用、開発者、役員、SaaS管理者に届いたメールは、同じ内容でも優先度が上がる。送信ドメイン認証の失敗だけでなく、業務上の権限とデータへの影響を合わせて見る。
迷った場合は、フィッシング報告テンプレートに沿って「受信日時」「操作有無」「気になった点」「ヘッダー全文」を渡す。報告の品質が揃うと、SOCや情シスは検索、隔離、注意喚起、認証ログ確認へ進みやすくなる。
よくある誤解
SPFがpassなら安全という誤解
SPFは、送信元ホストがそのドメインから送ってよいかを確認する仕組みだ。攻撃者が自分で取得したドメインを正しく設定して送る場合、SPFがpassすることはある。SPFのpassは「そのメールが読者にとって安全」という意味ではない。
DKIMがpassなら本文が信用できるという誤解
DKIMは、署名された範囲が途中で改ざんされていないことを確認する材料になる。ただし、署名したドメインが期待するブランドや取引先と一致するとは限らない。From、署名ドメイン、本文の要求内容を合わせて確認する。
DMARC failなら必ず攻撃という誤解
DMARC failは重要なシグナルだが、正規の外部配信、転送、メーリングリスト、設定不備でも発生し得る。DMARCレポートを継続的に読む運用は、DMARCレポートの見方と初動対応に整理している。
Receivedを逆順に読めば送信者が特定できるという誤解
Receivedヘッダーは配送経路の手がかりになるが、途中の経路や書式だけで攻撃者や送信者を断定するのは危険だ。実務では、メールゲートウェイ、SaaS監査ログ、端末ログ、ユーザー操作メモを同じ時刻で突き合わせる。
ヘッダーを読めない人は報告できないという誤解
一般社員がすべてのヘッダーを解釈する必要はない。重要なのは、削除せず、追加操作をせず、原本やヘッダーを社内ルールに沿って渡すことだ。学習目的なら、まずフィッシングメールの見分け方から始めるとよい。
関連用語・関連ページ
| 目的 | ページ |
|---|---|
| 用語を確認する | メールヘッダー、SPF、DKIM、DMARC、フィッシング |
| 実務で確認する | フィッシング確認チェックリスト、フィッシング報告テンプレート |
| 学習する | メールヘッダー分析ハンズオン、メール認証 SPF/DKIM/DMARC |
| 練習する | フィッシングメール判定ミニCTF、パスワードリセットメールのトリアージ |
| 関連ニュースを読む | DMARCレポートの見方と初動対応、不審なメール転送ルールの初動対応 |
公式情報・参考情報
- RFC 5322: Internet Message Format - メールメッセージ形式の基礎仕様。
- RFC 8601: Message Header Field for Indicating Message Authentication Status - Authentication-Resultsヘッダーの仕様。
- RFC 7208: Sender Policy Framework (SPF) - SPFの仕様。
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures - DKIM署名の仕様。
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) - DMARCの現行仕様。
- Google Gmail Help: Trace an email with its full header - Gmailでヘッダーを表示・コピーする公式ヘルプ。
- Microsoft Defender for Office 365: Anti-spam message headers - Microsoft 365環境でのメッセージヘッダー確認の公式情報。
