2026 Cloudflare Email Service 测试邮件被抑制？按场景排查。

先分清请求被拒，还是邮件没有进收件箱

“收不到”不是单一故障。应用可能没有触发发送；发送请求可能被抑制规则拒绝；也可能请求已接受、邮件已交给收件方服务器，但最终进入垃圾邮件或其他文件夹。若把这几种结果混成一个问题，改 DNS、换收件箱或删抑制项都可能是在处理错误的环节。

Cloudflare 的 Activity log 把发送事件区分为 Sent、Delivered、Rejected、Delivery failed 和 Failed。其中 Rejected 表示收件人命中抑制列表；Delivered 表示收件方邮件服务器已接受邮件，不等于收件箱里可见。日志还会列出投递尝试、收件方服务器响应和退信信息。(Activity log 状态与字段说明)

发送请求因抑制规则被拒时，先检查什么？
若应用日志确认发送代码已执行，但 REST API 返回 400、Workers binding 抛出 E_RECIPIENT_SUPPRESSED，或 SMTP 明确拒绝，就要检查该收件地址是否命中抑制记录。官方还说明：当 Drop suppressed recipients 关闭时，任一收件人受抑制都可能导致请求失败；开启后会剔除受抑制收件人并继续处理其余地址。若 SMTP 的收件人全部被剔除，可能返回 250 2.0.0 Ok，但没有 Message-ID，也没有实际投递。接受响应不能单独证明邮件已发出。这些发送行为及错误信息以官方抑制列表说明为准。

排查时先保存请求时间、发送方式、收件地址和响应原文，再到 Activity log 找同一封邮件。日志里的 Rejected 是抑制线索；Failed 更偏向配置或认证问题；若状态为 Delivered，应转查收件端文件夹与原始邮件头，而不是先改抑制列表。不要把 REST、SMTP 和 Workers binding 的错误表现当成完全相同的响应格式。

按抑制范围定位记录

判断时看记录的 scope，不要只看收件地址和 reason。账户级记录覆盖账户内所有发送域名及其子域名；sending_domain 记录只匹配记录中的精确发送域名。比如 mail.example.com 与 example.com 是不同匹配值，父域名和子域名不会自动互相覆盖。

Cloudflare Email Service 在 2026 年 9 月 25 日的变更记录中正式说明这两种范围，并指出退信和投诉会按发送域名范围创建抑制项；若 Cloudflare 无法识别原邮件的发送域名，投诉记录则可能使用账户范围。因此，sending_domain suppression 不是“某个邮箱在所有域名都被封”的同义词。上述范围和变更日期见前述官方变更记录及抑制列表说明。

区分 account 和 sending_domain 时，分别核对哪些对象？
先确认记录属于哪个账户，再查看 scope 与 scope.value。account 记录会影响该账户内所有发送域名；sending_domain 记录只对指定发送域名生效，不会因为域名存在父子关系就自动覆盖另一个域名。

如何从实际请求确认所用发件域名？
不要只看应用配置里的显示名称。REST API 和 Workers binding 按 From 地址的域名判定；SMTP 则按 envelope MAIL FROM 地址的域名判定。把这项值与抑制记录的 scope.value 逐字对照，特别留意子域名、环境变量和 SMTP 信封发件地址是否与预期一致。具体判定方式可查官方抑制规则文档。

从记录到复测的排查时间线

按下面顺序操作，能避免一边改配置、一边丢失判断依据。

