概述

发件方常需要确认"邮件到底送到了没有、对方读没读"。传统机制里，DSN（投递状态通知，RFC 3461）由中转返回、MDN（处置通知，RFC 3798）由收件方返回，但都依赖邮件头注入且易被篡改、易丢失。RFC 9208 引入 DELIVRTO URI Scheme：发件方在邮件中嵌入一个唯一回调地址，收件系统处理后向该地址回传结构化状态，形成更可信的送达证明。

机制要点

DELIVRTO 是一个带令牌的 URI，例如 deliverto://example.com/status?token=abc123。发件方把它放进邮件（通常经 MSA 注入），收件方 MTA/MDA 在投递成功或用户打开时，向该 URI 发起 HTTPS 回调，上报状态（投递、延迟、读取）。令牌保证只有原始发件方系统能解读状态，避免伪造。

与 DSN/MDN 的互补

机制	发起方	可信度	适用
DSN (RFC 3461)	中转 MTA	中（可丢）	投递失败/延迟
MDN (RFC 3798)	收件 MUA	低（可关）	用户已读/处置
DELIVRTO (RFC 9208)	收件系统回调	高（令牌+HTTPS）	结构化状态回填

隐私与滥用考量

RFC 9208 明确 DELIVRTO 不得用于隐蔽追踪用户：回调内容应最小化，且收件方有权拒绝回传（尤其读取状态涉隐私）。这与 Apple Mail Privacy Protection 的理念一致——打开追踪本身已不可靠。DELIVRTO 更适合同一组织内或对等信任域间的投递确认。

对信创邮件与政企的启示

在信创邮件系统与 Exchange 互通或跨域公文流转中，DELIVRTO 可作为"已送达"的强证据，用于合规审计与 SLA 考核；但必须配套隐私开关，且令牌短期有效。它补充而非替代 DSN/MDN，构成多层投递可观测性。