メールヘッダーを読んでフィッシングメールを見抜く方法

どのメールにも、読んでいる本文の上にヘッダーと呼ばれる部分があります。メールアプリは普段これを隠していますが、そこにはメッセージがどのサーバーから来たか、どのドメインが身元を保証したか、返信が実際にどこへ届くかが記録されています。本文が完璧に見えるフィッシングでも、たいていはここで正体が現れます。

私たちは受信メールサーバーを運用しているので、メッセージの挙動がおかしいときに読むのはいつも生のヘッダーです。このガイドでは、現実的なフィッシングのヘッダーを1行ずつ読み、その後ですべてのチェックに合格してしまう、より難しいケースを紹介します。読みながら、手元のメッセージのヘッダーを私たちのメールヘッダー解析ツールに貼り付けてみてください。解析はブラウザ内で行われ、ヘッダーが私たちのサーバーに送られることはありません。

ステップ1：メールアプリからヘッダーを取り出す

どのメールソフトも、標準ではヘッダーを表示しません。Gmailでは、メッセージを開き、「返信」の横にある三点メニューをクリックしてメッセージのソースを表示を選びます。Outlook on the webでは、三点メニューを開いて表示、メッセージのソースを表示の順に選びます。MacのApple Mailでは、表示、メッセージ、すべてのヘッダの順に選びます。Outlook for Windows、Yahooなどのメニューの場所はヘッダー解析ツールのページにまとめています。

最初の空行より上をすべてコピーしてください。そこがヘッダー部分です。その後に続く本文は必要ありません。iPhoneやiPadの標準メールアプリではヘッダーをまったく表示できないので、メッセージをパソコンに転送するか、Webメールで確認してください。

フィッシングメールのヘッダーを1行ずつ読む

以下は、アカウント警告を装った典型的なフィッシングのヘッダーを、重要な行だけに絞ったものです。ドメインやアドレスは架空のものですが、パターンは私たちが何度も目にしているものと同じです。ヘッダーは新しいものが上に積み重なるので、あなたにメッセージを届けたサーバーは上の方に、メッセージが出発した場所は下の方にあります。

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

各行からわかること

Return-Path

バウンスの送り先となるアドレスで、エンベロープ送信者とも呼ばれます。ここでは銀行のドメインではなくmail.example.netになっています。これだけではあまり証拠になりません。メール配信サービス経由のニュースレターも同じように見えるからです。次の行を読むときのために覚えておいてください。

Authentication-Results

メッセージが届いたときに、あなたのメールプロバイダーが記録した判定結果です。SPFは合格していますが、それは攻撃者のサーバーであるmail.example.netについての合格です。DKIM署名はありません。そして、あなたが実際に目にするFromドメインを確認する唯一のチェックであるDMARCは、examplebank.comについて不合格です。ヘッダーの中でいちばん役に立つ行がこれです。

Received（いちばん上）

あなたのプロバイダーのサーバーmx.example.comが、203.0.113.45からメッセージを受け取ったときに追加した行です。自分のプロバイダーが書いた行は信頼できます。これより下はすべて、あなたが何も知らないマシンが書いたものです。

Received（いちばん下）

いちばん古いステップです。Receivedの連なりは下から上へ読みます。メッセージはdesktop-4kq2と名乗るマシンから始まり、ログイン済みの送信（ESMTPA）でmail.example.netに渡されています。銀行の通知システムが誰かのデスクトップPCで動いていることはありません。盗まれたメールボックスや借りたメールボックスなら、そうなります。

From

表示名はExample Bank Securityで、アドレスはexamplebank.comを名乗っています。この欄には誰でも何でも入力できます。上のDMARC不合格こそが、このFrom行が偽造されている証拠です。

Reply-To

「返信」を押すと、あなたの返事は3つ目のドメインであるexample.orgに届きます。電話やログインを求める銀行が、他人のドメインで返信を集める理由はありません。返信で個人情報を送らせようとするフィッシングは、ほぼ必ずこれを設定しています。

