受信したヘッダーを読み取り、電子メールの配信パスを追跡する方法

電子メールは、受信トレイに到達する前に、アプリケーション サーバー、送信リレー、フィルタリング サービス、および受信者のメール エクスチェンジャを通過します。通常、各受信 SMTP サーバーは Received フィールドを追加します。これらのフィールドを読むと、遅延を特定し、メールをプロバイダーに渡したサーバーを特定し、配信スケジュールを構築するのに役立ちます。

フィールドは診断証拠であり、完全な保管過程ではありません。送信者は送信前に偽の行を追加したり、クロックが一致しない可能性があり、プライベート インフラストラクチャが詳細を隠したり書き換えたりする可能性があります。トレースは、プロバイダーのログ、認証結果、メッセージのコンテキストと合わせて使用​​します。

Received フィールドのレコードの内容

RFC 5321 セクション 4.4 では、配信またはさらなる処理のためにメッセージを受信して​​トレース情報を付加する SMTP サーバーが必要です。典型的なフィールドは次のようになります。

Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <[email protected]>;
        Mon, 03 Aug 2026 10:30:04 +0000

共通の条項はさまざまな質問に答えます。

• from は、送信側によって提示されるホストを記述し、ネットワーク接続上で観察されるアドレスを含む場合があります。
• by は、このホップを受け入れてフィールドに書き込んだサーバーを識別します。
• with は、ESMTP や暗号化された SMTP などのトランスポートまたはプロトコルのバリアントを記述します。
• id は、管理者がサーバーのログを検索できる場合に役立つキューまたはトランザクションの識別子です。
• for は 1 人のエンベロープ受信者を識別できますが、これはオプションであり、プライバシーのために削除できます。
• セミコロンの後の日付は、受信側サーバーがメッセージを受け入れたときの日付を記録します。タイムゾーン オフセットの数値も含まれます。

すべてのフィールドにすべての句が含まれるわけではありません。ゲートウェイおよび非 SMTP システムでは、見慣れない形式が生成される場合があります。 RFC 5321 では、受信側システムに、トレース ラインが異常に見えるという理由だけでメッセージを拒否するのではなく、予期しないトレース フォーマットに対して堅牢であるように明示的に指示しています。

ルートを下から上に読んでください

SMTP サーバーは、既存のフィールドの上に新しい Received フィールドを追加します。したがって、最新の受信ホップはヘッダー ブロックの先頭になります。通常、最も早く記録されたホップが一番下になります。

次の簡略化されたトレースについて考えてみましょう。

Received: from filter.example.net by mx.recipient.example;
        Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
        Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
        Mon, 03 Aug 2026 10:29:59 +0000

次のように読みます:

1. app.internal.example が outbound.sender.example にメッセージを渡しました。
2. 送信サーバーはそれを filter.example.net に渡しました。
3. フィルターはそれを受信者の mx.recipient.example サーバーに渡しました。

表示されているタイムスタンプでフィールドを並べ替えないでください。サーバーの時計が間違っているか、同期していない可能性があるため、プロトコルで定義されたフィールド順序の方が便利です。遅延を見積もる場合にのみ各タイムスタンプを 1 つのタイム ゾーンに変換し、証拠レコードに元の値を保存します。

遅延を慎重に計算してください

隣接するペアごとに、数値オフセットを適用した後、後の受信時刻から前の受信時刻を減算します。大きな正のギャップは、キューイング、レート制限、一時的なネットワーク障害、または次のサービスでの処理を示している可能性があります。それ自体では原因が特定されません。

負のギャップは通常、タイムトラベルや自動偽造証明ではなく、クロックのずれ、解析ミス、または信頼できないフィールドを示しています。オフセットが正しく処理されたかどうか、および 2 行が制御するシステムによって書き込まれたかどうかを確認してください。

独自のアプリケーションを調査するときは、トレースを次のものと関連付けます。

• アプリケーションがメッセージを要求した UTC 時間。
• 送信者のキュー ID と配信ログ。
• 信頼するインフラストラクチャによって書き込まれた最初の Received フィールド。
• 受信側プロバイダーが受信または表示を報告した時刻。
• 送信側システムによって記録された再試行ステータスまたは SMTP 応答。

開発者電子メール テスト チェックリスト では、1 つの受信ボックスの観察を配信システム全体として扱わずに、リクエストから到着までのタイムラインを記録する方法が説明されています。

どのホップが信頼できるかを決定する

一番上の Received フィールドは、表示しているメールボックスに最も近いサーバーによって追加されました。そのメールボックス プロバイダーが信頼できる場合、通常、このフィールドが最も強力な出発点になります。プロバイダーが実際にメッセージを受け入れたネットワーク アドレスを報告できます。

フィールドが認識しているインフラストラクチャと一致している限り、下方向にのみ作業します。メッセージが信頼できるプロバイダーに入力される前に作成されたとされる行は、送信者によって捏造される可能性があります。悪意のある送信者は、通常、受信者のシステムによって後で追加されたフィールドを書き換えることはできませんが、それらのシステムがそれを認識する前に、メッセージにもっともらしいトレース テキストを挿入する可能性があります。

ホスト名にはコンテキストも必要です。 from 名は、SMTP グリーティング、リバース DNS、またはローカル構成から取得される場合があります。 10.0.0.0/8 などのプライベート アドレスは内部ホップを記述することができますが、パブリック インターネット全体を直接追跡することはできません。 IP 地理位置情報の結果はおおよそのものであり、作成者の身元や物理的な位置を確立するものではありません。

受信したフィールドは認証に代わるものではありません

Received フィールドはトランスポート ホップを記述します。 SPF、DKIM、および DMARC は、ドメインの承認、署名、および調整に関するさまざまな証拠を評価します。普通に見えるルートには悪意のあるメッセージが含まれている可能性があり、正当に転送されたメッセージには複雑なルートが存在する可能性があります。

認証結果を個別に解釈するには、SPF、DKIM、および DMARC ガイドを使用してください。可視の From アドレスがルート内のすべてのホストを制御していたり、使い慣れたリレーがコンテンツを安全にしているなどと推測しないでください。

オーバーシェアせずにローカル ヘッダー アナライザーを使用する

Once Email 電子メール ヘッダー アナライザー は、ブラウザ内の Received ホップ、認証結果、および繰り返しフィールドを抽出します。ヘッダー フィールドのみを貼り付けます。パスワード、確認コード、メッセージ本文、添付ファイルは決して貼り付けないでください。このツールは、リストされたサーバーに接続したり、ログを検証したり、フィールドが本物であることを証明したりすることはありません。

結果を共有する前に、問題の再現に必要な順序と時間オフセットを維持しながら、個人アドレス、パブリック IP アドレス、キュー ID、および内部ホスト名を置き換えます。 テスト証拠編集ガイドは、より安全な報告パターンを提供します。

信頼できる解釈チェックリスト

上部から開始して最終的な受信システムを特定し、次に下部から上に向かってパスを再構築します。クロックの前にフィールドの順序を信頼してください。タイムゾーンを正規化し、負の間隔または異常に長い間隔にフラグを立てて、信頼できるインフラストラクチャと送信者が制御するインフラストラクチャとの境界をマークします。許可されたサーバー ログが利用可能な場合は、キュー ID を関連付けます。

最も重要なのは、結論の限界を示すことです。トレースは、「受信側プロバイダーが現時点でこのリレーからのこの接続を受け入れた」ことをサポートする場合があります。通常、誰がメッセージを書いたか、以前のすべてのホップが本物かどうか、リンクや添付ファイルが安全かどうかを証明することはできません。