フィッシングメールを分析する：メッセージからインフラまで

更新日：2026年9月26日

フィッシングメールは匿名の手紙のように見えます。それでも、あちこちに手がかりを残しています。封筒の消印、返信先のアドレス、どこかでホスティングされているはずのサイトへのリンク。少し筋道立てて調べれば、こうした手がかりから、詐欺師にマシンを貸している会社までたどり着けます。多くの場合、その会社は事情を知りません。そして、すべてを止められるのはその会社なのです。ここでは調査を一歩ずつ進めます。ヘッダーを読み、手がかりをインフラまでたどり、最後に誰に何を通報するかを決めます。

ヘッダー全体を取り出す：メッセージの「封筒」

メールソフトが表示するもの（差出人、件名、本文）は、手紙の中身にすぎません。その周りには、目に見えない封筒があります。それがヘッダー、つまり配送の途中で追加された何十行もの技術情報です。手がかりはここに隠れています。表示方法は次のとおりです。

Gmail：メッセージの ⋮ メニューから「メッセージのソースを表示」；
Outlook：メッセージの … メニューから、メッセージの詳細またはソースを表示するオプション；
Apple Mail：「表示」メニューから「メッセージ」、そしてすべてのヘッダーを表示する項目；
Thunderbird：ショートカット Ctrl+U（Mac では Cmd+U）で、メッセージのソースが開きます。

ヒント：分析のためにメッセージを「転送」してはいけません。転送すると新しいメールと新しいヘッダーが作られ、元の手がかりが消えてしまいます。ソース全体をコピーするか、メッセージを .eml ファイルとして保存しましょう。

Received 行：郵便局の消印

これらの行の中で最も価値があるのは、Received: で始まる行です。メッセージを受け取ったサーバーは、それぞれ自分の行をいちばん上に書き足します。郵便局が、通過するたびに封筒へ消印を押すようなものです。メールの旅路全体は、ガイドメールは送信者から受信者までどう届くのかで紹介しています。

実際のフィッシングで見かけるような、簡略化したヘッダーの例です。

Received: from mx1.provider.example (mx1.provider.example [192.0.2.10])
        by mailbox.provider.example; Tue, 15 Sep 2026 09:14:05 +0200
Received: from vps-4411.host.example (vps-4411.host.example [203.0.113.45])
        by mx1.provider.example with ESMTPS; Tue, 15 Sep 2026 09:14:03 +0200
Received: from mail.mybank.example (unknown [10.0.0.7])
        by vps-4411.host.example; Tue, 15 Sep 2026 07:13:58 +0000
Authentication-Results: mx1.provider.example;
        spf=pass smtp.mailfrom=parcel-mail.example; dkim=none;
        dmarc=fail header.from=mybank.example
Return-Path: <bounce@parcel-mail.example>
From: "マイ銀行" <security@mybank.example>
Reply-To: mybank.support@freemail.example
Subject: 24時間以内にお客様の口座を停止します

Received 行は、どれも短い文のように読めます。「どこから（from）来たマシンを、どのサーバーが（by）、いつ受け取ったか」。from のすぐ後ろにあるのは、相手のマシンが名乗った名前で、何の確認もされていません。かっこの中にあるのは、受け取ったサーバーが実際に確認したこと、つまり目の前にいたマシンの IP アドレスで、角かっこで囲まれています。

下から上へ読む……でも、信頼は上から下へ

サーバーはそれぞれ、前の行の上に自分の行を追加します。だから経緯は下から上へ読みます。いちばん下の行が出発を、いちばん上の行が受信箱への到着を語っています。例では、メッセージは「mail.mybank.example」を名乗るマシンを出発し、vps-4411.host.example を経由して、私たちのメールサービスに入ってきます。

