メールヘッダーの読み方（偽装された差出人を見抜く）

誰かがメールを転送してきて、短くは答えられない質問をします。「これ、本物ですか？」

本文は当てになりません。ロゴは数秒でコピーでき、口調は真似られ、リンクの表示文字列は昔から実際の行き先と一致している必要がありません。しかしメールにはもう一つ、送信者が完全には操作できない文書が付いています。ヘッダーです。どのサーバーがいつこのメールを扱ったのか、そして受信側が「誰が送ったのか」について何を結論づけたのかが、そこに記録されています。メールにおける証拠保全の連鎖に最も近いものです。

この記事はその読み方です。略語の背後にあるモデルを先に押さえたいなら——SPF・DKIM・DMARC が何を検証し、なぜアライメントが要になるのか——SPF・DKIM・DMARC はそれぞれ何をしているのかがそれを扱っています。ここではそれを前提に、実際の一通を読んでいきます。

生のヘッダーを取り出す

必要なのはクライアントの表示ではなくソースです。

• Gmail — メールを開き、三点メニューから メッセージのソースを表示。
• Outlook（デスクトップ）— ファイル → プロパティ、「インターネット ヘッダー」の欄。
• Apple Mail — 表示 → メッセージ → すべてのヘッダ、または ⌥⌘U で生ソース。
• Thunderbird — Ctrl+U。

先頭から最初の空行までをコピーします。その空行がヘッダーの終わりで、本文の始まりです。

どこかに貼り付ける前に身につけておきたい習慣が一つ。ヘッダーには受信者のアドレス、内部ホスト名、多くの場合プライベート IP レンジが含まれます。どのツールに渡すかを選ぶべき理由がここにあります。メールヘッダー解析ツールはすべてブラウザー内で解析し、何もアップロードしません。コピーして持ち出す内容ではメールボックス名を伏せられるので、ヘッダーを同僚と共有できる形になります。

結論から読む：Authentication-Results

ファイルの先頭から読み始めないでください。まず、サーバーが自分の結論を書き残した一行から見ます。

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.provider.com;
  dkim=pass header.d=yourcompany.com;
  dmarc=pass header.from=yourcompany.com

三つの独立した判定と、それぞれが適用される識別子として読みます。

• spf=pass smtp.mailfrom=... — 接続元 IP はそのドメインの代理で送信する権限がありました。そのドメインに注目してください。From 行のものではなく、事業者のバウンス用ドメインであることが頻繁にあります。
• dkim=pass header.d=... — 署名が検証を通り、それはそのドメインの鍵によるものでした。
• dmarc=pass header.from=... — SPF か DKIM の成功が、可視の From とアラインしたドメインに属していました。読み手が見る差出人について語っているのは、これだけです。

このヘッダーには注意点が二つあり、どちらも重要です。

最上部の通常の記録から見始めますが、上にあるというだけで信用してはいけません。 それは最新の結果であることが多い一方、上流の誰でも dmarc=pass と書いたヘッダーを挿入できます。先頭の authserv-id（上の例では mx.example.net）はその主張をしている主体を示します。意味を持つのは、それが実際に信頼できるメールシステム——通常は自分の事業者——に属するときだけです。知らない authserv-id からの dmarc=pass は、やはり見知らぬ相手の主張にすぎません。

これは記録であって再検査ではありません。 受信側は配送時にこれらを評価し、結果を書き留めました。いま何をしても再実行はされませんし、DNS はその後変わっているかもしれません。

このヘッダーがまったくない場合も、それ自体は何の証明にもなりません。付けないシステムはいくらでもあります。この近道が使えないので、残りをより丁寧に読むというだけのことです。

spf=pass と dmarc=fail が並ぶとき

この組み合わせは不具合を疑わせますが、一目で見分けられるようになる価値が最も高いものです。

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailer.example;
  dkim=none;
  dmarc=fail header.from=yourcompany.com

何も壊れていません。SPF は確かに成功しました——bounces.mailer.example について、です。このドメインは yourcompany.com と何の関係もありません。そしてもう半分を担う DKIM 署名もありませんでした。結果として、認証された識別子で From ヘッダーとアラインするものが一つもなく、DMARC は失敗しました。

この形には正反対の説明が二つあり、両者を切り分けることが実際の作業です。

• アライメントを一度も設定していない正規の送信元 — マーケティング基盤や問い合わせ管理システムがあなたの名前で送りながら、あなたのドメインで DKIM 署名していないケース。きわめて一般的で、事業者側で直せます。
• 完全な偽装 — 他人のドメインが SPF を通り、From 行にはあなたの名前が入っているケース。

残りのヘッダーが、この二つを切り分ける材料です。

