Source: https://once-email.com/ja/blog/read-received-headers 配信と認証 · 2026年8月3日更新日 2026年8月9日 # 受信したヘッダーを読み取り、電子メールの配信パスを追跡する方法 Received ヘッダー フィールドを正しい順序で追跡し、タイムスタンプを安全に比較し、ホスト名、IP アドレス、および信頼できないトレース データの制限を認識します。 [Once Email 編集部, Once Email author Once Email 編集部]() レビュー Once Email 日本語編集レビュー このガイドでできること 読者は、タイムスタンプ付きの配信パスを構築し、考えられる遅延ポイントを特定し、ホスト名、アドレス、非同期クロックの制限を記述することができます。 記事ガイド この記事を読む価値 **独自分析** トレース方法は、信頼できる受信境界からホップを逆方向に読み取り、観察されたリレーの証拠を、信頼できない送信者が捏造した可能性のある回線から分離します。 **トレンドの背景** クラウド リレー、フィルタリング ゲートウェイ、プライバシー プロキシによりホップと書き換えが追加されますが、独自のトレースを先頭に追加する各信頼できる受信者は依然として有用なアンカーです。 **実用的な価値** 読者は、タイムスタンプ付きの配信パスを構築し、考えられる遅延ポイントを特定し、ホスト名、アドレス、非同期クロックの制限を記述することができます。 電子メールは、受信トレイに到達する前に、アプリケーション サーバー、送信リレー、フィルタリング サービス、および受信者のメール エクスチェンジャを通過します。通常、各受信 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 ; 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 を関連付けます。 最も重要なのは、結論の限界を示すことです。トレースは、「受信側プロバイダーが現時点でこのリレーからのこの接続を受け入れた」ことをサポートする場合があります。通常、誰がメッセージを書いたか、以前のすべてのホップが本物かどうか、リンクや添付ファイルが安全かどうかを証明することはできません。 ## 関連ガイド 確認メールが届かない？安全なトラブルシューティングのチェックリスト コードを繰り返し要求したり、アカウントのセキュリティを弱めたりすることなく、アドレスの間違い、送信者の遅延、再試行、フィルタリング、メールボックスの制限に対処できます。 [確認メールが届かない？安全なトラブルシューティングのチェックリスト]() 電子メールヘッダーの SPF、DKIM、および DMARC の結果を読み取る方法 SPF、DKIM、および DMARC が何を認証するのか、なぜ位置合わせが重要なのか、なぜ合格結果がメッセージが安全であることの証明ではなく有用な証拠であるのかを理解します。 [電子メールヘッダーの SPF、DKIM、および DMARC の結果を読み取る方法]() Postfix と Dovecot の違い：受信メールサーバーの役割と切り分け Postfix、Dovecot、LMTP、キュー、IMAP の境界を理解し、証拠から受信障害の層を判断します。 [Postfix と Dovecot の違い：受信メールサーバーの役割と切り分け]() ## プライバシーを優先したメールツール メールヘッダー分析 配送経路と SPF、DKIM、DMARC の証拠を説明し、絶対的な真正性は断定しません。 [メールヘッダー分析]() [一部の Web サイトが使い捨てメール アドレスを拒否する理由 使い捨て電子メール制限の背後にあるアカウント回復、悪用、サポート、リスクの理由と、正当なユーザーが制限を回避する代わりに何をすべきかを理解します。]() [電子メールの添付ファイルをダウンロードする前の安全なチェックリスト 添付ファイルをダウンロードする前に、リクエスト、送信者、ファイル名、タイプ、処理環境を確認し、電子メールのプレビューやスキャナーでは証明できない内容を把握してください。]()