【メールヘッダー解析】不審な迷惑メール・なりすましの配信ルートや認証を調査する方法

「このメール，なんだか怪しいな……」「本当に取引先からのメールかな？」と，不安になったことはありませんか？

身に覚えのない請求書や，アカウント停止を警告する不審なメールを受け取ると，誰でもドキッとしますよね．最近のなりすましメールやフィッシングメールは本物そっくりに精巧に作られており，メールソフトの表示画面だけで人間の目で見分けるのが非常に難しくなっています．

実は，そうした怪しいメールの痕跡や追加調査の手がかりが，メールの「裏側」に隠されています．それが「メールヘッダー（生ソース）」と呼ばれるデータです．ただし，あらかじめ強くお伝えしておかなければならないのは，メールヘッダーは送信者の戸籍謄本や絶対的な安全証明書ではなく，あくまで技術的な「配送履歴やサーバー処理の痕跡」に過ぎないということです．ヘッダーの記録が完璧に見えたとしても，それだけでメールの送信者が確実に本人である，あるいは本文の内容が安全であると断定することはできません．

「なんだか専門用語ばかりで難しそう……」と思われるかもしれませんが，大丈夫です！この記事では，ITやセキュリティの深い技術的な知識がない方でも分かりやすいように，メールヘッダーの仕組みや見方を解説します．メールの送信元や配信ルートを正しく調べて，怪しいメールの構造とリスクを冷静に理解できるようになりましょう．

§1. 不審なメールに潜むリスクと，私たちが受けるストレス

「あなたのアカウントが不正利用されました」「至急，以下の口座へお振り込みください」「重要なお知らせ：パスワードの変更が必要です」——こんなメールが突然届いたら，誰だって焦ってしまいますよね．

こうしたメールの多くは，「ビジネスメール詐欺（BEC）」や「フィッシング詐欺」と呼ばれるサイバー攻撃の一種です．攻撃者は私たちの焦りや不安，または業務上の義務感といった心理につけ込み，大切なIDやパスワード，クレジットカード情報，さらには会社の重要な資金や機密情報をだまし取ろうと画策します．

「自分は気をつけているから大丈夫」と思いがちですが，最近の詐欺メールは正規のロゴを使用し，文章も自然で本物そっくりに作られています．なぜなら，メールの仕組み上，相手は送信元のアドレス（From）をいくらでも自由に書き換えることができるからです．そのため，表面上の表示だけでなく，追加調査の手がかりとしてメールの「配送履歴」や「検査記録」のような役割を持つメールヘッダーの痕跡を調べることがあります．ただし，メールの仕組み（SMTP）上，最下行にある最古の情報が真の送信元とは限りません．悪意のある送信者は，自分にとって都合の良い虚偽のヘッダー行を最初に追加してから送信することが可能です．そのため，調査を行う際は「受信側の既知の信頼できるサーバー」から送信側に向かって逆順にたどり，信頼できる境界を越えた先の情報は参考程度に留めるという極めて慎重な姿勢が求められます．表面的な見た目に騙されず，技術的な事実をもとに「このメールの出所はどこか？」を客観的に評価するためのステップを見ていきましょう．

§2. メールの裏側に書かれた「配送伝票」：メールヘッダーの仕組み

「SMTP」や「RFC」といった専門用語が出てくると，頭が痛くなってしまいますよね．ここでは，メールを「手紙や宅配便の封筒」に例えて考えてみましょう．メールシステムは郵便システムと非常に似た構造を持っています．

2.1 封筒に書かれた名前（エンベロープFrom）と，便箋に書かれた名前（ヘッダーFrom）

手紙を郵送するときを想像してみてください．

