RFC 3464: 配信ステータス通知フォーマット
ELI5: パッケージが配達できない場合、運送業者はその理由を説明するフォームを提供します。RFC 3464は、メッセージがバウンスしたり、遅延したり、正常に配達されたりした時にメールサーバーが記入する標準化されたフォームを定義します。ソフトウェアが自動的に読み取れるように構造化されています。
これが存在する理由
DSNフォーマットが標準化される前、すべてのメールサーバーは独自の自由形式のテキスト形式でバウンスメッセージを生成していました。これらの「バウンスメッセージ」を解析するには、脆弱なヒューリスティック(サーバーが言葉を変更するたびに壊れる正規表現)が必要でした。RFC 3464は、自動バウンス処理を信頼できるものにする機械可読MIMEコンテンツタイプ(message/delivery-status)を定義しています。
このRFCは、RFC 3461(SMTPレベルでDSNをリクエストする方法を定義)およびRFC 3462(DSNをラップするmultipart/reportコンテナを定義)と一緒に機能します。
仕組み
DSNメッセージは、report-type=delivery-statusのmultipart/report MIMEメッセージです。最大3つのMIMEパートが含まれます:
-
人間が読める説明(
text/plain)— 人間向けの自由形式テキスト。 -
機械が読める状態(
message/delivery-status)— このRFCで定義された構造化データ。 -
元のメッセージ(
message/rfc822またはtext/rfc822-headers)— 完全な元のメッセージまたはそのヘッダーのみ(RFC 3461のRETパラメータによって異なります)。
delivery-statusボディ
message/delivery-statusパートには、空行で区切られたヘッダーのようなフィールドのグループが含まれます:
; メッセージごとのフィールド(1つのグループ) Reporting-MTA: dns; mail.example.org Original-Envelope-Id: msg-20260311-0042 Arrival-Date: Wed, 11 Mar 2026 10:30:00 -0500 ; 受信者ごとのフィールド(受信者1人につき1つのグループ) Original-Recipient: rfc822;bob@example.org Final-Recipient: rfc822;bob@example.org Action: failed Status: 5.1.1 Diagnostic-Code: smtp; 550 5.1.1 User unknown Last-Attempt-Date: Wed, 11 Mar 2026 10:30:05 -0500
主な技術仕様
メッセージごとのフィールド
| フィールド | 必須 | 説明 |
|---|---|---|
Reporting-MTA |
はい | このDSNを生成したMTA(DNSホスト名) |
Original-Envelope-Id |
いいえ | 元のSMTPトランザクションからのENVID(RFC 3461) |
DSN-Gateway |
いいえ | DSNが外部メールシステムから変換された場合に表示 |
Received-From-MTA |
いいえ | メッセージをReporting-MTAに渡したMTA |
Arrival-Date |
いいえ | 元のメッセージがReporting-MTAに到着した時刻 |
受信者ごとのフィールド
| フィールド | 必須 | 説明 |
|---|---|---|
Final-Recipient |
はい | MTAが実際に配信を試みた受信者アドレス |
Original-Recipient |
いいえ | SMTPセッションからのORCPT値— 送信者が使用したアドレス |
Action |
はい | 次のいずれか:failed、delayed、delivered、relayed、expanded
|
Status |
はい | RFC 3463に基づく拡張ステータスコード(例:5.1.1) |
Diagnostic-Code |
いいえ | リモートサーバーからの実際のエラー文字列、タイプが先頭に付加(通常はsmtp) |
Remote-MTA |
いいえ | エラーを返したMTA |
Last-Attempt-Date |
いいえ | 最後の配信試行が行われた時刻 |
Will-Retry-Until |
いいえ | delayedアクションの場合、MTAが諦める時期 |
アクション値
| アクション | 意味 |
|---|---|
failed |
永続的な失敗— メッセージは配信されません(ハードバウンス) |
delayed |
一時的な失敗— 再試行中(ソフトバウンス) |
delivered |
受信者のメールボックスへの配信成功 |
relayed |
さらなるDSNを生成しない可能性のある環境に転送 |
expanded |
複数の受信者に拡張されたメーリングリストまたはエイリアスに配信 |
完全なDSNメッセージ例
From: mailer-daemon@mail.example.org To: alice@sender.example.com Subject: Delivery Status Notification (Failure) MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="DSN-BOUNDARY-001" --DSN-BOUNDARY-001 Content-Type: text/plain Your message to bob@example.org could not be delivered. The recipient's mailbox does not exist. --DSN-BOUNDARY-001 Content-Type: message/delivery-status Reporting-MTA: dns; mail.example.org Original-Envelope-Id: msg-20260311-0042 Arrival-Date: Wed, 11 Mar 2026 10:30:00 -0500 Final-Recipient: rfc822;bob@example.org Action: failed Status: 5.1.1 Diagnostic-Code: smtp; 550 5.1.1 User unknown --DSN-BOUNDARY-001 Content-Type: text/rfc822-headers From: alice@sender.example.com To: bob@example.org Subject: Meeting tomorrow Message-ID: <abc123@sender.example.com> --DSN-BOUNDARY-001--
一般的な誤り
-
人間が読める部分のみを解析する。
text/plainセクションは人間向けです。自動化されたシステムは、安定した定義された構造を持つmessage/delivery-statusパートを解析する必要があります。 -
ステータスコードのクラスを無視する。 最初の数字が重要です:
2.x.x= 成功、4.x.x= 一時的な失敗(後で再試行)、5.x.x= 永続的な失敗(試行を中止)。すべてのバウンスを同じに扱うと評判が損なわれます。 -
Original-Envelope-Idを照合しない。 RFC 3461で
ENVIDを設定した場合、Original-Envelope-Idを使用して特定の送信にDSNを相関させます。Final-Recipientのみに依存すると、エイリアスまたは転送が関与している場合に失敗します。 -
Final-RecipientとOriginal-Recipientを混同する。 転送後、
Final-Recipientは完全に異なるアドレスになる可能性があります。常にOriginal-Recipientが利用可能な場合はそれを確認してください。 -
relayedをdeliveredとして扱う。relayedアクションは、メッセージがDSN対応環境を離れたことを意味します。最終的なステータスを取得できない可能性があります。
配信可能性の影響
-
自動バウンス分類。
StatusフィールドはRFC 3463拡張ステータスコードにマップされます。コード5.1.1(ユーザーが見つかりません)はアドレスを削除することを意味し、4.2.2(メールボックスが満杯)は後で再試行することを意味します。正しい分類はリストの衛生の基礎です。 -
フィードバックループの相関。
Original-Envelope-Idにより、バウンスを特定のキャンペーン、APIコール、またはトランザクションに結び付けることができます— デバッグと分析に不可欠です。 -
ハードバウンスとソフトバウンスの処理。
Action: failedと5.x.xステータスを永続的として扱う— アドレスを抑制します。Action: delayedと4.x.xを一時的として扱う— バックオフで再試行しますが、繰り返される失敗の後は抑制します。 - 評判保護。 DSNを迅速に処理し、無効なアドレスを削除すると、デッドメールボックスに繰り返し当たるのを防ぎます。これはメールボックスプロバイダーが否定的な評判信号として追跡するものです。