エンベロープFromとは

エンベロープFromを読むときの前提

エンベロープFrom（Envelope From）は、SMTP配送で戻り先として使われる送信者情報です。メール画面に表示されるHeader Fromとは別で、配送エラーの戻り先やSPF評価の対象になることがあります。

実務では、Return-Path、MAIL FROM、送信サービスのバウンスドメイン、SPF対象ドメイン、Header From、DMARCアライメント、転送時の書き換えを合わせて確認します。

証跡には、対象メールのHeader From、Return-Path、Authentication-Results、Received、送信サービス設定、バウンス内容、確認時刻を残します。

SPF評価の対象を確認する

SPFは、利用者が見ているFromヘッダーではなく、SMTP配送上のエンベロープFromやHELO側のドメインを基準に評価されます。From表示だけを見てSPF対象を判断すると誤ります。

外部メール配信サービスでは、Return-Pathがサービス側ドメインになることがあります。独自バウンスドメインを設定しないと、SPFはpassしてもHeader Fromと揃わず、DMARCで失敗する場合があります。

• Return-PathとMAIL FROMのドメインを確認する。
• SPF TXTがどのドメインで評価されるか見る。
• Header Fromとのalignmentを確認する。

バウンス処理と配送ログを見る

エンベロープFromは、配送できなかったときのバウンス戻り先として使われます。バウンスがどこへ返るかは、利用者に見えるFromとは違うことがあります。

配送調査では、バウンスメール、SMTPステータス、MTAログ、Message-ID、送信サービスのイベントログを同じメールで突合します。バウンスが届かない場合は、エンベロープFrom側のドメインや受信先も確認します。

• バウンス戻り先と処理先を確認する。
• SMTPステータスとMessage-IDを保存する。
• 送信サービス側のイベントログと突合する。

転送と委託送信で変わる点を見る

メール転送やメーリングリストでは、エンベロープFromが書き換わることがあります。これは転送先からのバウンス処理やSPF失敗回避のために行われることがあります。

委託送信では、SPFがサービス側ドメインでpassし、DKIMで自社ドメインをalignmentさせる構成もあります。SPFとDKIMのどちらでDMARCを通す設計かを分けて確認します。

• 転送前後のReturn-Pathを比較する。
• 委託送信SaaSのバウンスドメイン設定を確認する。
• SPF/DKIMどちらでDMARC passするか記録する。

変更証跡と引き継ぎ

エンベロープFrom関連の変更では、旧Return-Path、新Return-Path、SPF TXT、送信サービス設定、バウンス処理先、テストメールヘッダー、戻し条件を残します。

引き継ぎでは、メール基盤管理者、DNS管理者、SaaS所有者、関連語としてHeader From、SPF、DMARCアライメント、バウンスメールを残すと確認しやすくなります。

• Return-Path変更とSPF変更を同じ記録へ残す。
• テストメールのAuthentication-Resultsを保存する。
• バウンス処理先と監視担当を明記する。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能