• エンベロープFrom (RFC 5321)：郵便局や配送業者が，もし手紙が宛先不明で届かなかった場合に「戻し先（バウンス先）」として確認する，封筒の裏に書かれた返送先住所です．本人の真の差出住所を証明するものではありません．メールサーバー間の通信では，このアドレスが使われます．
• ヘッダーFrom (RFC 5322)：手紙の封を切って開いたときに，便箋の冒頭に書かれている「〇〇より」という差出人の名前（From: フィールド）です．私たちが普段メールソフトで見ているのはこちらです．

実は，メールの世界でもこれと全く同じことが起きています．

悪意のある送信者は，ユーザーを騙すために便箋（ヘッダーFrom）には「大手の銀行や有名企業」の名前を書き，受信者を安心させようとします．しかし，郵便システムが配送エラー時の返送先として使う封筒（エンベロープFrom）には，自分が用意した全く別のドメイン（差出人）を設定していることが多いのです．DMARCなどの認証技術では，これら2つの送信元アドレスの整合性が評価されますが，仮に認証がすべてPASSしたとしても，メール本文のURLや添付ファイルが悪意のない安全なものであるという保証には決してなりません．

2.2 優先して確認すべき主要なヘッダー情報

メールヘッダーには数十行に及ぶ多くのメタデータが含まれています．すべてを読み解く必要はありませんが，セキュリティや配信状況の分析において，優先的に確認すべき主要な項目を押さえておきましょう．

このように，ヘッダーに書かれている情報はそれぞれ異なる意味と制約を持っています．これらを総合的に判断することが，メール解析の第一歩となります．

§3. Receivedヘッダー：宅配便の「配送履歴」を追いかける

荷物をネットで注文したとき，配送業者のページで「今どこを通過したか」「どの拠点で処理されたか」の履歴を確認したことはありませんか？

メールヘッダーにおける Received ヘッダーは，まさにその「配送履歴（トラッキングログ）」のようなものです．メールが送信元から宛先に届くまでに経由した各メールサーバー（MTA）が，通過するたびに自動的に自分自身の記録をヘッダーの先頭に追加していきます．

3.1 履歴は「古いものから新しいものへ」整理される

生のメールヘッダーでは，新しい中継記録ほど一番上に追加されていきます．つまり，一番上が最終的な到着地で，下に行くほど過去の記録になります．しかし，当サイトの解析ツールでは，ユーザーが時系列を追いやすいように内部の処理で「古い記録（送信元）から新しい記録（受信先）の順」に配列を逆順（reverse）に並べ替えて画面に表示します．

ツール上では，一番上が最初の送信元サーバー，一番下が最終的な受信先メールサーバーとして視覚的に分かりやすく表示されます．ただし，前述の通り，攻撃者が自前のサーバーで偽の Received 行を事前に追加してから送信することが技術的に可能であるため，最も古いとされる先頭の記録が必ずしも真の送信元であるとは限りません．例えば，明らかに偽造された無関係のホスト名が含まれている場合は，それらを真に受けないよう注意が必要です．なお，私的IPアドレス（例：192.168.x.x）は内部中継の正常な記録として記載されることもあり，それだけで虚偽とは限りません．確実に信頼できるのは，ご利用中のメールプロバイダー等を含む既知の信頼境界の中で記録されたものです．

3.2 配送履歴（Receivedヘッダー）の構成要素の分解

標準的な Received ヘッダーは，以下のような情報を括弧や特定のキーワードと共に一つの長い文字列として記録します．例えば，Received: from mail.example.com (mail.example.com [192.0.2.1]) by mx.example.net with ESMTPS id 12345 for <user@example.net>; Wed, 07 Oct 2026 12:00:00 +0900 (JST) のような形式です．

1. from 句（送信側）: 送信元がSMTP通信時に自己申告したホスト名と，受信側サーバーがネットワーク接続から実際に確認した生のIPアドレス（通常は角括弧 [] 内に記載されます）．このIPアドレスはあくまで送信元サーバーのネットワーク上の場所を示すものであり，送信した「人間」の所在や身元を法的に証明するものではありません．