ただし、すべての行が同じ重みを持つわけではありません。行を書くのは、いつも受け取る側のサーバーです。つまり上のほうの行は、私たち自身のメールサービスが書いたもので、信頼できます。下のほうの行は、メッセージが私たちに届く前に書かれたもので、詐欺師のマシンが書いたかもしれません。そこには何でも書けます。小包と同じです。こちらの郵便局の消印は信頼できますが、発送前に貼られたラベルは何の証明にもなりません。

やり方は簡単です。いちばん上から始めて、私たちのメールサービスが書いた行である限り下へ進みます。止まるのは入口の行、つまり私たちのメールサービスが外部のマシンからメッセージを受け取った行です。この行の角かっこ内の IP、ここでは 203.0.113.45 が、ヘッダー全体で最も確かな手がかりです。実際にメッセージを渡してきたマシンだからです。Baitback が探しているのも、まさにこの IP です。

では、いちばん下の行は？メッセージは「mail.mybank.example」から、10.0.0.7 というアドレスで来たと主張しています。これはインターネット上には存在しないプライベートアドレスです。この行を書いたのは vps-4411 自身で、わざと置かれた偽の手がかりです。

図：ヘッダーに積み重なった3つの Received 行。曲がった矢印が下から上へ向かう：メッセージの経緯は下から上へ読む。もう1本の矢印は上から下りて入口の行で止まる：信頼は上から下へたどる。いちばん上の行は自分のメールサービスが書いたもので信頼できる。入口の行には覚えておく IP、203.0.113.45 がある。いちばん下の行は届く前に書かれたもので、偽の可能性がある。虫眼鏡を持った調査員が、覚えておく IP を指している。 — 図1：経緯は下から上へ、信頼は上から下へ。入口の行で止まります。その IP がいちばん信頼できます。

信頼できるもの、偽造できるもの

ヘッダーの項目	書くのは誰か	信頼度
`From`（表示される名前とアドレス）	差出人	なし
`Reply-To`（返信先アドレス）	差出人	なし……ただし詐欺師が読んでいる本物の受信箱であることが多い
`Subject`、`Date`、`Message-ID`	差出人	低い
`from` の直後で名乗った名前	相手側のマシン	なし
入口の行より下の `Received` 行	それ以前のサーバー（詐欺師かもしれない）	低い
入口の行の角かっこ内の IP	自分のメールサービス	高い
`Authentication-Results`	自分のメールサービス	高い（確認した範囲について）

例の Authentication-Results は、多くを語っています。spf=pass は、このサーバーが確かに送信を許可されていたことを示します……ただしそれは封筒のドメインである parcel-mail.example としてであり、銀行としてではありません。dmarc=fail は、表示されているアドレス mybank.example が何も確認されていないことを示します。つまり「差出人」は偽物です。それでもなぜメッセージは届いたのか。それがガイドチェックが「OK」でも、メールはうそをつくのテーマです。

IP から事業者へ：このアドレスは誰のもの？

IP アドレスは、インターネット上のマシンの住所です。住所と同じように、大きなブロック単位で割り当てられています。それを担当するのは5つの地域インターネットレジストリです。RIPE NCC（ヨーロッパと中東）、ARIN（北米）、APNIC（アジア太平洋）、LACNIC（中南米）、AFRINIC（アフリカ）。これらがブロックを事業者に割り当て、事業者がそれを顧客に貸し出します。

これらのブロックはネットワークごとにまとめられ、それぞれに番号があります。それが ASN で、たとえば AS64500 のように書きます。IP が家の番地なら、ASN は町内のようなもので、そこを管理し通信を流している事業者を示します。

ある IP の背後に誰がいるかを知るには、レジストリの台帳を WHOIS やその新しい版である RDAP で検索します。無料のウェブサイトの多くが、ワンクリックで調べてくれます。コマンドラインでは、たとえば次のようになります（簡略化した抜粋）。

$ whois 203.0.113.45
inetnum:        203.0.113.0 - 203.0.113.255
netname:        HOST-EXAMPLE-VPS
org-name:       Host Example SAS
country:        FR
abuse-mailbox:  abuse@host.example
origin:         AS64500

