一张可用的送达账本，先回答「算的是什么」，再回答「这个比例要不要告警」。
一、旧名单导入之后，先查发送资格和最终状态
韩松把另一个产品两年前的邮箱名单导入当前产品，随后看到硬退与投诉上升。这是教学情境；它提示要检查地址状态、订阅目的与联系意愿，不能仅靠「清洗后没退信」就认定有资格发送营销。
一封邮件可能先有接受事件，之后才退信；回调还可能重复、乱序或迟到。若把所有原始事件直接相加，送达、退信与投诉就会出现重复。账本应保留原始记录，另按投递单位形成截至某一时点的汇总，并允许迟到事件修正。
二、四类观察值，分母与证据分别写清
本例以「逻辑消息 ID + 收件地址」为一个投递单位，重试尝试另记。群发给多个地址时须拆成多个单位；不能用 API 请求数当邮件收件数。
| 指标 | 本例口径 | 观测限制 | 行动依据 |
|---|---|---|---|
| 最终永久退信占比 | 最终归为永久退信的投递单位 ÷ 本批投递单位 | 永久失败可能是地址无效，也可能是策略拒绝 | 看细分原因；地址无效与投诉按规则抑制 |
| 最终临时失败占比 | 重投结束仍未成功的临时失败单位 ÷ 本批投递单位 | 不能把每次暂缓事件都当一次最终失败 | 看服务商是否仍在重投及失败类型 |
| 内部投诉占比 | 已去重、已收到的投诉消息数 ÷ 本例最终服务器接受单位 | 投诉回传覆盖不完整，且口径与平台不同 | 同一来源、时间窗与覆盖内比较 |
| 收件箱投放观察 | 经授权样本中收件箱与垃圾箱的情况 | 普通 delivery 事件看不见全体用户的文件夹 | 样本、用户反馈与接收平台工具交叉核对 |
硬退、软退、投诉与垃圾箱投放不具有统一的「三条行业红线」。内部可以设调查阈值，但必须同时注明收件平台、服务商、时间窗和样本量；不能声称达到某个比例就必然封号，或尚未越线就安全。
Gmail 的用户举报率单独看
Gmail 发信指南 针对个人 Gmail 收件场景，建议其用户举报垃圾邮件率保持低于 0.1%，避免达到 0.3% 或以上。它不是所有服务商共用的投诉公式，也不是对本例月度全量发送的阈值承诺。
Postmaster Tools 仪表板 中的 spam rate 与用户手动举报有关，不能解释为自动落入垃圾箱的比例；不同面板有自己的样本与认证条件。数据可能延迟、低量时可能缺失，空白不等于 0。按日与接收平台分别查看，不能用一个月的平均值掩盖某天异常。
三、5000 个投递单位的完整算例
假定本批状态已归并完成、没有待定单位；下列四类最终状态互斥。投诉作为后续标签，不再次从接受数里扣除。
投递单位 = 5000
最终永久退信 = 150，即 3%
最终临时失败 = 60，即 1.2%
最终服务器接受 = 4790
待定 = 0
状态勾稽 = 150 + 60 + 4790 + 0 = 5000
服务器接受比例 = 4790 ÷ 5000 = 95.8%
已收到并去重的投诉 = 4
内部投诉占比 = 4 ÷ 4790 × 100% = 0.0835%
若再有 1 条投诉且分母暂不变：5 ÷ 4790 × 100% = 0.1044%
这不是 Gmail Postmaster Tools 的用户举报率，也不是垃圾箱率
服务器接受的 4790 个单位是否全部进入收件箱、是否都被用户看到，这张表回答不了。实际如仍有待定单位，单列并说明观测截止时间，不能把它们全计成功，也不能直接用「总量减两种失败」宣布已送达。
150 次永久退信不能推出要删 37 个地址。 每个地址的发送次数不一定相同，也不能用「平均每月四封」做反推。先从退信记录取收件地址去重，再按原因决定抑制；假设其中实际查得 37 个独立无效地址，这个 37 来自记录查询，而不是 150÷4。
一次投诉足以值得调查，不需要等到红线；也不能说「距离封禁只剩一封」。内部可把 0.1% 设为本例的调查阈值，但实际平台处置还取决于其他规则、时间窗与信誉情况。
四、抑制、预热与恢复要按实际原因处理
| 情况 | 处理 | 不要做什么 |
|---|---|---|
| 确认地址不存在 | 停止向该地址继续投递，保留必要的原因与时间 | 每次营销都重新尝试无效地址 |
| 明确投诉或退订 | 按适当范围及时写入抑制，并检查排队任务 | 换子域名、产品或账号绕过选择 |
| 临时错误 | 区分暂缓与最终失败，按服务商状态和重投策略恢复 | 服务商仍在重投时应用又建多份任务 |
| 长期无业务互动 | 按订阅目的、近期行为与收件偏好复查 | 只凭追踪图片没打开就认定地址失效 |
| 新域名、IP 或流量变化 | 按当前限额、接收分布与服务商指引逐步调整 | 把每天 200 封、四周爬坡当成通用许可 |
没有统一的「停发三个月声誉归零」规则，也不能用固定天数证明恢复完成。增加流量时记录退信、举报、延迟与名单来源，异常时停止扩大并检查原因；小规模试发也须具备适当的发送资格。
所谓清洗，通常是从发送集合中排除，而不是无限保留全部旧地址。保留抑制所需的最少标识和依据，限制访问并设复核周期；地址更正或恢复需有核验过程，不能机械「永久删除」后下一次导入又发。
五、黑名单与异常处置
查询域名或 IP 是否被特定 blocklist 收录只是线索；不同接收方采用哪些名单不同，未被收录也不表示邮件一定进收件箱。发现条目后先核对影响、来源与对应名单的说明，处理真实原因，再按其正规流程申请复核。
共享 IP 的问题应联系发信服务商，不能把不属于自己的 IP 当成自己可以管理的资源。不要为了绕过限制而换号、轮换域名或继续向被抑制地址发送；备用服务商同样需要同步抑制与认证。
如果发现凭据泄漏或异常发送，立即止损并回收凭据；普通名单和节奏问题则暂停受影响的非必要批量发送、保留适当的事务服务并验证恢复。是否停某条事务通道取决于它是否也受到安全或地址问题影响，不能把「事务必须继续」理解成无条件向任何地址发送。
行动清单与实操验收
- 明确逻辑消息、单收件投递与每次传输尝试的关系。
- 对回调验签或鉴权、去重并处理乱序；对一次先接受后退信的样本复核最终汇总。
- 每个比例记录分子、分母、时间窗、来源与待定数量。
- 用地址去重和原因分类生成抑制清单，不按平均频次反推地址数。
- 分收件平台观察投诉；Postmaster Tools 缺数据时明确标注缺失。
- 为限流、泄漏与异常退信分别写恢复条件，不用固定预热表代替观察。
验收应能从任一统计值追到投递记录和最终分类，并解释哪些收件箱状态不可见。本文的 5000、4790 与 37 均为教学数据，未执行真实发信、名单清洗或账号申诉。
关键参考与核验范围
核验日期：2026-10-25。
- Amazon SES 通知事件 ：同一投递可能出现多类通知，不保证事件顺序；用于说明为何需要状态归并，其他服务商须另查契约。
- Gmail 发信指南 ：核对适用于个人 Gmail 的发信与举报率要求，不当作全行业封禁阈值。
- Postmaster Tools 仪表板说明 ：核对举报、认证、延迟与低流量数据限制，不当作全体用户垃圾箱计数器。
本文的内部比例与平台定义分别保留。服务商要求变化时按当前文档核对，不能声称「红线量级永远不变」。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。