「メールヘッダーを見ればわかると言われても、英語だらけで読めない」。
銀行や通販サイトを名乗るメールが届き、差出人を確かめようとして困った経験はありませんか。
メールヘッダーは、メールの配送記録や差出人情報を確認できる場所です。
この記事では、表示方法からReturn-Pathの意味、なりすまし確認の注意点まで、ダミーのサンプルと図で解説します。
全部を暗記せず、必要な項目を探せるようになりましょう。
まずは結論から
メールヘッダーは、差出人・宛先・配送経路・認証結果などを記録する、メール本文に付随した情報です。
手紙にたとえると、差出人欄や配送の追跡記録に当たります。
- なんのためにあるかというと、メールの表示や処理、配送トラブルの調査に使うためです。
- 「下から上に読む」のは、主にReceivedの配送履歴です。
- Return-Pathは、配信エラーの返送先を表します。
- なりすまし確認では、Fromと受信側の認証結果を合わせて見ます。
- ヘッダーだけで、メールの内容が安全だと断定することはできません。
まず目的を知り、手元のメールで表示方法を試すと理解しやすくなります。
メールヘッダーの役割と、わかること・わからないこと
メールは大きく、ヘッダーと本文に分かれます。
普段見ている差出人や件名も、ヘッダー情報の一部です。
メールソフトは、その中から必要な情報だけを読みやすく表示しています。
詳細ヘッダーを開くと、メールサーバー（メールを受け渡すコンピューター）の記録なども確認できます。
送信者のソフトが作る項目と、配送途中や受信時に追加される項目が混在している点が特徴です。
| 確認したいこと | 主な項目 | 読み取れる範囲 |
|---|---|---|
| 誰からのメールか | From | 表示上の差出人。本人の証明ではない |
| どこを通って届いたか | Received | 各サーバーの受け渡し記録 |
| 認証の結果 | Authentication-Results | 受信側などが行った検証の結果 |
| エラーがどこへ返るか | Return-Path | 配送上の返送先 |
| メールを識別する情報 | Message-ID | 調査や関連付けに使う識別子 |
たとえば「午前中に送ったのに、届いたのは午後」というときは、Receivedの時刻が手掛かりになります。
ただし、記録が不完全だったり時計がずれていたりすると、ヘッダーだけでは原因を確定できません。
また、接続元のIPアドレス（通信相手を識別する番号）が見えても、送信者本人の住所とは限りません。
メールサービスのサーバーを示すことも多く、個人の特定までできる情報ではないのです。
Gmailでのメールヘッダーの表示方法
パソコンのブラウザ版Gmailでは、対象メールのメニューから開けます。
受信箱全体のメニューと、個々のメールのメニューを取り違えないのがコツです。
Gmailでメールヘッダーを表示する操作の流れを示した模式図。画像を開くと拡大できます。- パソコンのブラウザでGmailを開きます。
- 調べたいメールを開きます。
- そのメールの返信アイコン横にある「その他」（縦の3点）を押します。
- 「メッセージのソースを表示」を選びます。
- 別画面で詳細ヘッダーを確認します。保存する場合は「クリップボードにコピー」を使います。
複数のメールがまとまった会話では、調べたい1通を展開してから操作してください。
差出人の横の詳細表示だけでは、配送履歴まで含む全文は見られません。
手順はGoogleのGmail公式ヘルプで確認できます。
※ GoogleはGmailを提供する企業です。リンク先はメールの詳細ヘッダーに関する公式ヘルプです。
ソースには、ヘッダーに続いて本文が含まれることもあります。
メール全体を外部へ貼り付けないよう、コピー後に内容を確認しましょう。
Outlookでのメールヘッダーの表示方法
Outlookは、新しいOutlook・Web版と、クラシックOutlookで操作が異なります。
「ファイル」が見当たらないときは、使っている種類を先に確かめてください。
新しいOutlookとクラシックOutlookでメールヘッダーを表示する手順の模式図。画像を開くと拡大できます。新しいOutlook・Outlook on the web・Outlook.com
- 調べたいメールを開きます。
- メッセージ上部の「その他のアクション」（3点のボタン）を選びます。
- 「表示」から「メッセージの詳細を表示」を選びます。
- 表示された詳細情報を確認し、必要なら選択してコピーします。
クラシックOutlook for Windows
- メールをダブルクリックし、閲覧ウィンドウの外にある別ウィンドウで開きます。
- 「ファイル」→「プロパティ」を選びます。
- 下部の「インターネット ヘッダー」欄を確認します。
- 欄内を選択してコピーし、メモ帳などに貼り付けると読みやすくなります。
本記事の操作案内は2026年9月11日に確認した公式情報に基づきます。
更新や表示言語で表記が違うときは、MicrosoftのOutlook公式手順で対象製品を選んでください。
※ MicrosoftはOutlookを提供する企業です。リンク先は同社の公式サポートです。
図は操作の順番を示す模式図で、実画面のスクリーンショットではありません。
Mac版やスマートフォン版の操作とは区別してください。
ダミーのメールヘッダーと、番号でわかる読み方
最初から全項目を読もうとすると、どこを見ているのかわからなくなります。
まずは次の8か所だけを探してみましょう。
メールヘッダーのダミーサンプルを8つの枠と番号で解説した図。画像を開くと拡大できます。図は主要項目を抜き出し、日時などを短縮した見取り図です。
対応するテキスト例を下に示します。番号と枠は説明用で、実際のヘッダーには付きません。
Return-Path: <bounce@example.com>
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
Received: from relay.example.com (relay.example.com [192.0.2.10])
by mx.example.net with ESMTP;
Fri, 11 Sep 2026 10:00:03 +0900
Received: from submit.example.com (submit.example.com [192.0.2.20])
by relay.example.com with ESMTP;
Fri, 11 Sep 2026 10:00:01 +0900
From: Shop <news@example.com>
Reply-To: support@example.com
To: reader@example.net
Subject: Test message
Date: Fri, 11 Sep 2026 10:00:00 +0900
Message-ID: <sample-001@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
アドレス、ドメイン（example.comのような名前）、IPアドレスはすべて説明用です。
認証結果も架空の設定で、署名そのものなどは省略しています。実際に認証を検証できるメールではありません。
①Return-Pathと②Authentication-Results
①Return-Pathは、配信できなかったことを知らせるエラーの返送先です。
②Authentication-Resultsは、メールの認証について受信側などが記録した結果を示します。
この例では、mx.example.netが記録した想定です。
③④Receivedと⑤From
③④Receivedは、どのサーバーからどのサーバーへ渡ったかを示します。
⑤Fromは、メールソフトに表示される差出人です。
「Shop」という名前と、山括弧内の実際のアドレスを分けて確認してください。
⑥Reply-To・⑦To・⑧Subject
⑥Reply-Toは、通常「返信」を押したときの宛先です。指定がなければ、通常はFromが返信先になります。
⑦Toは表示上の宛先、⑧Subjectは件名です。
Toと実際の配送先は必ずしも同じではなく、Bccで受け取るメールなどが例に当たります。
図で省略した項目と、折り返し行
Dateは送信側が設定した作成日時、Message-IDはメールの識別子です。
どちらも単独で送信者を証明するものではありません。
MIME（Multipurpose Internet Mail Extensions。本文の形式などを扱う仕組み）の関連項目もよく現れます。
Content-Typeは本文の種類を示し、charset=UTF-8は文字を扱う方式の指定です。
件名が「=?UTF-8?B?…?=」のように見えても、日本語を一定の形式に変換した表記かもしれません。
メールの文字化けと本文形式の関係は、こちらで詳しく解説しています。
なお、空白やタブで始まる行は、前の項目の続きとして読むのが基本です。
上のAuthentication-Resultsは4行ありますが、1つの項目です。
ヘッダーと本文は空行で区切られます。メール形式の仕様（英語）にも、この構造が定められています。
Receivedを「下から上」に読む理由
Receivedは、配送を担当したサーバーが新しい記録を上へ追加するため、下から上へ読むと配送順になります。
新しい荷物の追跡履歴が、一覧の一番上に増えるイメージです。
メールヘッダーのReceivedを下から上に読む配送順の模式図。画像を開くと拡大できます。この図は時系列の模式図です。テキスト例では、作成日時が10時00分00秒、下側のReceivedが01秒、上側が03秒です。
④で送信側から中継へ渡り、③で中継から受信側へ届いた、と読み取れます。
Received内の「from」は渡してきた相手、「by」はその記録を付けた受け取り側です。
⑤の差出人項目「From:」とは役割が違います。
「with ESMTP」は、拡張されたメール転送方式を使ったことを示します。
時刻を比べるときは、末尾の「+0900」などにも注目します。
これはUTC（Coordinated Universal Time。世界で時刻を比較する基準）から9時間進んだ表示で、日本時間に相当します。
違う時差表記をそのまま引き算しないでください。
ただし、一番下のReceivedが必ず本当の送信元とは限りません。
送信者が偽の履歴を混ぜる可能性があるため、調査では自分の受信サービスが付けた記録を起点に、上側から信頼できる範囲を確認します。
配送順を理解する向きと、証拠として信用できるかの判断は別です。
追記の規則と送信元偽装の限界は、メール配送の仕様（英語）で確認できます。
Return-Path・From・Reply-Toの違い
「差出人とReturn-Pathが違う。偽メールなのでは？」と迷うかもしれません。
この3つは役割が違うので、不一致だけでなりすましとは判断できません。
| 項目 | 役割 | 通販メールでの例 |
|---|---|---|
| From | 読者に示す差出人 | お店の案内用アドレス |
| Reply-To | 読者が返信する宛先 | 問い合わせ窓口 |
| Return-Path | 配信エラーを返す宛先 | 配信システムのエラー受付 |
メール配送では、画面に表示する差出人とは別に、配送用の差出人が使われます。
これをエンベロープFrom（配送用の封筒に書く差出人に相当する情報）と呼びます。
Return-Pathは、最終配送時にその返送先を記録する項目です。
外部の配信サービスを使うお店では、Fromがお店のドメイン、Return-Pathが配信会社のドメインになることもあります。
「違うから危険」「同じだから安全」のどちらも早合点です。
Reply-Toが予想外の宛先なら、返信を保留して公式窓口で確認してください。
なりすまし確認で見るSPF・DKIM・DMARC
差出人の表示は書き換えられるため、名前だけでは判断できません。
そこで手掛かりになるのが、②Authentication-Resultsの認証結果です。
メールヘッダーでFromと認証結果を確認し公式の別経路で依頼を照合する図。画像を開くと拡大できます。認証方式は次の3つを押さえましょう。
- SPF（Sender Policy Framework。配送用の差出人ドメインが、その送信サーバーを許可しているか確かめる仕組み）
- DKIM（DomainKeys Identified Mail。ドメインの電子署名を検証し、署名対象の内容が保たれているか確かめる仕組み）
- DMARC（Domain-based Message Authentication, Reporting, and Conformance。Fromのドメインと認証されたドメインの整合を確かめる仕組み）
SPFの成功だけでは、画面に見えるFromのドメインまで確認できたとは限りません。
DKIMも、署名したドメインとFromが別の場合があります。
その関係を確認するのがDMARCです。
DMARCは、SPFまたはDKIMの少なくとも一方が成功し、その認証ドメインがFromと所定の条件で一致するとpassになります。
この一致条件をアライメントといい、設定によって完全一致か、組織ドメインの一致かが変わります。
両方の認証成功が必須という意味ではありません。DMARCの仕様（英語）で条件を確認できます。
pass・fail・noneの読み方
passはその認証に成功、failは失敗を示します。
noneは認証に必要な署名やポリシーがない場合などで、具体的な意味は方式ごとに異なります。
一時的な問題を示すtemperrorなどもあり、結果がないことも含めて「安全」と読み替えないでください。
一方、転送でSPFが失敗したり、メーリングリストによる変更でDKIMが失敗したりすることもあります。
failだけで攻撃と確定するわけではありません。Gmailの認証に関する公式説明も、未認証と迷惑メールを区別しています。
信用するのは、受信側が記録した認証結果
Authentication-Resultsが複数あっても、都合のよいpassを選んではいけません。
偽の認証結果を送信者が入れる可能性があり、自分の受信サービスや管理者が信頼するシステムの結果を見る必要があります。
サーバー名の文字列や「一番上にある」というだけで、本物と確定はできません。
迷ったら、サービスが表示する認証の要約や、管理者の調査結果を使いましょう。
この信頼範囲の考え方は、認証結果ヘッダーの仕様（英語）でも説明されています。
さらに、攻撃者が自分のドメインで認証を正しく設定すれば、危険なメールでもpassになります。
正規アカウントが乗っ取られている場合も、認証だけで見抜けるとは限りません。
怪しいメールを見つけたときの確認手順
ヘッダーを読み切れなくても、先に取れる行動があります。
急いで支払うよう求められた場面ほど、いったん操作を止めてください。
- 本文のリンクや添付ファイルを開かず、返信や送金も保留します。
- Fromの表示名だけでなく、アドレスのドメインを確認します。
- 受信サービスが示す認証結果と、Reply-Toなどを照合します。
- 普段使っている公式アプリや保存済みの連絡先から、依頼が本物か確かめます。
- 判断できなければ、迷惑メール報告や社内の管理者への相談を行います。
正規に見える名前でも、ドメインが一文字違う場合があります。
また、「正規名.example.org」のような文字列を見て、知っている名前が含まれるだけで信用しないでください。
Outlookでの報告と受信拒否の使い分けは、次の記事が役立ちます。
ヘッダー解析ツールへ貼り付ける前の注意
解析ツールは、Receivedの経路や時間を整理する補助になります。
ただし、個人名、メールアドレス、件名、組織内部のサーバー名などが含まれ得ます。
会社のメールは、外部送信が許可されたツールか確認してから利用してください。
相談用に伏せ字のコピーを作る場合も、原本は別に保管します。
署名対象のヘッダーや本文を変えると、DKIMの再検証には使えなくなることがあります。
通常の「転送」では元の情報が十分残らないこともあるので、管理者が指定する形式で共有するのが確実です。
よくある質問
- メールヘッダーは全部、下から上に読むのですか？
いいえ。主にReceivedの配送順を追うときの読み方です。FromやSubjectなどは、項目名を探して読みます。 - Return-Pathが空の「<>」なのは異常ですか？
配信エラー通知などでは、エラーの通知が往復し続けることを防ぐため、空の返送先が使われます。空というだけでは異常と判断できません。 - メールヘッダーで送信者の住所や個人を特定できますか？
通常、ヘッダーだけではできません。IPアドレスは配送サーバーの情報である場合もあり、個人の居場所を直接示すものではありません。 - スマートフォンのGmailでも全文を確認できますか？
本記事はパソコンのブラウザ版での全文表示を案内しています。アプリの差出人詳細や認証表示とは別なので、全文を探せないときはパソコンで開いてください。 - SPF・DKIM・DMARCがすべてpassなら安全ですか？
いいえ。認証はメールの内容や依頼の正当性を保証しません。ドメイン自体の確認と、公式の別経路での照合も必要です。
まとめ
メールヘッダーは、難しい英語を全部読むためのものではありません。
調べたいことに合った項目を選べば、配送や差出人を確認する手掛かりになります。
- Receivedは下から上へ配送順を追い、記録の信頼性は別に確認します。
- Fromは表示上の差出人、Reply-Toは返信先、Return-Pathはエラーの返送先です。
- なりすましは1項目で決めず、受信側の認証結果とドメイン、依頼内容を合わせて確認します。
- 判断に迷うメールは操作を保留し、公式アプリや既知の連絡先で確かめます。
まずは身近なメールを1通開き、FromとReceived、Return-Pathの場所を探してみましょう。