Received を下から追う

Received: は経路の履歴です。決定的な仕組みは、各サーバーが自分の行を先頭に追加すること。したがってこの連鎖は新しいものが上で、最上段が最後のホップ、最下段が起点を自称しています。

Received: from mx.example.net by inbox.example.net; Tue, 4 Aug 2026 10:00:12 +0000
Received: from mail.sender.example (mail.sender.example [198.51.100.7])
        by mx.example.net; Tue, 4 Aug 2026 10:00:09 +0000

下から上へ読めば、時間の流れに沿ってメールを追えます。取り出す価値があるのは三つです。

どこで自社インフラに入ったか。 信頼できるサーバーが書いた最も下の行を見つけます。それが境界です。これが重要なのは、その下はすべて他人が書いたものだからです。偽装されたメールは、その線より下にもっともらしいホスト名と時刻を備えた履歴を丸ごと捏造できます。境界より下は、どのホップも事実ではなく主張として扱ってください。

角括弧の中の IP。 直前のホスト名ではなく、角括弧のリテラル（[198.51.100.7]）を採ります。ホスト名は接続してきたサーバーの自称であり、角括弧のアドレスは自分のサーバーが実際に観測したものだからです。送信元 IP が差出人の説明と噛み合わないなら——銀行のメールが無関係な国の住宅回線から届いているなど——追う価値のある兆候です。IP アドレス検索で実際の保有者を確認できます。

ホップ間の時間。 各ホップには時刻が付きます。数分の遅れはたいてい単なるキューイングです。それより興味深いのは辻褄の合わない間隔です。どこかで数時間滞留していた、あるいはホップの時刻が逆行している場合など。後者はたいてい時計のずれですが、まれに連鎖が手作業で組み立てられたことを意味します。

識別子のフィールドと、その食い違い

メールは差出人を複数の場所で名乗っており、偽装はたいていその食い違いとして現れます。

From: — 読み手が見るもの。 表示名は自由なテキストで、アドレスとは何の関係もない点に注意してください。

From: "Support <support@yourbank.example>" <ceo@random-domain.example>

多くのクライアントは Support <support@yourbank.example> しか表示しません。実際のアドレスは後ろのほうです。表示名の中にアドレスが埋め込まれているのは、意図的な誘導である可能性があります。 操作する前に実際の From を確認してください。文脈の中では強い警告ですが、それだけで証拠になるわけではありません。

Return-Path: — バウンスの戻り先。 配送時に記録されたエンベロープ送信者です。From ドメインと一致しないことは日常的で、かつ正当です。多くは事業者がバウンスを処理しているだけです。参考にはなりますが、SPF が実際に評価した ID の証明ではありません。SPF は SMTP の MAIL FROM を使い、リバースパスが空なら HELO を使うことがあります。存在する場合は Authentication-Results の smtp.mailfrom または smtp.helo を確認してください。そこに受信側が記録した ID があります。

Reply-To: — 返信の宛先。 共有メールボックスやヘルプデスクなど、正当な用途も多々あります。ただしすでに DMARC に失敗しているメールで無関係なドメインを指す Reply-To は、会話を攻撃者へ差し向ける仕掛けそのものです。

Message-ID: — 割り当てられた識別子。 ドメイン部分は通常それを生成したシステムです。事業者が代理送信していれば From ドメインと異なるのは正常です。形式が壊れている、あるいは存在しない場合は書き留めておく価値があります。

どれ一つとして単独では決め手になりません。それが要点です。兆候はパターンにあり、個々のフィールドにはありません。 DMARC に失敗した From ドメイン、別のアドレスを含む表示名、無関係な先を指す Reply-To——この三つが揃うと一貫した筋書きになり、単なる設定ミスはその筋書きを語りません。

DKIM 署名を読む

DKIM-Signature: ヘッダーがある場合、いくつかのタグがその価値を決めます。

DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=selector1;
  h=from:to:subject:date; bh=...; b=...

• d= — 署名ドメイン。From ドメインと比べます。無関係なドメインによる完璧に有効な署名は、DMARC には何も寄与しません。
• s= — セレクター。d= と合わせて selector1._domainkey.yourcompany.com の公開鍵を指します。DNS 検索ツールでその TXT レコードを自分で引き、鍵が公開されているか確認できます。
• h= — 署名が覆うヘッダーの一覧。from を含まない署名はほぼ無価値です。 可視の差出人を、署名に触れずに差し替えられてしまいます。これは明示的に確認する価値があります。問題があっても dkim=pass と報告される、見えにくい失敗だからです。
• l= — 本文の長さ上限で、先頭 N バイトだけに署名します。それ以降に追記された内容は署名されません。まれですが、あれば疑う理由になります。

