メールヘッダー分析入門 — SPF・DKIM・DMARC の失敗を読み解く

本文より「痕跡」を見ると、不審メールの解像度が上がる

不審なメールを調べるとき、多くの人は本文や件名から見始めます。もちろんそれも大事ですが、攻撃者は本文をいくらでも整えられます。生成AIの普及で日本語の違和感も減り、見た目だけでの判別はますます難しくなりました。

一方で、メールヘッダー には送信経路や認証結果といった「配送の痕跡」が残ります。ここを見ると、表示名だけでは分からないなりすましや、不自然な配送経路、認証失敗の有無が見えてきます。

このレッスンは、前回の メール認証（SPF・DKIM・DMARC） を受けて、「実際に受け取ったメールをどう読むか」を手を動かしながら理解するための実践編です。

まず覚えたい前提は「信じやすいヘッダー」と「信用しにくいヘッダー」の違い

ヘッダーはすべて同じ重みではありません。送信者が比較的自由に書けるものもあれば、受信側や中継サーバーが後から付けるため、より信頼しやすいものもあります。

• Subject や From の表示名は、攻撃者が見せ方を調整しやすい
• Reply-To も誘導先として悪用されやすい
• Authentication-Results は受信側のゲートウェイやメールサービスが付けるため、比較的信頼しやすい
• Received は配送ごとに追記されるので、自組織に近い側の行ほど信頼しやすい

ここで重要なのは、「外部から持ち込まれた生ヘッダーを全部そのまま信用しない」ことです。特に Received は、送信側が下流の一部を細工できる場合があります。調査では、自分たちのメール基盤が付けた情報を基点に読むのが安全です。

最初に見るべき 4 つの項目

1. From: 受信者が見ている差出人

From は、受信者が通常のUIで目にする差出人です。ここが vendor-example.com なのか vend0r-example.com なのか、まずはドメインを確認します。表示名だけではなく、実際のアドレス全体を見るのが基本です。

ただし、From だけでは十分ではありません。攻撃メールでは、見た目上の From を本物らしく見せつつ、裏側の送信経路を別ドメインにしていることがよくあります。

2. Return-Path: バウンス先として使われる送信元

Return-Path は配送失敗通知の返送先であり、SPF 判定で参照されることが多い項目です。From と Return-Path のドメインが大きく違う場合、それだけで即不正とは限りませんが、SaaS配信や転送以外で不自然にズレているなら要注意です。

たとえば From: billing@example.co.jp なのに、Return-Path: bounce@mailer-somewhere.net となっている場合は、なぜそのサービスが送っているのか説明できるかを考えます。

3. Received: どこを経由して届いたか

Received は配送経路の記録です。メールはサーバーを通過するたびに Received 行が追加されるため、下から上に読むと、どこからどこへ渡ってきたかを追いやすくなります。

見るポイントは次の3つです。

• 最初の送信元と思われるホスト名や IP はどこか
• その経路は From や Return-Path と整合しているか
• 明らかに関係のない国・ホスティング事業者・雑なホスト名が混ざっていないか

4. Authentication-Results: 認証に失敗していないか

実務で最も早く価値が出るのがこのヘッダーです。ここには受信側が評価した SPF、DKIM、DMARC の結果が出ます。

pass ならそれだけで安全という意味ではありませんが、fail、softfail、none、temperror が出ているときは、少なくとも追加確認が必要です。特に dmarc=fail と header.from の不整合は、なりすまし判定の強い手がかりになります。

実際のヘッダーはこう読む

下は、練習用に簡略化したメールヘッダーの例です。

