Return-Pathとは
Return-Pathは、配送失敗通知などの返送先を示すメールヘッダーで、通常は配送過程で付加されます。一般に「リターン・パス」と読み、RFC 5322ではReceivedとともにtrace field（トレース・フィールド）に分類されます。
値の元になるのは、SMTPのMAIL FROMで受け取ったエンベロープFromです。最終配送を行うサーバーが、その逆方向経路をメッセージ上部へ記録して保存側へ渡します。
Return-Pathは著者が本文と一緒に書くプロフィール欄ではありません。最終配送時のSMTP返送先を、受信後に調査できる形へした記録です。
配送中の値と、保存後に見える記録を分ける
送信側がSMTPトランザクションで提示し、失敗通知の返送経路にする
接続元IPが逆方向経路ドメインを使う許可をDNS規則で評価する
既存の偽装値を除き、受け取った逆方向経路からReturn-Pathを作る
メールボックスへ保存後、診断や認証結果の確認に使えるトレース情報になる
配送状態通知などで逆方向経路が空なら、山括弧の中も空になる
配信管理用トークンや内部ドメインが含まれる場合は必要部分だけ残す
最終配送サーバーが付ける理由
送信者がReturn-Pathを自由に付けられると、実際のSMTP返送先と異なる値を表示できます。そのためSMTPは、最終配送時に受け取った逆方向経路からReturn-Pathを挿入することを定めています。
中継サーバーがまだ次へ転送する段階では、最終的なReturn-Pathを確定しません。メッセージが別の配送環境へ再投稿されれば、その新しいSMTP封筒に基づく記録へ変わり得ます。
空の山括弧は、壊れたアドレスではない
配送状態通知は、それ自体が配送できなかったときに二重の返送を作らないよう、空の逆方向経路を使います。最終配送後のReturn-Pathも空の山括弧になります。
これは送信元不明やヘッダー欠落ではなく、バウンスループ防止の正規動作です。空値を一般のメールアドレス検証へ渡さず、配送状態として扱います。
From、Reply-To、Senderとは目的が違う
ヘッダーFromは著者、Senderは実際の送信担当、Reply-Toは通常の返信を希望する宛先です。Return-Pathは配送エラーの返送先記録で、受信者が返信する宛先ではありません。
ニュース配信では、Fromを人が認識する窓口、Reply-Toを問い合わせ先、Return-Pathを受信者別バウンス処理用にできます。異なること自体は不正ではなく、各ドメインの認証と運用を確認します。
SPF結果と対応させて読む
SPFは受信時の逆方向経路ドメインを主な検査対象にします。受信後のReturn-Pathは、その値を調査する手掛かりになりますが、転送・再投稿・ゲートウェイを通ると評価境界が変わります。
Authentication-Resultsに記録されたsmtp.mailfromとReturn-Pathを対応させ、どの受信サーバーがどの接続元IPを評価したかを確認します。Return-Path文字列だけを別の場所でSPF再評価しません。
転送や配信サービスでは、元のFromと異なるのが一般的である
転送サービスはSPFを維持するため逆方向経路を書き換えることがあります。配信サービスは失敗した受信者を特定するため、受信者別トークンをローカルパートへ含めることがあります。
このためReturn-Pathが外部サービスのドメインでも、直ちに偽装とは言えません。DMARCの整合、DKIM署名、契約している配信経路、Receivedをまとめて確認します。
生ヘッダーを共有するときは個別情報を除く
Return-Pathにはメールアドレス、顧客識別トークン、配信キャンペーン、内部サーバー名を推測できる情報が含まれます。Message-IDやReceivedのIPと組み合わせると追跡範囲が広がります。
調査目的に必要なドメイン、認証結果、時刻、応答だけを残し、ローカルパートと個別トークンを一貫した置換値へ伏せると、対応関係を保ったまま共有できます。
trace fieldの確認資料：RFC 5321「SMTP」、RFC 5322「Internet Message Format」、RFC 7208「SPF」