传递状态通知（DSN）协议：退信背后的标准化机制

普通开发者收到退信后，只能被动查看零散的数字与英文提示，无法精准定位邮件故障的具体链路与根因，难以开展针对性排查。自建邮件系统的运维开发者常会遭遇各服务商退信格式不统一的问题，无法通过程序自动解析投递异常，只能依赖硬写正则适配碎片化返回格式，运维效率极低。

退信为什么需要被标准化？——从 NDR 的混乱现状到 DSN 的设计动机

DSN 出现前，业界无统一退信规范，各 MTA 自主定义 NDR 格式，导致退信信息碎片化、无法机器解析。NDR（未送达报告）是邮件传输的固有功能，只要邮件投递失败，MTA 都会生成通知反馈给发件人，但早期无统一标准，不同厂商、不同版本的 MTA 会使用完全不同的文本描述、返回格式与提示逻辑，不存在统一状态码与固定报文结构。

非标准化 NDR 仅支持人工阅读排查，完全无法适配自动化邮件运维场景。碎片化的退信格式没有统一的错误语义定义，程序无法精准识别临时失败、永久失败、网络异常等故障类型，运维场景中只能依靠脆弱的正则匹配文本关键词，极易出现误判、漏判，无法实现故障统计、自动告警、链路异常定位等程序化能力。

DSN 的核心设计目的是统一退信的格式与语义，将零散的 NDR 能力转化为可互操作、可机器解析的标准化能力。DSN 并未创造全新的退信通知功能，只是对已有 MTA 退信能力进行规范约束，定义统一的 MIME 结构、状态码体系与报文字段，让所有合规 MTA 的投递状态反馈具备一致性。

不支持 DSN 扩展的 MTA 仍可正常生成 NDR，只是会退回厂商自定义的非标准化格式。DSN 是协议扩展规范，而非 MTA 运行刚需，设备不兼容该标准不会丧失退信能力，仅会丢失标准化、可程序化解析的特性，回归碎片化的传统退信形态。

DSN 仅标准化通知格式与语义定义，不强制约束 MTA 的通知生成逻辑。标准解决的是“通知如何统一表达”的问题，无法解决“MTA 是否一定会发送通知”的可靠性问题。部分 MTA 会静默丢弃异常邮件、不生成任何退信报告，这类静默故障无法通过 DSN 机制规避。

DSN 标准化彻底改变了退信的使用属性，将依赖人工经验的主观反馈，转化为可落地的技术契约。标准化前，退信的可读性、准确性完全依赖 MTA 厂商的实现逻辑；标准化后，统一状态码与报文结构成为跨设备、跨网络的通用交互依据，为自动化运维提供核心支撑。

发件人怎么"请求"退信？——SMTP DSN 扩展的机制与边界

根据 RFC 3461 的定义，SMTP DSN 扩展允许客户端在邮件发送阶段主动声明投递状态通知偏好，实现按需获取退信报告。该扩展依托 EHLO 机制生效，MTA 会在 EHLO 响应中声明自身是否支持 DSN 能力，仅兼容该扩展的链路可识别客户端的自定义通知请求。

客户端通过 RCPT TO 命令携带 NOTIFY 参数，精准定义所需的通知场景，支持多条件组合配置。NOTIFY 包含四类核心取值：NEVER 禁止任何场景通知、SUCCESS 投递成功时通知、FAILURE 投递失败时通知、DELAY 投递延迟未终局时通知，可自由组合适配不同运维需求。

RET 参数用于控制 DSN 退信报文的内容体量，直接影响传输与存储开销。RET=FULL 会将完整原始邮件正文嵌入退信报告，RET=HDRS 仅保留邮件信头，极简压缩退信体积，适配高频投递、批量运维场景。

DSN 相关参数仅为客户端偏好声明，并非强制契约，最终通知行为由链路 MTA 策略决定。客户端配置的 NOTIFY 规则不具备强制约束力，沿途任意 MTA 可因不支持扩展、本地安全策略、运维配置等因素，覆盖或忽略客户端的自定义请求。

NOTIFY=NEVER 的优先级低于 MTA 本地强制策略，存在明确的执行边界冲突。当客户端声明禁止所有通知，但 MTA 本地规则要求必须反馈失败日志、合规退信时，服务端策略会优先生效，客户端的偏好设置会被直接覆盖。

链路中任意一跳 MTA 不支持 DSN 扩展，整条链路的自定义通知规则都会失效。未在 EHLO 阶段声明 DSN 能力的 MTA，会直接忽略 NOTIFY、RET 扩展参数，退信行为回归设备默认策略，客户端无法自主干预通知时机与内容格式。

跨公网多跳投递场景下，DSN 自定义通知规则无法全程保真执行，链路断裂是常态现象。公网邮件传输经过多厂商、多版本 MTA 节点串联，只要单一节点不兼容 DSN 扩展，客户端预设的通知逻辑就会中断，无法实现端到端的统一通知效果。

以下为标准 DSN 扩展示意命令，适配失败、延迟双场景通知需求：
# 客户端请求：仅失败/延迟时通知，退信仅返回信头 RCPT TO:<user@example.com> NOTIFY=FAILURE,DELAY RET=HDRS
该命令仅在支持 RFC 3461 扩展的 MTA 链路中生效，非兼容链路会直接丢弃扩展参数，按默认规则生成退信。

退信里那个状态码到底在说什么？——DSN 状态码体系的设计逻辑

根据 RFC 3463 的规范，DSN 采用 class.subject.detail 三段式状态码结构，分层定义投递状态与故障范畴。三段结构各司其职，一级类标识投递结果类型，二级主体定位故障子系统，三级细节精准界定具体异常原因，实现故障的分层精准归类。