2. by 句（受信側）: そのメールを受け取って処理したサーバーのホスト名．

3. with 句（プロトコル）: メールを受け渡す際に使用された通信プロトコル（通常のSMTPや，TLSで暗号化されたESMTPSなど）．

4. 日付表示（処理日時）: 受信側サーバーがこのメールの処理を完了し，次のキューへ渡したときの日時とタイムゾーン．

3.3 配送遅延とタイムスタンプの扱いに関する深い注意

当ツールでは，隣り合う Received レコードのタイムスタンプをプログラムで解析し，正の差分（時間が進んでいる場合）のみを「前のノードからの転送時間（遅延）」として抽出して参考表示します．

• 負の差分はゼロ扱い: インターネット上のサーバー間で内部時計（NTP同期など）がずれている場合，時間が逆戻りしているように見える記録が残ることがあります．ツールではこの場合，遅延時間をマイナスとして計算せず安全に「0」として扱います．タイムスタンプが逆転しているからといって，必ずしもサーバーの時計の設定ミスだとは限りませんし，偽装目的で改ざんされた痕跡である可能性もあります．
• 遅延時間の保証なし: サーバーごとのヘッダーの書き込みフォーマットの細かな違いや，日時の欠落，タイムゾーン文字列のパース不能（非標準的な表記）などにより，正確な遅延時間が計算できないことも多々あります．また，仮に数時間単位の遅延が計算できたとしても，その根本原因（スパムフィルターでの一時的な隔離保留なのか，ネットワーク回線の物理的な切断なのか，単なる送信キューの滞留なのか）をヘッダーの記録だけで完全に断定することは不可能です．遅延はあくまで調査の目安として捉えてください．

§4. 送信ドメイン認証技術（SPF / DKIM / DMARC）の基礎知識

「差出人を偽装したなりすましメール」を防ぐために，現代のメールシステムは，SPF，DKIM，DMARCという3つの送信ドメイン認証技術を組み合わせています．これらがどのような仕組みで動いているのか，そしてどのような限界や制約があるのか，基礎的な部分を詳しく解説します．これらの知識を持つことで，解析ツールの表示結果をより正確に読み解くことができます．

4.1 SPF (Sender Policy Framework) の仕組みと限界

• 概要：送信元ドメインの所有者が，「このドメインのメールは，このIPアドレスのサーバー（または特定のクラウドサービス）からしか送りません」という許可リスト（SPFレコード）を，DNS上のTXTレコード（例：v=spf1 ip4:192.0.2.0/24 include:_spf.example.com ~all）として公開する仕組みです．この v=spf1 という文字列から始まるレコードだけがSPFとして扱われます．
• 検証の動き：受信側サーバーは，メールを受け取るとエンベロープFrom（Return-Path）のドメインのDNSを参照し，接続してきたIPアドレスがその許可リストに含まれているかを確認します．許可リストに合致していれば pass となります．設定には厳格な拒否（-all）や緩やかな失敗（~all），ニュートラル（?all）などがあります．
• 注意点と制約：

SPFはあくまで「送信元IPアドレスの許可」を確認するものであり，送信した人間の本人確認ではありません．例えば，攻撃者が自身で取得したドメイン（spammer.example）に対して正しいSPFレコードを設定し，そのドメインをエンベロープFromとして使用すれば，SPFは完全に pass してしまいます．また，メールが第三者のサーバーを経由して自動転送された場合，受信側から見た接続元IPアドレスが「転送サーバーのもの」に変わるため，元のエンベロープを保ったまま許可外のIPから転送されるとSPFの検証は失敗（fail または softfail）することがあります．ただし，SRS等による書き換えや許可構成によって成功することもあります．なお，-all は検証結果の方針であり，配信が必ず拒否されるわけではありません．さらに，SPFレコードの評価においては過負荷を防ぐため上限（ RFC 7208 参照）が設けられていますが，これはDNS参照を伴う特定のメカニズム等の合計が10回という意味であり，全DNS問い合わせ数ではありません．この制限を超過した場合は PermError 扱いとなります．