SubjectとDate

緊急性と期限の組み合わせです。Dateは送信側のマシンが主張しているだけの日時ですが、Receivedのタイムスタンプと比べてみてください。Dateと最初のステップの間に数時間や数日の差があれば、メッセージが届くまで迷惑メールのキューに滞留していた可能性があります。

Message-ID

送信ソフトが作る一意のIDです。大企業のシステムは自社のドメインを付けます。このIDはdesktop-4kq2で終わっていて、いちばん下のReceived行にあった自宅のマシンと同じです。ここでの食い違いはヒントであって証拠ではありません。正規のソフトでも汎用的なIDを使うものは多いからです。

まとめると、事情ははっきりしています。銀行を名乗るメッセージが、デスクトップPCから見知らぬ人のメールサーバーを経由して送られ、銀行自身の認証に不合格となり、3つ目のドメインへの返信を求めています。どこを見ればよいかがわかれば、1分もかからずにこの結論にたどり着けます。ヘッダー解析ツールを使えば、DMARC不合格とReply-Toの食い違いを自動で指摘してくれます。

SPF、DKIM、DMARCをわかりやすく解説

この3つのチェックは、送信者が入力したテキストではなく、受信サーバーがメッセージを検査した後に書き込むヘッダーの部分です。それぞれ別の問いに答えています。

SPF

このサーバーは、エンベロープ送信者のドメインのメールを送ることを許可されているか？ドメインの所有者は許可するサーバーの一覧をDNSで公開し、受信側は接続してきたIPアドレスをその一覧と照合します。SPFが確認するのはReturn-Pathのドメインで、あなたが目にするFromアドレスではありません。フィッシングが自分のドメインでSPFに合格できるのはそのためです。用語集のSPFも参照してください。

DKIM

メッセージはあるドメインによって署名され、その後変更されていないか？送信サーバーが暗号署名を付け、受信側は署名者のDNSにある公開鍵でそれを検証します。header.d=の値が、署名したドメインを示します。無関係なドメインによる有効な署名は、From行のブランドについて何も保証しません。

DMARC

From行のドメインは、SPFまたはDKIMに合格したドメインと一致しているか？この「アラインメント」の確認こそが、チェックをあなたが実際に読む名前に結び付けます。DMARCではさらに、不合格のメールをどう扱うかをドメイン所有者が受信側に指示できます。何もしない（p=none）、隔離する、拒否する、のいずれかです。本物の会社が強制を有効にしていなければ、偽造メッセージでも受信トレイに届いてしまうのはこのためです。

各結果の意味

より難しいケース：すべてのチェックに合格する

慎重な攻撃者は、銀行のドメインをそもそも偽造しません。似たドメインを登録し、SPF、DKIM、DMARCをきちんと設定して、そこから送ってきます。するとヘッダーは一見完璧になります。

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

認証によって証明されるのは、examplebank-secure.comがこのメールを送ったということです。そのドメインがあなたの銀行のものかどうかはわかりません。そこを確かめるのはあなたの役目で、結局はドメインそのものをじっくり読むことに尽きます。私たちがよく目にする手口は次のとおりです。

• 余計な単語。本物の名前に-secure、-login、-support、-verifyなどを付け足したもの。
• 文字の入れ替え。mの代わりにrn、英字のoの代わりに数字の0、文字の重複や欠落など。
• 違う末尾。正しい名前でも、会社が使っているものではなく.co、.net、新しいトップレベルドメインになっているもの。
• 本物の名前をサブドメインに使う。examplebank.com.account-check.netの場合、ドメインはaccount-check.netです。ドメインは右から読んでください。
• そっくりな文字。キリル文字のаはラテン文字のaとまったく同じに見えます。生のヘッダーでは、こうしたドメインはxn--で始まる形で表示されることがよくあります。これはラテン文字以外のドメイン名をエンコードした形式です。
• 表示名で信用させる。フリーメールのドメインのアドレスの前に「Example Bank」と付けたもの。多くのスマートフォンは名前しか表示しないので、タップしてアドレスを確認してください。