大事な情報は3つです。誰か（組織名）、どこか（国。どの法律が適用されるかを知るのに役立ちます）、そして何よりabuse アドレス、つまり不正利用の通報を受け付ける公式の窓口です。IP の逆引き名、ここでは vps-4411.host.example も、もう一つ手がかりをくれることがよくあります。「vps」は、借りられた仮想サーバーであることを示しています。

よくある落とし穴があります。ネットワークの事業者が、最終的なホスティング事業者とは限りません。大手の事業者がアドレスのブロックを再販業者に貸し、その再販業者が自分の顧客にサーバーを貸していることがあります。その場合、WHOIS には再販業者名義の小さなブロックが、その業者自身の abuse アドレスとともに表示されます。まず連絡すべきはこの業者です。マシンにいちばん近い存在だからです。

ほかの手がかりをたどる：差出人、リンク、DNS

送信元 IP は、糸の一本にすぎません。フィッシングはほかにも手がかりを残し、それぞれ別の関係者へつながっています。

差出人の手がかり

From、Return-Path、Reply-To に出てくるドメインを見ます。

無料メールサービス（Gmail や Outlook.com など）の場合：関係者はそのサービス事業者で、アカウントを閉鎖できます。特に Reply-To、つまり被害者の返信が届く受信箱について役立ちます；
この目的のために作られたドメインの場合：そのドメインを販売した会社であるレジストラを、ドメインの RDAP や WHOIS で調べます。たとえば lookup.icann.org が使えます。そこでは登録日もわかります。3日前に生まれた「銀行」のドメインは、非常に悪いサインです；
なりすまされたブランドの本物のドメインの場合：ブランド自身に責任はなく、メッセージを送ってもいません。フィッシングの通報窓口があれば、知らせることができます。

リンクの手がかり

メッセージ内のリンクは罠のページへつながっており、そのページはどこかでホスティングされているはずです。クリックはせず、アドレスをコピーします（右クリックして「リンクをコピー」）。大事なのはドメインで、https:// に続く最初の「/」の直前にあります。それより左側は、詐欺師が自由に決められます。リンクは何度もリダイレクトされることがよくあります。Baitback が代わりにたどって、チェーン全体を表示します。画像の中に隠れたリンクについては、ガイドクイッシング：QRコードの裏に隠れたフィッシングをご覧ください。

DNS の手がかり

インターネットの電話帳である DNS は、ドメインの各部分がどこにあるかを教えてくれます。質問は3つで足ります。

$ dig +short A  secure-login.example    # サイトの IP（CDN の場合もある）
$ dig +short MX secure-login.example    # そのドメインのメールを受け取るサーバー
$ dig +short NS secure-login.example    # DNS を管理しているのは誰か

サイトの IP は、送信元 IP と同じ手順で調べます。WHOIS、ASN、事業者、abuse アドレス。そして、メールサーバーを一つも持たないのに私たちへメールを送ってきたと称するドメインは、よく見てみる価値があります。DNSのMXレコード：信頼のしるし？を参照してください。

調査マップ：怪しいメールから、曲線でつながった3本の手がかりが延びている。ヘッダーは送信元 IP へ、次に IP の WHOIS（ASN、事業者）へ、最後にサーバーを停止できるホスティング事業者へ。差出人はドメインまたは無料メールへ、次にドメインの WHOIS へ、最後にドメインを停止できるレジストラへ。リンクはサイトのドメインへ、次に DNS へ、最後にページを削除できる CDN またはホスティング事業者へ。Baitback は貼り付けたメールからこの道のりをたどる。 — 図2：3本の手がかり、3種類の関係者。どの道も、行動できる誰かにたどり着きます。

なぜいつも複数の事業者が出てくるのか