4.2 DKIM (DomainKeys Identified Mail) の仕組みと限界

• 概要：送信側サーバーが，メールの特定のヘッダー（From，To，Subjectなど）と本文をもとに，公開鍵暗号方式を用いた「電子署名」を作成してメールに添付（DKIM-Signature ヘッダー）します．受信側は，送信元ドメインのDNSから特定のセレクタ（s= タグ）を用いて公開鍵を取得し，その署名の正当性を検証します．一つのメールに複数のDKIM署名（たとえば送信元ドメインと，経由したメーリングリストのドメインの両方）を付与することも許可されています．
• 検証の動き：署名されたドメイン（d= タグ）の公開鍵を使用し，署名対象のデータ（h= タグで指定されたヘッダーや，bh= タグで指定された本文のハッシュ値）が，正規化処理を経た上で配送中に一致していれば pass となります．これは対象範囲の完全な不変や安全を保証するものではありません．
• 注意点と制約：

DKIMは「署名されたドメインの正当性」と「対象データの非改ざん」を強力に証明しますが，メールのすべてのフィールドが偽造不可能になるわけではありません．署名対象のヘッダーが配送中に書き換えられたり（例：件名へのタグ追加），ウイルス対策ソフト等によって本文が変更されたりすると，対象範囲のハッシュ値が変わってしまい署名の検証は失敗し得ます．一方，署名対象外のヘッダーの変更は必ずしも失敗を引き起こすわけではありません．正規化の仕組みもあるため「全く改ざんされていなければ」と完全な不変を保証するものではありません．なお，bh= は本文のハッシュであり，署名ドメインと記載上のFromの人間が同一である証明ではありません．また，極めて重要な点として，攻撃者が自身の所有するスパム用ドメインで有効なDKIM署名を付与して送信することも可能です．つまり，DKIMがPASSしているからといって，送信者が信頼できる人物であるとは限りません．

4.3 DMARC (Domain-based Message Authentication) とアライメント

DMARCは，SPFとDKIMの結果を活用し，最終的なメールの取り扱いを決定するための上位の枠組みです．

• アライメント（整合性）：

DMARCを通過（pass）するためには，SPFとDKIMの両方がPASSしている必要はありません．SPFかDKIMのどちらかが成功し，かつその成功した認証のドメインが「ヘッダーFrom」のドメインと合致（アライメント）している必要があります．この仕組みにより，受信側の方針に従って巧妙ななりすましの判断が行われます．アライメントには完全一致を求めるStrict（厳格）と，サブドメインの違いを許容するRelaxed（緩和）があり，条件が異なります．

• ポリシーとレポート機能：

ドメインの所有者は，「DMARCの検証に失敗したメールをどう処理してほしいか」をDNS上（_dmarc.example.com）で宣言できます．p=none（何もしない・レポートのみ），p=quarantine（迷惑メールフォルダ等へ隔離），p=reject（受信を完全に拒否）の3つがあります．また，DMARCには集計レポート（rua）や失敗レポート（ruf）を管理者に送信する機能（ RFC 7489 参照）がありますが，これらは種類や形式が異なり，送信されるかは受信側の方針にも依存します（当解析ツールではこれらのレポートXMLを処理する機能は提供していません）．ただし，p=reject に設定したからといって，世界中のすべての受信サーバーが必ずその指示に従ってメールを破棄してくれるわけではありません．受信側のシステムの仕様や，管理者の独自の設定にも大きく依存します．

