セキュリティ調査 / 2026-09-11 / Updated 2026-09-11

フィッシングメールをヘッダーとドメイン情報から調べる

フィッシングメールは、有名企業やサービスをかなり自然に装っていることがあります。

本文や表示上の送信者名だけでは、実際にどこから送られてきたメールなのか判断しにくい場合があります。

そこで、実際に複数の不審メールを受信したことをきっかけに、表示されている本文だけでなく、メールヘッダーやドメイン情報まで確認するようになりました。

今回の調査では、危険なリンクを開くことなく、メールそのものから取得できる情報を中心に確認しました。

主に行ったのは次の作業です。

  • 元メールを .eml 形式で保存
  • SHA-256ハッシュ値を計算
  • メールヘッダーを確認
  • SPF、DKIM、DMARCの結果を確認
  • URLとホスト名を抽出
  • 登録ドメインを特定
  • ドメイン登録情報を確認
  • 複数メールを比較
  • 調査結果を再利用できる形で整理

目的は、単に「怪しいメールかどうか」を判断することだけではありません。

メールからどのような証拠を取り出せるのか、そしてその情報を後から確認できる形でどのように残せるのかを整理することでした。

最初に原本を保存する

不審なメールを調べるときは、可能な限り最初に原本を保存します。

.eml ファイルとして保存すると、通常のメール画面では見えにくい詳細なメールヘッダーや配送経路の情報も残すことができます。

あわせて、原本ファイルのSHA-256ハッシュ値も計算します。

ハッシュ値だけで、そのメールが悪意のあるものか判断できるわけではありません。

ここでの目的は、後から分析を進めても、保存した原本が変更されていないことを確認できるようにすることです。

基本的な流れは次のようになります。

元メール
→ EMLとして保存
→ SHA-256を計算
→ 作業用データを解析

原本保存と分析作業を分けることで、後から調査手順を確認しやすくなります。

メールヘッダーで確認する項目

メール画面に表示される From は、メールを構成する情報の一部にすぎません。

不審なメールでは、複数のヘッダー情報と認証結果をあわせて確認します。

例えば次のような項目です。

  • From
  • Return-Path
  • Reply-To
  • To
  • Received
  • Message-ID
  • Authentication-Results
  • SPF
  • DKIM
  • DMARC

どれか1つの項目だけで、正規メールかフィッシングメールかを断定することはできません。

複数の情報を比較して、不自然な組み合わせがないか確認します。

例えば、表示上の送信者名は正規企業に見えても、実際の送信ドメインやReturn-Path、リンク先ドメインが全く関係のないものになっている場合があります。

SPF・DKIM・DMARCは重要だが、それだけでは判断しない

SPF、DKIM、DMARCは重要な確認材料です。

ただし、これらの認証結果は文脈とあわせて確認する必要があります。

例えば SPF=pass であっても、その認証に成功したドメイン自体が、メール本文で名乗っている企業とは無関係ということがあります。

そのため、

SPFがPASSした
＝
このメールは安全

とは考えません。

むしろ重要なのは、

どのドメインが認証されたのか
→ そのドメインは、メール内で名乗っている組織と関係があるのか

という確認です。

URLとドメインを確認する

不審メールに含まれるURLも重要な情報です。

ただし、調査のためにリンクをクリックする必要はありません。

保存したメールの内容からURL文字列を抽出し、次のような情報を整理できます。

  • ホスト名
  • 登録ドメイン
  • パス
  • 不自然なサブドメイン
  • メールソース上で確認できるリダイレクト情報

特に重要なのが登録ドメインです。

長いホスト名では、一見すると正規サービス名が含まれているように見えることがあります。

例えば、

account.example.login.suspicious-domain.example

のような文字列では、左側の単語だけでは判断できません。

どの部分が実際の登録ドメインなのかを正しく特定する必要があります。

ドメイン登録情報を確認する

登録ドメインが分かったら、必要に応じてRDAPなどの公開情報を確認します。

例えば次のような情報があります。

  • Registrar
  • Creation Date
  • Expiry Date
  • Domain Status
  • Name Server

ただし、ドメイン登録情報だけで、そのドメインが悪意のあるものだと断定することはできません。

メールヘッダーやURLなど、他の証拠と組み合わせて確認します。

例えば、長年運営されている有名サービスを装ったメールに、全く無関係な新しいドメインが使われている場合は、追加確認が必要な材料になります。

複数メールを比較する

1通のメールだけでも多くの情報を確認できますが、複数のメールを比較するとパターンが見えやすくなります。

私は抽出した情報を表形式で整理し、次のような項目を比較しています。

項目 比較する内容の例
Sender 表示名、メールアドレス
Return-Path バウンス処理に使われるドメイン
Authentication SPF、DKIM、DMARC
Message-ID ドメイン、送信システム
URL ホスト名、登録ドメイン
Domain Data Registrar、日付、Name Server
File Evidence ファイル名、SHA-256

こうして構造化すると、複数メールで同じインフラが使われているのか、別のキャンペーンなのかを比較しやすくなります。

手作業からローカル分析ツールへ

複数のメールで同じ作業を繰り返すうちに、証拠抽出の多くは自動化できると考えるようになりました。

そこで、Windows上で動作するローカル分析ツールの作成を始めました。

想定している流れは次のとおりです。

EMLファイル
→ ハッシュ計算
→ ヘッダー抽出
→ 認証結果抽出
→ URL・ドメイン抽出
→ 比較データ作成
→ Markdown分析レポート

設計上重視しているのは、原本メールを外部サービスへ送らなくても、基本的な証拠抽出をローカルで完結できることです。

AIは解釈や文章整理を支援できますが、ハッシュ計算、ヘッダー抽出、URL抽出といった機械的な処理はローカルでも実行できます。

証拠と解釈を分ける

この調査で特に重要だと感じたのが、「確認できた事実」と「そこからの解釈」を分けることです。

例えば、

確認できた事実

  • 送信ドメイン
  • SPF結果
  • DKIM結果
  • URLのホスト名
  • ドメイン登録日

解釈

  • 送信インフラが名乗っている企業と関係するか
  • 複数メールが同じ送信元に関連している可能性があるか
  • フィッシングメールとして扱うべきか

この2つを分けて整理することで、推測を事実として扱ってしまうリスクを減らせます。

再利用できる調査フローへ

一連の流れをまとめると、次のようになります。

保存
→ 抽出
→ 確認
→ 比較
→ 解釈
→ 記録

対象はセキュリティですが、基本的な考え方は普段行っている調査業務とも共通しています。

疑問・不審な事象
→ 証拠収集
→ 情報整理
→ 検証
→ 再利用できる知識・ツール

今回の経験は、フィッシングメールを調べるだけでなく、再利用可能なローカル分析ツールを作るきっかけにもなりました。

本記事は、実際の技術調査経験をもとに、一般化した調査手順を整理したものです。メールアドレス、個人を特定できる情報、公開に不要なIOCなどは掲載していません。ドメイン登録情報やメール認証結果だけで悪意の有無を断定せず、複数の情報を組み合わせて判断する必要があります。

Research Notes一覧へ戻る