RFC 3461: SMTP配信状態通知拡張

Current Standard Delivery Status & Bounce Handling Obsoletes RFC 1891 Published March 2026

ELI5: 認定郵便を郵便サービスで送付する場合、配達証明を要求することができます。RFC 3461はメールの同等物です。SMTP会話に特別なパラメータを追加することで、送信サーバーが「このメッセージが配信されたか、バウンスしたか、遅延したかを教えてください」と言うことができます。

これが存在する理由

基本的なSMTP（RFC 5321）は、配信が最終的に失敗した場合にバウンスメッセージが生成されることのみを保証しています。しかし送信者はしばしばさらに多くの情報が必要です：

メッセージが受信者のメールボックスに配信されたことの肯定的な確認
メッセージがキューに滞留している場合の遅延通知
選択的なレポート—失敗時のみ、または成功時のみ通知を受ける
送信者が元の送信に関連付けることができるオペイクな識別子を使用したエンベロープレベルのトラッキング

この拡張がない場合、送信者は盲目的です：沈黙は配信成功を意味する場合もあれば、メッセージが失われたことを意味する場合もあります。RFC 3461は、発信元MTAが配信状態通知（DSN）を明示的にリクエストしてそのコンテンツを制御できるようにするSMTPパラメーターを追加します。

仕組み

DSN拡張はSMTP EHLOハンドシェイク中にネゴシエートされます。受信サーバーがDSNをアドバタイズすると、送信者は2つの新しいパラメーターセットを使用できます：

MAIL FROMパラメーター

RET=FULLまたはRET=HDRS — DSNメッセージに元のメッセージ本文全体を含めるか、ヘッダーのみを含めるかを制御します。大きなメッセージの場合はHDRSが推奨されます。
ENVID=value — エンベロープ識別子（最大100文字のxtext形式）。任意のDSNで返され、送信者が通知を元のメッセージと関連付けることができます。

RCPT TOパラメーター

NOTIFY=conditions — カンマ区切りのリスト：SUCCESS、FAILURE、DELAY、または特殊値NEVER。これはDSNが生成される時期を制御します。
ORCPT=type;address — 元の受信者アドレス（エイリアス拡張またはフォワーディング前）。DSNが送信者が実際に意図していたアドレスを報告できるようにします。

SMTPセッション例

EHLO sender.example.com
250-mail.example.org Hello
250-SIZE 52428800
250-DSN
250 STARTTLS

; エンベロープIDを指定してDSNをリクエスト、バウンス時はヘッダーのみを返す
MAIL FROM:<alice@sender.example.com> RET=HDRS ENVID=msg-20260311-0042
250 OK

; 成功または失敗時に通知、元の受信者を保持
RCPT TO:<bob@example.org> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;bob@example.org
250 Accepted

; このアドレスのすべてのDSNを抑止
RCPT TO:<bcc-copy@archive.example.com> NOTIFY=NEVER
250 Accepted

DATA
354 Start mail input
[message content]
.
250 OK

重要な技術詳細

NOTIFYの値

値	DSNが生成される条件
`SUCCESS`	メッセージが受信者のメールボックスに正常に配信された
`FAILURE`	配信が永続的に失敗した（ハードバウンス）
`DELAY`	配信が遅延しているがまだ再試行中
`NEVER`	いかなる状況下においてもDSNなし（他の値と組み合わせることはできません）

NOTIFYが省略されている場合、デフォルトの動作はNOTIFY=FAILUREと同等です—永続的な失敗の場合のみ通知を受けます。

ENVIDエンコーディング

ENVID値はxtextエンコーディングを使用します：印字可能ASCII文字はそのまま通過しますが、+と=（および印字可能ASCII範囲外の文字）は+XXとしてエンコードされます。XXは16進値です。これによってパラメーターはSMTP転送に対して安全に保たれます。

リレー動作

DSNをサポートする中間MTAは、リレー時にDSNパラメーターを伝播する必要があります。中間MTAがDSNをサポートしていない場合、標準SMTPルールに従って適切なバウンスメッセージを生成する必要がありますが、きめ細かなDSN制御は失われます。

一般的な間違い

NEVERを他の値と組み合わせる。 NOTIFY=NEVER,FAILUREは無効です。NEVERは単独で表示される必要があります。
EHLOをチェックせずにDSNパラメーターを使用する。サーバーがDSNをアドバタイズしない場合、これらのパラメーターを含めると構文エラー（コード501）が発生します。
すべてのサーバーからDSNを期待する。DSNサポートはオプションです。多くの大規模メールボックスプロバイダーはこれをアドバタイズしておらず、GmailやOutlookに成功通知を強制できないことを意味します。
大きなメッセージにRET=FULLを使用する。これにより元のメッセージ全体（添付ファイルを含む）がDSNに含まれ、サイズ制限に達するか帯域幅を浪費する可能性があります。
フォワーディング時にORCPTを忘れる。サーバーがエイリアスを展開またはメールをフォワードする場合、ORCPTを省略するとDSNが最終アドレスではなく、送信者が使用したアドレスをレポートしません。

配信可能性への影響

DSNサポートはプロフェッショナルなメール送信のための重要なインフラストラクチャです：

バウンス処理。プログラムによるバウンス処理はDSNに依存して、どの受信者が失敗したか、そしてなぜ失敗したかを識別します。ENVIDパラメーターにより、バウンスを特定のキャンペーンまたはトランザクションに関連付けることができます。
リスト衛生。 NOTIFY=FAILURE（デフォルト）により、無効なアドレスについて学べます。バウンスするアドレスの迅速な削除は、送信者の評判を保護します。
不要なトラフィックの抑止。BCC コピーまたは配信確認が不要なアーカイブアドレスにNOTIFY=NEVERを使用します。
遅延認識。 NOTIFY=DELAYは、配信の問題が永続的な失敗になる前に、すぐに検査する時間を与えてくれます。