当サイトの解析ツールでは，Authentication-Results や ARC-Authentication-Results ヘッダーに記載された文字列から，これらのSPF，DKIM，DMARCの結果を正規表現等で簡易的に抽出して画面に表示します．ツール自体が独自にDNSを引いて再検証を行ったり，暗号署名を計算し直したりしているわけではないため，この表示結果の出所は必ず「全ヘッダー」タブの原文と照らし合わせて，本当に信頼できる自社の受信サーバーが記録したものか（第三者が書き込んだ偽物でないか）を確認してください．

§5. ARC (Authenticated Received Chain) についての補足

メールがメーリングリストや個人の自動転送サービスを経由すると，前述の通りIPアドレスが変わることでSPFが失敗し，件名や本文に手が加わることでDKIMも失敗することが頻繁に発生します．その結果，本来は正常なメールであってもDMARCが失敗してしまい，必要なメールが届かなくなるという深刻な問題に対処するため，RFC 8617で定義されたARCという新しい仕組みが存在します．ARC（ RFC 8617 ）はこのような問題に対処する仕組みの一つです．

• ARCの目的と動作：中継するサーバー（ARCフォワーダー，例えばGoogleグループのサーバーなど）が，メールを受け取った時点でのドメイン認証結果（SPF/DKIM/DMARC）を ARC-Authentication-Results (AAR) ヘッダーに記録し，それに自分自身の署名（ARC-Message-Signature, AMS）と全体の改ざんを防ぐメタ署名（ARC-Seal, AS）を付けて次のサーバーへ転送します．これが経由するごとに i=1, i=2 と連鎖（チェーン）していきます．
• 限界と注意点：

最終的な受信サーバーは，このARCの記録を参照し，検証チェーンが正しければ「転送前は認証が成功していた」と見なしてメールを救済できる「場合があります」．しかし，ARCが設定されていれば必ずメールが救済される（正常に受信される）というわけではありません．受信側がその中継サーバーの信頼性を評価する等のポリシーに基づき判断を補助することがあります．ただし，チェーンが有効であっても記録全体の正しさや安全性を完全に保証するものではありません．当サイトの解析ツールはARCの暗号検証や authserv-id 表記からの自動的な信頼判定機能は持たず，あくまで記録結果を抽出して表示します（信頼境界の考え方については RFC 8601 等も参照）．

§6. メールヘッダーを取り扱う際の重要な注意点とプライバシー

メールヘッダーには，一見するとただの英数字や記号の羅列に見えますが，送信者や受信者のメールアドレス，社内のネットワーク構成を示すプライベートIPアドレス，社内サーバーの固有のホスト名（例：mail01.internal.local），そして場合によっては件名（Subject）の生データなど，取り扱いに非常に注意すべき機微な情報が大量に含まれています．

6.1 プライバシーとセキュリティへの配慮

ヘッダー情報を扱う際は，組織のセキュリティ規程や情報管理ルールに従うことが最も重要です．不審なメールの調査を社外の専門家やベンダーのサポート窓口に依頼してヘッダーを共有する場合は，調査に必要な情報だけを残し，見られては困るメールアドレスやプライベートIP，社内のシステムIDなどを伏字（マスク化）する配慮が求められます．これを怠ると，思わぬ情報漏洩事故に繋がる可能性があります．ただし，セキュリティ管理者が詳細な経路調査やインシデント対応を行うためには完全なオリジナルの情報が必要になるため，元の生データはマスク化する前に別途安全な場所に保管しておくことを強くお勧めします．

6.2 ブラウザー内での解析に関する誤解と事実

当サイトのメールヘッダー解析ツールは，貼り付けられたテキストや読み込まれた.emlファイルの内容を，サーバーに送信することなくお使いのブラウザー上で直接解析（ReactのJavaScriptによる状態管理と処理）します．そのため，外部の解析用サーバーにあなたの機密性の高いヘッダー内容をアップロードする仕組みではありません．