正直に書いておくべき限界が一つ。署名を読むことは検証ではありません。 検証には改変されていない本文と DNS 上の公開鍵が必要で、転送中の変更は書かれた時点では正しかった署名も無効にします。解析ツールが行うのはフィールドを読み、上に挙げた構造的な性質を確認することです。Authentication-Results の dkim=pass こそが、受信側が配送時に行った検証です。

ARC ヘッダーと、その価値

転送とメーリングリストは、仕組み上どうしても認証を壊します。中継サーバーの IP は自社のものではないので SPF は失敗し、リストがメールに手を加えれば DKIM も失敗します。ARC（Authenticated Received Chain、RFC 8617）は、その断絶をまたいで壊れる前の判定を運ぶために存在します。Google や Microsoft を経由した実際のメールを読めば、絶えず目にするはずです。

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc;
  h=from:to:subject; b=...
ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass smtp.mailfrom=you@yourcompany.com;
  dkim=pass header.d=yourcompany.com; dmarc=pass

中間者ごとに三つのヘッダーが付き、i= で番号が振られます。

• ARC-Authentication-Results — そのホップが見た認証結果。手を加える前の姿であり、これが実質的な中身です。
• ARC-Message-Signature — そのホップによるメール本体への署名。残したスナップショットを後から書き換えられなくします。
• ARC-Seal — チェーンそのものへの署名。これがあるからこそ、ばらばらの主張の寄せ集めではなく一本の鎖になります。

i= は位置を表します。i=1 が最初の中間者、i=2 はその後に封をし直した者です。番号が最大の ARC-Seal の cv= がチェーン検証の結果で、最初のホップなら none、そこまでのチェーンが検証できていれば pass、できていなければ fail です。cv=fail はどこかでチェーンが切れたという意味で、そこに載っている結果は何も証明しません。

そしてメールを判断するうえで肝心なのがここです。ARC は迂回路ではありませんし、チェーンが有効であることは DMARC 成功と同義でもありません。 「このメールはすべて通過した」と主張する ARC セットは誰でも付けられます。攻撃者にも付けられます。証拠になるのは、最終的な受信側がその封をしたドメインを信頼している場合だけで、これは先ほど authserv-id に適用したのと同じ判断です。どの中間者を認めるかは受信側が自分で決めます。ARC はその判断材料を与えるのであって、認めることを義務づけるものではありません。

したがって ARC チェーンは判定ではなく説明として読んでください。転送されてきたメールが SPF も DKIM も失敗したのに配送された、その理由を教えてくれるものです。解析ツールは見つかった ARC セットの数とチェーン検証の状態を表示するので、そのメールが中間者を経由したのかどうかを一目で確認できます。

「偽装」と「正当だが壊れている」を並べる

どちらも DMARC に失敗します。切り分けるのはヘッダーです。

率直にまとめると、単独の異常はたいてい設定ミス、複数が同じ方向を指すならそのメールは敵対的なものとして扱うべき、ということです。

読解チェックリスト

1. 生のソースを入手し、最初の空行までをコピーする。
2. まず Authentication-Results を読む。 authserv-id が信頼できるシステムのものか確認する。
3. 各判定がどのドメインに適用されたかを記録する。 合否だけでは足りません。見知らぬドメインの spf=pass は From 行について何も証明しません。
4. Received の連鎖で信頼境界を見つける。 その下はすべて主張です。
5. 入口のホップの角括弧の IP を採り、保有者を確認する。
6. 識別子のフィールドを比べる。 From アドレスと表示名、Return-Path、Reply-To、Message-ID。
7. DKIM 署名の d= と h= を確認し、from が覆われているか見る。
8. ARC セットがあれば、番号が最大のものの cv= を見る。 そして封をしたドメインを信頼できるかを自問する。
9. 個々のフィールドではなくパターンで判断する。

毎回これを目視でやる代わりに、ヘッダーをメールヘッダー解析ツールに貼ってください。ホップごとの経路と各ホップの所要時間を並べ、認証結果をそのまま転記するのではなく解析し、表示名のなりすましや識別子の食い違いを指摘し、DKIM 署名をフィールド単位で分解します。ローカルで動作するので、メールは手元の端末から出ません。

そして結論が「偽装されているのは自社のドメインだ」、あるいは「自社の正規の送信元がアライメントを通せない」だった場合、それは鑑識ではなく設定の問題です。自分のドメインが何を公開しているかを SPF/DMARC チェッカーで確認し、答えが「強制がまだ有効になっていない」であれば、p=none から p=reject へが、メールを失わずに段階的に有効化する手順です。