調査の最後に、名前が一つだけ残ることはめったにありません。それが普通です。フィッシングの作戦は、すべてをレンタルでまかなう引っ越しのようなものです。ドメイン名はあるレジストラで買い、その DNS は別の会社が管理し、ページは別の場所で借りたサーバーに置かれて CDN の陰に隠れ、メールは3台目のサーバーから送られ（フィッシング：詐欺師はどうやってメールを届けているのかを参照）、返信は無料の受信箱に届きます。

詐欺師がすべてを分散させるのには理由があります。どのサービスも安く、盗んだ支払い手段で払われることも多いこと。ある事業者が止めても、ほかは動き続けること。そしてサイトの前に置いた CDN が、本物のサーバーのアドレスを隠してくれること。よい知らせもあります。どの事業者も、同時に「てこ」でもあるのです。知らせる相手が多いほど、作戦は早く崩れます。

IP は犯人ではない

よくある誘惑があります。IP を見つけ、会社名や国名を読んで、「犯人はこいつだ」と結論づけてしまうことです。これはほとんどの場合まちがいです。IP が示すのは、メッセージを最後に渡したマシンであって、キーボードの前にいる人物ではありません。そのマシンは、たとえば次のようなものです。

詐欺師が数日だけ借りたサーバー。いちばん単純なケースです；
大手メールサービスのサーバー。詐欺師がそこでアカウントを作ったか盗んだ場合です。このとき IP はサービス事業者のもので、事業者に責任はありませんが、アカウントを閉鎖できます；
乗っ取られたサイトやパソコン。その持ち主も被害者です；
本当の接続元を隠す VPN や中継サーバー。

ですから、正しい問いは「誰が悪いのか？」ではなく、「このマシンに手を打てるのは誰か？」です。連絡すべきはその相手です。詐欺師に連絡することは決してせず、「反撃」もせず、サーバーを乗っ取られただけかもしれない会社を公の場で非難することもしません。

ドメインかサーバーか：看板とビル

誰が何をするのかを理解するには、たとえ話が役立ちます。通りに偽の銀行支店があると想像してみましょう。

ドメイン名は入口の上の看板で、レジストラはその名前を貸し出した機関です。看板を外すことができます；
サーバーは偽の支店が入っているビルで、ホスティング事業者はそのビルの大家です。入居者を追い出すことができます；
IP アドレスは、プレートに書かれた番地です；
CDN は入口の前に置かれた受付です。訪問者は受付と話し、受付が要望をビルへ取り次ぎます。通りから見えるのは受付だけです。

通りのイラスト：訪問者が点線の道をたどって、ビルの前に座っている受付の人物のところへ向かう。ビルの上の看板にはドメイン名 secure-login.example が、外壁のプレートには IP アドレスが書かれている。凡例：看板はドメイン名で、レジストラが停止できる。ビルはサーバーで、ホスティング事業者がページを削除できる。プレートは IP アドレスで、ビルを指すこともあれば受付だけを指すこともある。受付は CDN で、通報を転送し、訪問者に警告を出せる。 — 図3：看板（ドメイン）、ビル（サーバー）、プレート（IP）、受付（CDN）。それぞれ責任者が違います。

サーバーを止めればページは消えますが、詐欺師は数分でドメインを別のサーバーに向け直せます。逆にドメインを停止すれば、サーバーがまだ動いていても、すでに送られたすべてのリンクが役に立たなくなります。両方が補い合うのです。

CDN の場合

サイトの IP の WHOIS で Cloudflare、Akamai、Fastly といった名前が出てきたら、それはほぼ確実にホスティング事業者ではなく、受付です。CDN は通報を受け付け、訪問者に警告ページを表示でき、住所を知っている本当のホスティング事業者へ苦情を転送します。たとえば Cloudflare には、abuse.cloudflare.com に専用のフォームがあります。あわせてドメインのレジストラにも通報します。レジストラは CDN の陰に隠れていません。

サーバーが乗っ取られている場合

