Return-Path

概要

Return-Path は、メールの配送エラー（バウンス）通知を受信するアドレスを指定するヘッダーフィールドです。RFC 5321 で定義されており、SMTP セッションの MAIL FROM コマンドで渡されたエンベロープ From アドレスが、受信側の MTA によって Return-Path: ヘッダーとして付加されます。

Return-Path とエンベロープ From は同じアドレスを指しますが、登場する箇所が異なります。SMTP 送信時の MAIL FROM がエンベロープ From であり、受信後にメールヘッダーとして記録されるのが Return-Path です。メールクライアントの「生のメール（Show Original / View Source）」で Return-Path: を確認できます。

バウンスメール（配送不能通知）はこのアドレスに返送されるため、Return-Path の設定は配信管理の基盤です。SaaS のメール配信サービスを使う場合、Return-Path がサービス側のドメインになることがあり、SPF アライメントに影響します。

仕組み

Return-Path は SMTP の Mail From と受信後のヘッダーという 2 つの側面を持つフィールドで、バウンス通知の経路を制御します。

sequenceDiagram
    participant S as 送信サーバー
    participant R as 受信サーバー
    participant B as Return-Path 宛先

    S->>R: MAIL FROM:<bounces@example.com>
    S->>R: DATA（From: newsletter@example.com）
    alt 配送成功
        Note over R: Return-Path: bounces@example.com<br/>をヘッダーに付加
        R-->>S: 250 OK
    else 配送失敗
        R->>B: バウンス通知（NDR）
    end

SMTP セッションでの流れ

メール送信の SMTP セッションでは、MAIL FROM コマンドで送信元アドレスを宣言します。

S: 220 mail.example.net ESMTP
C: EHLO sender.example.com
S: 250-mail.example.net
C: MAIL FROM:<bounces@example.com>
S: 250 OK
C: RCPT TO:<user@example.net>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: newsletter@example.com
C: Subject: Monthly Update
C:
C: Hello, ...
C: .
S: 250 OK

MAIL FROM:<bounces@example.com> がエンベロープ From です。受信側の MTA はこのアドレスを Return-Path: ヘッダーとして受信メールに付加します。

Return-Path: <bounces@example.com>
Received: from sender.example.com (...)
Delivered-To: user@example.net
From: newsletter@example.com
Subject: Monthly Update

MAIL FROM と From: ヘッダーが異なるドメインでも、SMTP 仕様上は問題ありません。この分離が SPF と DMARC のアライメント問題の根本にあります。

バウンス通知の経路

メールが配送不能だった場合、受信側の MTA は Return-Path アドレス宛にバウンス通知を送信します。ハードバウンス（存在しないアドレス）でもソフトバウンス（一時的なサーバー障害）でも、通知は Return-Path に届きます。

From: Mail Delivery Subsystem <MAILER-DAEMON@example.net>
To: bounces@example.com
Subject: Delivery Status Notification (Failure)

Return-Path が空アドレス（MAIL FROM:<>）の場合、バウンス通知は送信されません。これはバウンス通知自体が再バウンスを引き起こすのを防ぐための仕組みです。

SaaS 利用時の Return-Path

SendGrid、Amazon SES、Mailgun などのメール配信サービスを使う場合、Return-Path はサービス側のドメインに設定されることがあります。

Return-Path: <bounces+abc123@sg.example.com>

この場合、SPF の検証対象は sg.example.com のドメインになり、ヘッダー From（@example.com）とは異なるドメインに対する SPF チェックになります。DMARC の relaxed アライメントでは、Envelope From とヘッダー From が同じ組織ドメインであれば pass しますが、ドメインが全く異なる場合は SPF アライメントが fail します。

カスタム Return-Path を設定すると、自社ドメイン配下にエンベロープ From を揃えられます。

Return-Path: <bounces@mail.example.com>

DKIM アライメントが pass していれば DMARC は通過するため、カスタム Return-Path を設定しなくても DKIM がカバーできます。しかし SPF アライメントも通過させる場合は、カスタム Return-Path の設定が必要です。

設定例

Return-Path に関連する DNS レコードと、SaaS 利用時のカスタム Return-Path の設定例を示します。

基本的な SPF レコード

Return-Path のドメインに対して SPF レコードを設定します。

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

カスタム Return-Path の設定

SendGrid でカスタム Return-Path を使う場合の DNS 設定です。

; カスタム Return-Path ドメインの SPF レコード
mail.example.com.  IN  TXT  "v=spf1 include:sendgrid.net ~all"

; カスタム Return-Path ドメインの CNAME
bounces.mail.example.com.  IN  CNAME  sendgrid.net.

この設定により、Return-Path が bounces@mail.example.com となり、SPF アライメントが relaxed モードで pass します。

バウンス処理専用の Return-Path

バウンスメールの処理を自動化する場合、Return-Path をバウンス処理専用のアドレスに設定します。

Return-Path: <bounces@example.com>

bounces@example.com 宛に届いたバウンス通知をパースし、ハードバウンスのアドレスを配信リストから自動除外する仕組みを構築します。

確認方法

受け取ったメールの Return-Path を確認するには、メールのヘッダー情報を表示します。

Gmail では「その他」→「メッセージのソースを表示」から確認できます。

Return-Path: <bounces+abc123@mail.example.com>

送信ドメインの 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:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "mode": "auto",
      "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true }
      ],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1"],
      "exhaustive": false
    },
    "dmarc": { "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com", "exists": true, "source": "exact", "domain": "example.com" },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

data.spf.record に SPF レコードの内容が返ります。Return-Path のドメインがヘッダー From と異なる場合は、Return-Path のドメインを domain= に指定して SPF レコードを確認します。

よくある問題

Return-Path に関するトラブルは、バウンス処理の放置、SPF アライメントの不一致、空アドレスの誤用に集約されます。

バウンス通知を誰も確認していない

Return-Path を no-reply@example.com に設定している場合、配送エラーの通知がそのアドレスに届きます。受信ボックスを誰も監視していないと、ハードバウンスのアドレスへの送信が継続され、送信ドメインのレピュテーションが低下します。バウンス処理専用のアドレスを Return-Path に設定し、ハードバウンスのアドレスを自動で配信リストから除外する仕組みを導入します。

Return-Path とヘッダー From のドメインが不一致で SPF アライメントが fail になる

SaaS のメール配信サービスを使うと、Return-Path がサービス側のドメイン（@sg.example.com 等）になることがあります。この場合、SPF は pass しても DMARC の SPF アライメントが fail になります。DKIM アライメントで DMARC を通過させるか、カスタム Return-Path を設定して自社ドメイン配下に揃えます。

Return-Path を空アドレスにして通知を失う

バウンス通知を送信したくない場合に MAIL FROM:<> を使うと、送信側でバウンスの状況を一切把握できなくなります。一斉送信メールのバウンス率を監視できないため、配信品質の低下に気づけません。バウンス通知を受け取る専用のアドレスを Return-Path に設定し、バウンス情報を活用します。

Return-Path のドメインに SPF レコードがない

Return-Path のドメインに SPF レコードが設定されていないと、SPF チェックが none になります。DMARC は SPF が none の場合、SPF アライメントを fail として扱います。Return-Path のドメインに対しても SPF レコードを設定します。