缺失信号不等于已送达

缺失信号属于故障路径，而非软成功。当没有 DLR 返回、Webhook 未送达、消费者超时或导出单元格为空时，产品和财务部门必须将静默视为“未知”或“失败”，绝不能标记为“已送达”。将静默行提升为绿色或已结算的成功状态，等同于虚构管道从未发送过的证明。

IOSOR 是白标预付费平台。20 美元的试点资金用于强制暴露缺失结果；而在接近 1,000 美元/月的软评审中，虚假的“已送达”状态会造成严重误导。本页面旨在强调静默与超时的诚实性——这不同于内容过滤(已发送不是收件箱)以及 DLR 失败后的重试策略(预付费下 DLR 失败重试策略)。相关阅读：产品与财务的共享状态语言、同一账本上的扣款行与送达状态、在呼叫人工介入前设置心跳与烟雾测试门禁。

缺失信号不等于已送达证明

没有 DLR、没有签名的 Webhook、没有关联加入且没有导出时间戳，意味着“缺失”，而不是“已送达”。没有投诉并不代表送达。在收到最终确认词或指定负责人书面关闭该行之前，请优先使用“未知”或“缺失”。

超时必须保持为未知或失败

在没有可靠结果的情况下，截止日期过后，该行必须保持“未知”或按政策转为“失败”，绝不能为了清空队列而标记为“已送达”。超时是客观事实：消费者挂起、签名丢失、上游静默或延迟超过连接窗口。接近 1,000 美元/月的软评审并不代表可以放弃诚实。覆盖状态需要负责人、理由和新的烟雾测试，而不是一个安静的绿色芯片。

UI 和账本必须对缺失达成一致

产品芯片和预付费账本行必须对静默使用统一的词汇。如果 UI 显示已送达而财务部门仍显示未知，月末对账将失败。将缺失映射到开放对账或终端失败，绝不能自动结算为成功。可关联的结果需要持久的 Webhook 和相同的扣款行——参见 同一账本上的扣款行与送达状态 和 产品与财务的共享状态语言。

缺失与过滤及重试的区别

内容过滤是另一种失败：网络可能接受发送，但收件箱从未显示——参考过滤指南中的“已发送≠收件箱”。重试在“失败”的 DLR 之后开始，并决定是否再次尝试消耗预付费。缺失开始得更早：尚未有可靠的终端结果。不要借用过滤或重试宏来掩盖静默。保持分页在心跳和烟雾测试之后(在呼叫人工介入前设置心跳与烟雾测试门禁)。

缺失信号买家核对清单

1. 在没有 DLR 或 Webhook 时，UI 和账本是否拒绝显示“已送达”？
2. 超时是否保持为“未知”或“失败”，绝不自动成功？
3. “未知/缺失”是否是与财务部门共享的一级词汇？
4. 过滤和重试指南是否为独立页面，而非本页？
5. 支持人员是否能粘贴与导出匹配的静默原因？
6. 20 美元的试点是否会在 1,000 美元/月的软评审前强制暴露缺失行？

任何“否”都会让虚假的“已送达”远离生产环境。

从 IOSOR 开始

请审查您的下发控制台与回调监听器，确保缺失的回执状态默认归类为未知或处理中，而不是自动将派发标记为已送达。请核实预付费账目冻结状态保持有效，直至收到已签名的终态事件或明确的超时策略将记录转换为失败。在数据管道中设置严格的关联窗口阈值，让未确认的消息行触发对账挂起，而不是过早清理队列。

IOSOR 要点

在没有明确回执或已签名回调的情况下，绝不能将未确认的派发尝试标记为已送达。无响应代表未确定的网络状态或上游丢弃，这需要财务账目与系统界面在收到验证通过的终态字眼之前，针对缺失或开放状态保持同步。

务必执行严格的超时策略，将无响应的记录转换为未知或失败状态。切勿为了清理运营积压或在月末对账期间虚增送达指标而自动结算待处理的消息队列。