https://yamada-bakery.example/wp-content/uploads/x/login.php のようなアドレスは、乗っ取られたサイトであることを示していることがよくあります。ドメインは何年も前からあり、実在するお店のものです。罠のページが片隅にこっそり置かれただけです。この場合、ドメインの停止を求めるのは不公平で、効果もありません。ホスティング事業者に、そしてサイトの持ち主の連絡先が見つかれば持ち主にも、ページの正確なアドレスを添えて知らせます。本物の受信箱が乗っ取られてメールが送られた場合も同じ考え方です。メールサービス事業者に知らせれば、アカウントを止めて本来の持ち主に返すことができます。

状況別の連絡先

見つけたもの	通報先	相手ができること
送信元 IP がホスティング事業者のもの（借りたサーバー）	ホスティング事業者の abuse アドレス（IP の WHOIS）	送信サーバーを停止する
有名なメールサービスから送られている	そのメールサービス事業者	アカウントを閉鎖・凍結する
`Reply-To` が無料メール	その受信箱のサービス事業者	返信を受け取る受信箱を閉鎖する
詐欺のために作られたドメイン	レジストラ（ドメインの RDAP または WHOIS）	ドメインを停止する
CDN の背後にあるサイト	CDN、次にレジストラ	訪問者に警告し、ホスティング事業者へ転送する
乗っ取られた正規のサイト	サイトのホスティング事業者と持ち主	ページを削除し、サイトを修復する
短縮リンク	短縮 URL サービス	リンクを無効にする
あらゆるフィッシングページ	Google Safe Browsing、Microsoft、Netcraft など	ブラウザーでページをブロックする

公的な窓口もあります。たとえばフランスでは、メールを Signal Spam に転送し、詐欺を PHAROS に通報できます。どの国にも同様の窓口があります。こうした窓口は主に統計と捜査のためのもので、1時間以内にサーバーを止めることはありませんが、公式な記録を残してくれます。

通報の流れを組み立てる

すべてを一度に、誰にでも通報するのは、あまりうまくいきません。緊急度の高いものから長期的なものへ、順番に進めましょう。

被害を止める：罠のページ（ホスティング事業者または CDN）と、ブラウザーのブロックリスト。1時間ごとが勝負です。作戦の被害者の多くは、最初の数時間に出ます。
名前を断つ：ドメインのレジストラ。すでに送られたリンクを無効にします。
送信を断つ：送信元 IP のホスティング事業者と、Reply-To の受信箱のサービス事業者。
記録を残す：捜査のための公的な窓口。

よい通報は、短くて検証できるものです。次のものを含めます。

メッセージのヘッダー全体。スクリーンショットだけでは足りません；
その相手に関係する具体的な項目。ホスティング事業者には IP、レジストラにはドメイン、サイトのホスティング事業者にはページの正確なアドレス；
タイムゾーン付きの日付と時刻；
誰もうっかりクリックしないよう無害化したリンク。たとえば hxxps://secure-login[.]example のように書きます。

これこそが Baitback の仕事です。メールのソースを貼り付けると、ツールが Received 行を読み、送信サーバーとそのホスティング事業者、通報先アドレスを見つけ、SPF、DKIM、DMARC を確認し、リンクとそのリダイレクトをたどり、すぐに送れる通報メッセージを用意します。このガイドの調査が、数秒で終わります。

まとめ

ヘッダー全体は「原文の表示」やメッセージのソースで取り出せます。メッセージは転送しません。
Received 行は下から上へ経緯を語りますが、信頼できるのは自分のメールサービスが書いた行だけです。
いちばん信頼できる IP は入口の行、つまり自分のメールサービスが外部からメッセージを受け取った行にあります。
IP → WHOIS → 事業者と abuse アドレス。ドメイン → レジストラ。DNS → サイトのサーバー。
IP が示すのはマシンであって犯人ではありません。行動できる相手に連絡します。
レジストラは名前を、ホスティング事業者はマシンを断ち、CDN は取り次ぎます。それぞれに関係する内容を知らせましょう。