From: “経理部” <finance@example.co.jp>
Reply-To: support@secure-payments-help.net
Return-Path: <bounce@mailer.secure-payments-help.net>
Received: from inbound.example.jp (inbound.example.jp [192.0.2.10])
by mx.company.jp with ESMTPS id abc123
for <user@company.jp>; Wed, 23 Apr 2026 09:14:22 +0900
Received: from smtp.secure-payments-help.net (smtp.secure-payments-help.net [203.0.113.55])
by inbound.example.jp with ESMTPS id def456;
Wed, 23 Apr 2026 09:14:18 +0900
Authentication-Results: mx.company.jp;
spf=fail smtp.mailfrom=mailer.secure-payments-help.net;
dkim=none;
dmarc=fail header.from=example.co.jp
Message-ID: <20260423091418.123456@secure-payments-help.net>
Subject: 【至急】本日の送金先変更について

この例で注目したいのは次の点です。

• From は example.co.jp を名乗っている
• Reply-To と Return-Path はまったく別のドメインを向いている
• Authentication-Results で spf=fail、dkim=none、dmarc=fail
• Message-ID も送信元を名乗るドメインと一致していない

この時点で、「少なくとも通常の正規メールではない可能性が高い」と判断できます。本文の日本語が自然でも、配送の痕跡はかなり不自然です。

Gmail / Outlook でどこを見ればよいか

Gmail の場合

1. 対象メールを開く
2. 右上のメニューから「メッセージのソースを表示」
3. Authentication-Results、Received、Return-Path を確認する
4. 必要なら元データを .eml として保存する

Outlook の場合

1. デスクトップ版なら「ファイル」や「プロパティ」からインターネット ヘッダーを確認する
2. Web版ならメッセージの詳細表示やソース表示を開く
3. From と Reply-To のズレ、Authentication-Results の判定を見る

UIは環境で少し違いますが、見るポイントは同じです。本文ではなく、配送情報と認証結果を先に見る と覚えておくと迷いにくくなります。

フィッシング初動では「読む」だけでなく「残す」ことも重要

フィッシングやビジネスメール詐欺の調査では、証拠の保存が非常に大切です。受信直後に削除したり、本文だけをチャットへ貼り付けたりすると、後から重要なヘッダーが失われます。

おすすめの初動は次の通りです。

• 元メールを .eml 形式で保存する
• 可能なら受信したままの状態で SOC や情シスへ転送する
• 画面キャプチャだけでなく、ヘッダー全文も残す
• クリックや返信をする前に From、Reply-To、Authentication-Results を確認する

特に Reply-To の誘導先が別ドメインになっているメールは、支払い詐欺やサポート詐欺でよく見られます。ヘッダー分析は、攻撃の真偽だけでなく、どの方向に誘導したいメールなのか を理解する助けにもなります。

よくある誤解と限界

認証が pass でも安全とは限らない

本物のアカウントが侵害されて送られたメールは、認証上は pass になることがあります。メールヘッダー分析は強力ですが、万能ではありません。

表示名が本物らしいだけで安心してはいけない

「経理部」「社長」「取引先担当者」といった表示名は簡単に偽装できます。あくまでドメイン、配送経路、認証結果を見て判断します。

Received はすべて同じ信頼度ではない

外部から持ち込まれた古い Received 行よりも、自組織のゲートウェイや受信基盤が付けた記録の方が信頼しやすいです。調査では「どこから先が自分たちの観測か」を意識する必要があります。

ヘッダーだけで結論を出さない

ヘッダー分析は、URL の確認、添付ファイルの解析、利用者への聞き取り、インシデント対応の流れと組み合わせて初めて意味を持ちます。単発の fail やドメイン不一致だけで断定せず、全体の文脈で見ることが大切です。

まずは「3分で見る手順」を体に入れる

メールヘッダー分析は、SOC の専門家だけの技術ではありません。最低限の見方を知っているだけで、「本文はもっともらしいが、配送の痕跡は怪しい」という違和感を持てるようになります。

次に読むなら、認証の仕組みそのものを整理した メール認証（SPF・DKIM・DMARC） と、攻撃者のだまし方を学ぶ フィッシングとソーシャルエンジニアリング をあわせて読むと理解がつながります。