エンベロープ From（Envelope From）
概要
エンベロープ From（Envelope From） は、SMTP 通信の MAIL FROM コマンドで渡される送信元アドレスです。Return-Path とも呼ばれ、RFC 5321 で定義されています。受信サーバーは SPF の検証にこのアドレスのドメインを使います。メールクライアント（Gmail、Outlook 等）に表示される「From」欄とは別のフィールドで、通常エンドユーザーには見えません。
この「見えない From」と「見える From」の分離が、メール認証の複雑さの根本にあります。SPF が pass していても、エンドユーザーが見るヘッダー From のドメインを検証しているわけではない点を理解しておく必要があります。
仕組み
SMTP によるメール送信は、封筒（Envelope）と手紙本文（Message）に分かれています。
- 送信クライアントが
EHLOで接続する MAIL FROM: <sender@example.com>で送信元（Envelope From）を宣言するRCPT TO: <recipient@example.net>で宛先（Envelope To）を宣言するDATAコマンドでFrom:,To:,Subject:等のヘッダーと本文を送信する- SMTP 接続が終了する
受信サーバーは手順 2 の MAIL FROM ドメインに対して SPF のチェックを行います。手順 4 で送信した From: ヘッダー（ヘッダー From）は、SPF の検証対象ではありません。
Return-Path との関係
Envelope From は受信後に Return-Path: ヘッダーとして保存されます。メールクライアントの「生のメール（Show Original / View Source）」で確認できます。バウンスメール（配送不能通知）はこの Return-Path アドレスへ返送されます。そのため Envelope From を「バウンスアドレス」と呼ぶこともあります。
SaaS 経由でのメール送信
SendGrid、Mailchimp、HubSpot などのメール配信サービスを使う場合、Envelope From のドメインをサービス側のドメインに設定することがあります。例えば SendGrid 経由で送ると、Envelope From が bounces.sendgrid.net になることがあります。この状態で SPF は sendgrid.net のレコードに対してチェックされます。
ヘッダー From は自社ドメイン（@example.com）のままです。DMARC はヘッダー From とのアライメントを確認するため、Envelope From のドメインがヘッダー From と異なる場合、SPF アライメントは fail になります。この場合、DKIM アライメントで補完します。
設定例
エンベロープ From のドメインに対する SPF レコード設定と、SaaS 利用時のカスタムドメイン返信パスの構成例を示します。
基本的な SPF レコード
Envelope From のドメインが SPF レコードを持つ側のドメインです。
example.com. IN TXT "v=spf1 include:sendgrid.net ~all"ただし SendGrid 経由で送る場合、実際の Envelope From は bounces.sendgrid.net のサブドメインになります。この場合、sendgrid.net の SPF レコードが参照されます。カスタムドメインを使った返信パスの設定（SendGrid では「Reverse DNS」や「Inbound Parse」）を行うと、自社ドメインを Envelope From として使えます。
カスタムドメインの返信パス
mail.example.com. IN TXT "v=spf1 include:sendgrid.net ~all"この場合の Envelope From は bounces@mail.example.com のような形になり、SPF アライメントが mail.example.com ← example.com のサブドメインとして relaxed モードで pass します。
確認方法
受け取ったメールの Envelope From（Return-Path）を確認するには、メールのヘッダー情報を表示します。Gmail では「その他のオプション」→「メッセージのソースを表示」から確認できます。
Return-Path: <bounces+abc123@mail.example.com>送信側の Envelope From ドメインに SPF レコードが設定されているかは dig で確認できます。
dig TXT mail.example.com;; ANSWER SECTION:
mail.example.com. 3600 IN TXT "v=spf1 include:sendgrid.net ~all"外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:sendgrid.net ~all",
"exists": true
},
"dkim": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": { "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com", "exists": true },
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.spf.record フィールドに SPF レコードの内容が返ります。data.spf.exists が true であれば外部から SPF レコードが確認できる状態です。Envelope From のドメインが異なる場合は、そのドメインを domain= に指定します。
よくある問題
エンベロープ From に関するトラブルは、ヘッダー From とのドメイン不一致、バウンス処理先の放置、SPF 設定先ドメインの取り違えに集約されます。
Envelope From とヘッダー From のドメインが一致しないことに気づかない
SaaS のメール送信サービスを導入した直後によくある状態です。メールは届いているため問題に気づきにくいですが、DMARC のアライメントが SPF で fail しています。rua レポートで spf=fail が増えていたら、Envelope From のドメインを確認します。
DKIM アライメントが pass していれば DMARC は通過しますが、SPF だけに依存している場合はアライメントエラーで DMARC fail になります。SaaS ごとに提供されているカスタムドメイン設定を行い、Envelope From を自社ドメイン配下に揃えるか、DKIM を設定します。
バウンス処理先を見落とす
Envelope From はバウンスメールの返送先です。no-reply@example.com を Envelope From にすると、配送エラーの通知がそのアドレスに届きます。受信ボックスを誰も見ていない場合、ハードバウンス（存在しないアドレス）への送信を続けてしまい、送信ドメインの評判が下がります。バウンス処理専用のアドレスを Envelope From に設定し、ハードバウンスのアドレスをリストから削除する仕組みを整えます。
SPF レコードのドメインを間違える
Envelope From のドメインではなく、ヘッダー From のドメインだけに SPF レコードを設定しているケースがあります。SPF は Envelope From のドメインを検証するため、ヘッダー From のドメインに SPF を設定しても SPF 検証には使われません。送信経路を確認して、実際に MAIL FROM で使われているドメインを特定します。