メールヘッダーを読む：配送経路と認証結果の手がかり
届くまでに時間がかかったメールや、差出人が気になるメールには、本文の上に配送の記録が付いています。ただしヘッダー全体が信頼できる配送証明書というわけではありません。どのサーバーが書いた行なのかを意識しながら読むと、調査に使える部分を見つけやすくなります。
画面の差出人と配送用の差出人を分ける
メールソフトの「メッセージのソース」「原文を表示」などから、ヘッダーを含む元のメッセージを開きます。通常の転送本文に貼られた「差出人：」の表示だけでは、元の配送記録は読めません。
最初に見る項目
項目の役割はRFC 5322 §3.6、Return-Pathと配送記録はRFC 5321 §4.4に定義されています。
| 項目 | 分かること・限界 |
|---|---|
| From | 著者として記載されたアドレス。表示名だけで本人性は分からない |
| Reply-To | 返信先の指定。Fromと異なること自体は不正の証拠ではない |
| Return-Path | 最終配送時に記録される返送先。表示上のFromとは役割が違う |
| Date | 送信側が付ける作成日時。受信サーバーの到着時刻とは別 |
| Received | サーバーが追加する受け渡しの記録 |
Receivedは、新しい行が上に追加される
メールを受け取ったSMTPサーバーは、自分のReceived行を先頭へ追加します。通常の配送の並びをたどるなら下から上が古い順です。ただし、時刻順に並べ替えることと、記録を信用できることは別の話です。
2段の配送例を読む
下の行ではrelayが12:00:00に受信し、上の行ではinboxが12:00:04に受信した、と記載されています。fromは渡してきた側、byはその行を追加した受信側です。ここで得られる4秒は到着記録の差で、回線の転送だけにかかった時間とは限りません。待ち行列や処理時間、時計のずれも入り得ます。
Received: from relay.example.com (relay.example.com [192.0.2.20])
by inbox.example.net; Fri, 23 Oct 2026 12:00:04 +0000
Received: from sender.example.com (sender.example.com [192.0.2.10])
by relay.example.com; Fri, 23 Oct 2026 12:00:00 +0000信頼できる受信側から、記録をさかのぼる
送信者は、渡すメッセージに偽のReceived行をあらかじめ含められます。そこで調査では、受信サービスが管理するサーバーの記録を起点にします。自分の受信サービスが付けた上側の行を特定し、そのサーバーが直接観測した相手へとさかのぼる考え方です。
下端に書かれたIPが発信者とは限らない
信頼できない相手へ境界を越えた先は、送信者の主張が混ざり得ます。先頭の行でも、見慣れたホスト名があるだけで信用はできません。受信サービスの仕様や管理ログで出所を照合します。ヘッダーにあるIPを、そのまま個人の端末や住所と結び付けることもできません。
Authentication-Resultsは、誰の検証結果かを読む
Authentication-Resultsには、SPF・DKIM・DMARCなどの結果と、検証したドメインが記載されます。冒頭のauthserv-idは結果を付けた認証サービスの識別子です。信頼する受信環境が付けた結果として確認できて初めて、判定の材料になります。
結果の記載例
この記載では、SPFが見たのはexample.org側、DKIMが見たのはexample.comです。Fromがexample.comなら整合するDKIMでDMARCがpassになる例です。ただし文字列を貼り付けて読むだけでは、認証の再実行にはなりません。RFC 8601 §1.2と§7.1は、この信頼境界と偽造行の問題を説明しています。
Authentication-Results: inbox.example.net;
spf=pass smtp.mailfrom=mailer.example.org;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comヘッダー解析で並びと時刻差を読む
Online Toolsのメールヘッダー解析へ上のReceived例を貼り付けると、下の行から順に並び、次の行との差は4秒になります。解析はブラウザ内で行い、入力したヘッダーを解析のためにサーバーへ送信しません。SPF・DKIMの検証や、書かれたホストの調査は行いません。
本文を除き、折り返しを保つ
ヘッダーと本文は空行で分かれます。本文を除いたヘッダー部分を使い、行頭の空白による折り返しは残します。例のbyやspfの前の空白も、前の行の続きである目印です。入力上限は262,144文字。共有する結果にはアドレス、内部ホスト名、IPなどが含まれ得るため、必要な範囲に絞れます。負の時刻差や日時不明は、改ざんの断定ではなく時計・形式・記録の欠落を調べる手がかりです。
仕様と、認証結果を読む続き
RFC 5321 §4.4：配送記録、RFC 5322 §2.2.3：行の折り返し、RFC 8601 §2.2：Authentication-Resultsの構文。認証とFromの関係はSPF・DKIM・DMARCのalignment、位置情報の限界はIPアドレスと位置情報で詳しく読めます。