Amazon SES硬反弹率图表0%~0.02%波动噪声原因及解决方法

你观察到的数学逻辑矛盾是成立的：按单日150封的峰值发送量计算，单封硬反弹对应的反弹率确实在0.6%以上，不可能出现0.02%的率值，这个波动完全是SES统计口径和控制台渲染逻辑产生的噪声，没有实际业务风险，具体成因如下：

波动产生的核心原因 #

• 反弹率计算用滑动窗口总发送量做分母，不是单时间片发送量：SES控制台展示的账号级反弹率，默认以过去14天的全量有效发送作为统计分母，和折线图展示的小时/分钟级细粒度时间片没有对应关系。如果你的账号在14天滑动窗口内累计发送量达到5000封，单封硬反弹对应的率值正好是0.02%，和你看到的波动值完全匹配。
• 共享IP池的权重分摊尾差：如果使用SES默认共享IP池，统计管线会按各账号在IP池内的发送量占比，分摊整个IP池的公共反弹事件权重，这类分摊值通常远小于1，不会对应你账号实际发出的邮件反弹，只会在聚合率值上带出万分之几的尾差，且这类分摊值不会计入账号健康度考核。
• 控制台图表的插值渲染噪声：细粒度折线图在两个相邻的真实统计点之间会做线性平滑插值，哪怕两个点的真实值都是0%，受浮点计算精度影响，插值路径上也会出现0.01%~0.02%的非零值，不属于真实的反弹事件统计结果。
• 异步回执补算的临时值：跨ISP的延迟反弹回执、软/硬反弹的状态校正会在事件发生后数天内异步回写到统计管线，回写过程中会出现短暂的非整数反弹当量，等数据对齐后就会回落，不会长期留存。

对应处理方案 #

• 这个级别的波动可以直接忽略：SES触发账号审查甚至封禁的硬反弹率阈值是持续高于5%，你看到的数值比阈值低两个数量级，完全碰不到告警线，没必要特意清洗收件人列表或者调整发信逻辑。
• 如果需要精确统计自身业务的真实反弹率，不要依赖控制台的聚合率值，配置SES的SNS事件推送，把原始的发送、反弹回执落到自己的日志系统里，按实际发生的单封事件计算即可，这部分原始回执数据是100%准确的。
• 如果觉得控制台折线的波动干扰判断，可以把统计维度切换为「累计视图」，或者直接看「硬反弹总数量」指标，只要没有非零的计数，就说明你的账号没有产生真实的硬反弹。

SES Bounce Chart
Number of sends

内容的提问来源于stack exchange，提问作者Dan K