1. 固定本次发送上下文。 记录环境（开发、预发或测试）、触发动作、发送方式、收件地址、请求时间，以及应用拿到的原始响应。测试自家产品即可，不要用这种流程去批量注册第三方平台账户。
2. 检查发送端结果。 在 Activity log 搜索相应事件，记录状态及可用的错误细节。若查不到事件，先确认应用是否发起请求、请求是否发往预期账户；没有事件不能直接证明是抑制问题。
3. 查询该收件地址的抑制记录。 在控制台打开 Email Sending 的 Suppressions，或使用有相应权限的 API。列表可以按 email 查地址，也可以用 scope_type 和 scope_value 限定发送域名；账户级记录则需单独核对。控制台和 API 的查询方式见官方抑制管理文档。
4. 逐项核对证据。 对照 reason、scope、read_only 和 expires_at。read_only 才是能否修改记录的依据，不能只凭 reason 猜测。特别确认 sending_domain 值是否与本次邮件的实际发件域名完全一致。
5. 先判断记录来源和收件授权。 手工抑制可能来自产品退订决定；自动记录可能源于投诉、硬退信或软退信。若地址曾报告垃圾邮件，或地址、域名不可用，不要为了测试绿灯而立即解除。先核实地址归属、测试授权和故障原因。
6. 只在条件成立时调整并复测。 有权限、收件目标仍适合接收测试邮件，而且原因已查清时，才调整可变更的测试记录；否则改用另一个由团队控制且获授权的测试地址。重新触发一封与本次测试关联的自家产品邮件。
7. 分别验收发送端和收件端。 保存新的日志状态与响应，再从受控收件端确认邮件是否实际可读。若显示 Delivered 但看不到邮件，检查垃圾邮件文件夹和邮件原始信息。官方排查步骤同样要求区分发送状态与收件端实际情况，详见发送故障排查文档。

退信、投诉与可变更状态要分开判断

自动抑制记录并非都能按同一种方式清理。官方列出的 reason 包括 manual、complaint、hard_bounce、soft_bounce 和 policy；其中 read_only: true 表示客户端不能更新或删除该项，应按官方建议进一步调查，而不是换 API 方法反复尝试。API 字段和操作权限见官方抑制记录 API 文档。

手工测试记录可以在确认目标地址仍有效、仍获授权后评估是否删除；投诉记录不应仅为测试而解除，先确认收件人已经重新选择订阅。硬退信要先查地址或域名是否真实可用；软退信则可能是临时收件端问题。部分退信记录有到期时间，部分没有；具体以当前条目的 expires_at 和 read_only 为准，不能从错误类型自行推定可删除或何时自动恢复。

抑制列表中有测试地址时，是否应直接删除并重试？
只有在确认记录可变更、地址归属清楚、目标仍适合接收测试邮件且已有权限时，才考虑删除人工测试记录。对于退信或投诉，先修复地址或确认重新授权；若 read_only 为 true，不要绕过限制。删除操作允许后续投递尝试，但它既不是地址有效性的证明，也不是投递成功的证据。操作前应依据当前控制台与 API 文档确认记录状态。

用三张核对表完成判断与验收

表一：先按发送结果选排查路径

发送响应和日志字段请以对应发送方式及当前 Cloudflare 文档为准。该服务说明在剔除受抑制收件人后，如果没有剩余收件人，SMTP 可能返回成功响应但不生成 Message-ID。

表二：按 scope 核实影响范围

表三：按 reason 和状态决定下一步

若满足以下条件，才在原地址复测；否则回退到受控地址：

• ✅ 记录对应的 Cloudflare 账户、收件地址和本次发送方式均已确认。
• ✅ scope 与本次实际发件域名匹配，或已排除账户级记录。
• ✅ 收件地址仍可用、由团队控制，并获准接收这类测试邮件。
• ✅ 若需调整记录，read_only 和权限允许该操作，且原因已查明。
• ❌ 若涉及投诉、地址不存在、收件授权不明或只读记录，先停止原地址重试，改查原因或使用另一受控地址。

每次验收建议留下四类证据：本次实际使用的发件域名、抑制记录的 scope 与 reason、发送端响应或日志状态、收件端能否实际读取邮件。这样才能明确测试证明的是“请求已发起”“请求被接受”“收件服务器已接收”还是“受控收件箱中确实可读”。它们不是同一个验收结果，也不能互相替代。

如果排查后只需要一个临时、受控的收件目标来验证自家产品邮件，Tenminbox 的临时收件箱可以作为复测方案之一；先确认邮件发送行为符合授权和测试要求，再以收件端实际可读作为验收依据。若还要追踪测试地址与垃圾邮件线索之间的关系，可参考如何核查垃圾邮件来源。使用临时地址不意味着 Cloudflare 一定接受该收件地址，也不保证邮件必达；重要账户、需要长期找回或需要持续回信的测试，应使用团队长期控制的地址。