しかし，だからといって「外部へのデータ漏洩リスクが完全にゼロである」「完全なオフライン状態での実行と全く同一である」と過信しないでください．ウェブサイト自体を表示して動作させるための通信（アセットの読み込み等）は当然発生しますし，お使いのブラウザーにインストールされているサードパーティの拡張機能（翻訳ツール，文法チェックツール，入力補助ツールなど）が，画面上のテキストを裏側で自動的に読み取って外部に送信している可能性も否定できません．また，一度だけブラウザーの開発者ツールのネットワークタブを観察して「何も不審な送信されていない」と確認したとしても，将来のアップデートにわたっての安全性を恒久的に保証するものではありません．各種法令（GDPRや個人情報保護法）やNDA（秘密保持契約）に適合しているかどうかの個別具体的な法的判断も行うことはできませんので，あくまで補助的な調査ツールとして，ご自身の責任とローカル環境の安全性を十分に確認した上でご利用ください．

§7. メールの「配送伝票（ヘッダー）」を取り出して調べる方法

では，実際に怪しいメールのヘッダーを取り出してみましょう！お使いの主要なメールソフトごとに手順をまとめました．少し奥まったメニューにありますが，慎重に操作すれば簡単です．

7.1 各種メールソフトにおけるヘッダー抽出手順

• Gmail (Webクライアント): メールの「その他」メニューから「メッセージのソースを表示」を選択してコピーします（詳細は公式ヘルプ）．
• Microsoft Outlook: 「ファイル」のプロパティや「メッセージ詳細」等からインターネットヘッダーをコピーします（詳細は公式ヘルプ）．
• その他のメールソフト: 各公式ヘルプ等で「生ソース（raw header）」を取得する方法をご確認ください．

7.2 当サイトの「メールヘッダー解析ツール」を利用する

コピーしたヘッダーのテキストは，当サイトの メールヘッダー解析ツール で見やすく解析できます．

1. メールヘッダー解析ツール のページを開きます．

2. 画面のテキストボックスにコピーしたヘッダーを貼り付けるか，「EMLファイルを読み込む」ボタンからローカルの.emlファイルを選択します．（※現在のツール実装ではドラッグ＆ドロップ操作には未対応です）．

3. 「解析を実行する」ボタンを押すと，以下のタブに整理されて情報が表示されます．

• 概要: 件名や送信日時，抽出された各種認証ステータスの直感的なバッジ表示．
• 認証: SPF/DKIM/DMARCの記載内容の詳細と抽出結果テキスト．
• 配送ルート: Receivedヘッダーから抽出した中継経路の時系列リストと遅延時間．
• 全ヘッダー: 読み込まれたすべてのヘッダーと値を検索可能な一覧表で表示．

§8. こんなときはどうする？よくあるトラブルと解決のヒント

ツールを使って解析した結果，エラーが表示されたり，うまく情報が読み取れなかったりした場合の確認ポイントや，表示された内容の解釈に迷った際のヒントを詳細にまとめました．調査に行き詰まった際の参考にしてください．

8.1 ツールにうまく読み込まれない・情報が極端に不足している場合

• 入力テキストの欠落：コピーしたテキストの途中で文章が切れていないか確認してください．メールヘッダーはルーティングの複雑さによっては数十行から百行を超える長大なテキストになることが多いため，マウスのドラッグで選択すると下部が漏れてしまうことがよくあります．必ず「全選択」ショートカット（Ctrl+A 等）を使用して，すべてをコピーできているか再度確認しましょう．
• HTMLの誤混入：メールソフトの画面に表示されている本文（HTMLソース）を誤って貼り付けないよう注意してください．ヘッダーは Key: Value の形式である必要があり，HTMLタグばかりだとツールは正しくパースできません．
• ヘッダーと本文の境界（空行）：ツールは，RFCの仕様に基づき最初の「空行（改行だけの行）」までをヘッダーの領域として処理します．コピーミス等によりヘッダーの途中に意図しない空行が紛れ込んでいると，それ以降の重要なヘッダー情報は本文とみなされ，すべて無視されてしまうことがあります．
• 未認識のフォーマットや文字化け：ツールはMIMEエンコードされた件名（=?UTF-8?B?...?=のような形式）の完全な復号処理は行わず，生のテキストとしてそのまま表示します．また，長すぎて複数行に折り返されているヘッダー行は空白を基準に自動で結合されますが，非標準的な書式で記述されているヘッダーの場合は，正しく分割・認識されないことがあります．
• 認証結果が全く表示されない：もし Authentication-Results が一つも見当たらない場合，それは受信サーバー側でSPFやDKIMのチェックを実施していないか，あるいは社内ネットワークに入る際にセキュリティゲートウェイが意図的にそのヘッダーを削除（ストリップ）してしまった可能性があります．