DSN 一级 Class 类字段定义投递终局状态，是判断邮件可用性的核心依据。2 代表投递成功、4 代表临时性可重试失败、5 代表永久性不可重试失败，三类状态完整覆盖邮件投递的所有结果形态。

DSN 二级 Subject 主体字段，精准划分故障所属的业务子系统。标准定义多类主体范畴，其中包含 1=未指定异常、2=信箱相关故障、3=邮件系统异常、4=网络传输故障、5=协议交互异常、7=安全校验失败，实现故障场景的标准化归类。

DSN 三级 Detail 细节字段提供具体故障编号，实现异常原因的精细化区分。相同主体范畴下的不同细节编号，对应差异化故障场景，例如 5.1.1 代表收件人邮箱不存在、5.2.2 代表邮箱容量已满，为精准排查提供依据。

DSN 状态码采用传输无关的设计理念，理论上可脱离 SMTP 协议适配多类投递场景。该状态码体系独立于底层传输协议，并非 SMTP 专属，可统一适配 LMTP、HTTP 等各类邮件传输方式，实现多链路投递状态的语义统一。

SMTP 增强状态码与 DSN 状态码属于同源统一体系，并非两套并行标准。SMTP 会话中返回的 3 段式增强码，本质是 DSN 状态码在 SMTP 传输层的具象落地，二者语义、编码规则完全一致，是同一标准的不同应用形态。

传输无关是设计理想，实际状态码可用范围与底层传输协议能力强耦合。协议设计层面实现了传输解耦，但部分轻量化网关、简易传输链路不具备细粒度故障识别能力，无法返回精准 detail 细节码，只能笼统返回通用 4.x.x、5.x.x 状态，丢失精细化故障信息。

DSN 标准仅定义状态码编码空间，不强制 MTA 返回最高精度的故障码，实际粒度依赖设备实现。部分 MTA 为简化逻辑，会将多类同类故障统一归为通用状态码，导致标准化状态码在不同设备中呈现的精细度不一致。

"延迟"和"失败"的边界在哪？——两种 DSN 的触发时机与实际陷阱

失败 DSN 是投递终局通知，由 MTA 判定永久性故障后立即触发，无后续重试动作。当出现收件人不存在、域名解析失败、永久权限拦截等不可逆异常时，MTA 直接终止投递流程，生成 FAILURE 类型 DSN，投递流程彻底结束。

延迟 DSN 是投递中间状态警告，仅代表当前投递未成功，未判定永久失败，MTA 仍会持续重试。邮件处于重试周期内、暂时无法投递，但未触发永久失败条件时，MTA 会主动推送 DELAY 类型通知，仅用于预警，不代表最终投递结果。

两类 DSN 的核心边界是投递终局性：失败 DSN 终止流程，延迟 DSN 仅反馈临时状态。收到延迟 DSN 不代表邮件最终投递失败，后续仍可能重试成功，是运维排查中极易误判的核心点。

延迟 DSN 的触发时机无统一标准阈值，完全由 MTA 本地配置定义，存在明显边界模糊性。协议标准未规定延迟通知的最小触发间隔，不同 MTA 的重试周期、延迟阈值配置差异极大，部分设备短间隔重试会导致延迟通知与失败通知几乎同步触发。

多跳投递链路会出现时序通知矛盾，先后收到延迟 DSN 与成功 DSN 属于正常现象。上游 MTA 触发延迟预警后，下游节点完成正常投递，会导致发件人先收到异常警告、再收到成功通知，程序化处理时必须按最终终局状态为准，忽略中间临时状态。

延迟 DSN 的可用性完全受制于 MTA 本地策略，客户端请求无法强制生效。即便客户端声明 NOTIFY=DELAY，若 MTA 关闭延迟通知功能、或延迟阈值设置过大，发件人将完全收不到中间状态预警，再次印证 DSN 请求仅为偏好声明的核心特性。

NDR 与 DSN 到底是什么关系？——退信的"实现"与"标准"

NDR 是宽泛的功能性概念，所有邮件未送达的反馈通知都可称为 NDR，无格式、无规范约束。只要 MTA 判定投递失败并向发件人推送通知，无论通知形式、内容、结构如何，都属于 NDR 范畴，是邮件系统的基础固有能力。

DSN 是 NDR 的标准化子集，是具备固定 MIME 结构、可机器解析的规范化退信格式。根据标准定义，DSN 采用 multipart/report 结构，固定包含可读文本说明、机器可识别的 delivery-status 状态体、可选原始邮件片段，是结构化、标准化的 NDR 实现形态。

二者的包含关系不可逆：所有 DSN 都是 NDR，但绝大多数传统 NDR 并非合规 DSN。非标准化 NDR 仅包含人工可读文本，无结构化状态字段、无统一状态码，无法被程序精准解析；DSN 在保留人工可读信息的基础上，新增标准化机器解析模块。

两类退信的自动化处理能力存在本质差距，直接决定运维模式的效率上限。非 DSN 格式的传统退信，必须依赖正则匹配、文本语义识别提取故障原因，容错率低、维护成本高；合规 DSN 可直接解析 delivery-status 体部的标准化状态码，实现零人工干预的自动化故障归类、统计、告警。

DSN 标准化是运维需求驱动的优化能力，而非邮件投递的基础刚需。仅人工排查退信的场景中，非标准化 NDR 完全可以满足使用需求；只有在自动化运维、批量故障统计、链路异常监控的场景下，DSN 的标准化价值才成为刚需。

DSN 只规范退信格式与语义，不强制 MTA 的通知生成策略，标准化无法解决静默丢包问题。合规支持 DSN 的 MTA，仍可通过本地策略静默丢弃异常邮件，不生成任何退信报告，格式标准化无法弥补策略层面的可靠性缺失。