そのドメインが会社のものかどうか自信がないときは、メール内のものを使って調べないでください。会社のアドレスを自分でブラウザに入力して比べましょう。

メールヘッダーの危険信号（重要度順）

ほぼ証拠と言える信号もあれば、いくつも重なって初めて意味を持つ信号もあります。私たちはおおよそ次のように重み付けしています。

怪しいメールを5分で確認する手順

1. 1

   ヘッダー全体をコピーする

   上で説明したとおり「メッセージのソースを表示」などを使い、すべてのReceived行を含むヘッダー全体をコピーします。

2. 2

   ヘッダー解析ツールに貼り付ける

   私たちのメールヘッダー解析ツールは、From、Reply-To、Return-Pathを並べて表示し、SPF、DKIM、DMARCの結果を示し、配信経路を古い順に一覧にします。解析はブラウザ内で行われます。

3. 3

   FromのドメインとDMARCを照らし合わせる

   dmarc=とその隣のドメインを探します。知っているブランドで不合格なら、そこで確認をやめてメッセージを削除して構いません。

4. 4

   すべてのドメインを右からゆっくり読む

   From、Reply-To、DKIMに合格したドメインは、すべてその会社のものであるはずです。上で紹介したそっくりドメインの手口に注意してください。

5. 5

   Receivedの連なりを下から読む

   いちばん下の行が、メッセージの出発点です。信頼してよいのは、上の方にある自分のプロバイダーが追加した行だけです。送信者は偽のReceived行や、その下に偽のAuthentication-Results行まで挿入できます。

6. 6

   クリックせずにリンクを確認する

   ヘッダーには本文のリンクは表示されません。パソコンなら、各ボタンにマウスを重ねて、ウィンドウの隅に表示されるアドレスを読んでください。会社の本物のドメインに向かわないものがあれば、それだけで立ち去る理由になります。

フィッシングだと思ったら

• クリック、返信、添付ファイルを開くことはしないでください。返信すると、そのアドレスが読まれていることを相手に知らせてしまいます。添付ファイルはマルウェアが侵入するよくある経路です。
• 別の方法で会社に連絡する。会社のアドレスを自分でブラウザに入力するか、カードや契約書に記載された番号を使ってください。メールに書かれた番号は使わないでください。
• メールアプリで報告する。Gmailでは三点メニューからフィッシングを報告を選びます。Outlookでは報告、フィッシングの報告の順に選びます。これにより、そのサービスを使う全員のためにフィルターが学習します。
• Anti-Phishing Working Groupに転送する。宛先は[email protected]です。報告はセキュリティ企業やブラウザと共有されます。
• 米国ではFTCに報告する。報告先はReportFraud.ftc.govです。特にお金や個人情報が関わっている場合は報告してください。
• すでにパスワードを入力してしまった場合は、今すぐ本物のサイトでパスワードを変更し、2段階認証を有効にして、同じパスワードを使い回している場所でもすべて変更してください。漏えい直後の1時間にすべきことは、メールアドレスがデータ漏えいに含まれていないか確認する方法のガイドで解説しています。

出典

• IETF、RFC 7208: Sender Policy Framework (SPF)。pass、fail、softfail、neutralの意味を含みます。
• IETF、RFC 6376: DomainKeys Identified Mail (DKIM) Signatures。
• IETF、RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)。2026年に公開され、RFC 7489を置き換えました。
• IETF、RFC 8601: Message Header Field for Indicating Message Authentication Status。Authentication-Resultsヘッダーを定義しています。
• 米国連邦取引委員会（FTC）、How to Recognize and Avoid Phishing Scams。FTCとAPWGの報告先について。
• Anti-Phishing Working Group、Report Phishing。