8.2 認証ステータスが「UNKNOWN」や複数ある場合の解釈

• 複数の認証記録の存在：メールが複数の中継サーバー（スパムフィルターや転送サービス）を経由した場合，ヘッダー内に Authentication-Results が複数存在することがよくあります．当ツールでは，それらや ARC-Authentication-Results を一つの文字列に結合し，最初に見つかったSPF，DKIM，DMARCの一致結果を正規表現で抽出して表示する簡易的な仕組みになっています．そのため，最新の受信サーバーの検証結果とは異なる過去の値が優先して表示される可能性もあります．必ず「全ヘッダー」のタブから生の文字列を検索し，どの authserv-id（サーバー名）が記録した認証結果なのかを原文で直接確認してください．もし「全ヘッダー」タブの表が空に見える場合は，上部の検索絞り込みボックスに意図しない文字列が残っていないか確認し，クリアしてみてください．
• DNSの自動再検証は行いません：ツールはあくまで「メールのヘッダーに記載されている過去の文字列」を読み取っているだけです．解析ツール上で現在のDNSレコードを引き直してSPFを判定したり，DKIM署名の暗号計算を自動実行して安全性を再評価したりすることはありません．

8.3 配送ルートの時間がマイナスになる，または表示がおかしい

• 時計の差異とパースの失敗：前述の通り，記録された日時のフォーマットが標準から外れている（括弧書きのタイムゾーンが特殊など）場合，ツールが日付を正しく認識できず遅延を計算できないことがあります．また，タイムスタンプが逆転していても，それが必ずしも「サーバーの時計が狂っている」ことを意味するわけではありません．偽装目的で意図的に過去の日時が書き込まれている場合もあります．
• 転送時の仕様による隠蔽：メールシステム（特にMicrosoft 365やGoogle Workspaceの内部処理）によっては，内部的な中継プロセスで Received 行を逐一追加しないものや，意図的に送信元のプライベートIPアドレス等の情報を秘匿して書き出す設定になっているものもあります．すべての経路が完璧に記録されているとは限りません．
• やり直したい場合：画面上の「クリア」ボタンを押すことで，現在読み込まれている解析結果やフォームの入力を完全にリセットし，新しいヘッダーを貼り付ける初期状態に戻すことができます．

§9. おわりに：メールヘッダーを調査の第一歩に活用しよう

電子メールの仕組みは古くからあるプロトコル（SMTP）に様々な機能やセキュリティパッチを上乗せして作られているため，その構造は非常に複雑です．しかし，メールヘッダーの基本的な読み解き方を知ることで，怪しいメールの配送経路や調査の手がかり，認証技術（SPF/DKIM/DMARC）がどのように機能しているのかを垣間見ることができます．

不審なメールを受け取ったときは，焦って本文のリンクをクリックしたり添付ファイルを開いたりせず，まずは落ち着いてヘッダーを取り出し，送信元や配送経路を確認する癖をつけてみてください．完全な安全保証にはなりませんが，強力な調査の手がかりになります．

当サイトのツールが，日々のメールの確認やトラブルシューティングの調査，そしてセキュリティ意識の向上の一助となれば幸いです．