判断框｜适合继续排查： Cloudflare Email Service 的 Delivered 表示收件方邮件服务器接受了邮件，不代表它进入收件箱。先核对 Activity log 中的本次记录，再检查垃圾邮件等文件夹、抑制状态和收件方提供的完整邮件头；不要仅凭 Delivered 就判定测试通过。这个状态定义见 Cloudflare 官方排查说明。
适合使用 Cloudflare Email Service 发送自家产品邮件、日志显示 Delivered 但测试收件箱空白的开发者、QA 工程师和独立开发者。
如果你要排查的是入站路由，或第三方平台的邮件账号问题，本文的发信诊断流程并不适用。
先弄清 Delivered 确认了什么
Cloudflare Email Service 显示 Delivered，是不是代表邮件进了收件箱？
不是。它确认的是收件方邮件服务器通过 SMTP 接受了邮件；之后邮件可能进入收件箱、垃圾邮件或其他文件夹，也可能被收件方的过滤规则处理。Cloudflare 无法从这个状态得知收件方最终把信放在哪里，也无法凭它确认用户已经看到邮件。官方排查文档明确区分了服务器接受和邮箱分类。
排查时要把以下环节分开记录：
- 发送请求被接受：应用或发送接口接受了你的请求，不等于收件服务器已收到。
- 收件方服务器接受：Activity log 显示
Delivered，表示远端服务器回应接受。 - 邮箱分类：由收件方服务的过滤与信誉机制决定，发件侧日志不一定能看到分类结果。
- 用户实际读取：需要在受控收件箱中找到邮件并打开，才能证明测试邮件真实可读。
把后三者混为一谈，会让你追错故障边界：例如把垃圾邮件分类误判为 Cloudflare 发送失败，或把接口请求成功误当作收件验收完成。
按 Activity log 状态锁定故障段
发送日志显示 Delivered，但测试邮件找不到，该从哪里开始？
先打开本次发送事件，而不是只看应用界面上的“发送成功”。Cloudflare 的 Activity log 状态说明列出了发信状态及其含义；同一条记录还可查看收件方服务器响应、发送尝试、时间戳和可用的邮件预览信息。
| Activity log 状态 | 它能说明什么 | 下一步 |
|---|---|---|
Sent |
邮件已被接受并排入发送队列，不等于收件方服务器已接受 | 继续查看该事件是否出现后续投递结果 |
Delivered |
收件方邮件服务器已接受邮件 | 核对地址与文件夹，并向收件方取证 |
Delivery failed |
投递失败，可能伴随退信原因 | 查看退信代码和收件方响应 |
Rejected |
因收件人处于抑制名单，邮件未发送 | 核对对应地址和抑制原因 |
Failed |
发送因配置或认证问题失败 | 检查 Email Sending 设置及相关认证状态 |
表格里的状态不是同一层级的“成功或失败”标签。特别是 Sent 与 Delivered 不可互换：前者表示发送队列接受，后者才表示收件服务器接受。可以在日志里同时核对状态、收件地址和 Message-ID，再用 Message-ID 关联应用日志，避免把同一测试的重发邮件、不同收件地址或旧记录混在一起。
Activity log 可按 30 分钟至 30 天的时间范围筛选，也支持自定义范围；如果测试事件较早，先调整筛选窗口再判断“没有记录”。若已启用邮件预览，日志中还可查看邮件内容与原始头信息；官方说明预览保留约 7 天，所以不要把它当成长期归档。Activity log 文档说明了筛选与预览的使用边界。
地址与文件夹的排除检查
邮件到了垃圾邮件文件夹，怎样定位原因？
先不要改发送配置。对照日志中的完整收件地址，确认你查看的是本次测试实际使用的邮箱，而非主邮箱、旧地址或另一个环境的地址；随后检查垃圾邮件、促销、归档、已删除邮件及邮箱自定义规则。搜索 Message-ID 或主题也能帮助你从文件夹分类中找回邮件，但搜索不到并不能证明收件方服务器没有接受它。
| 核查对象 | 你要找的证据 | 证据不足时的判断 |
|---|---|---|
| 测试地址 | Activity log 收件人和当前登录收件箱地址完全一致 | 先修正地址或测试环境变量 |
| 收件文件夹 | 收件箱、垃圾邮件及其他分类中是否存在该封邮件 | 找到后记录实际分类，不把它记成投递失败 |
| 完整邮件头 | 收件方生成的 Authentication-Results、Received 等字段 |
请收件方导出原始邮件，而不只提供截图 |
| 应用与平台日志 | 同一封邮件的 Message-ID、触发时间和收件人 |
用标识关联记录，避免对错邮件下结论 |
如果你能访问邮件原文，重点记录收件方写入的 Authentication-Results。这个字段用于呈现接收侧做出的邮件认证结果，并可能被过滤系统用于后续处理；它不是发件侧对“进了收件箱”的证明。Gmail 用户可以按其查看完整邮件头的官方步骤打开原始邮件；其他邮箱服务也应使用“查看原文”或“下载原始邮件”一类功能。
抑制状态与认证记录
对照了地址和文件夹后，如果状态是 Rejected，或日志与应用表现不一致，再检查抑制状态。Cloudflare 的抑制名单用于阻止向特定收件人发送邮件；条目可能是账号级，也可能限定在某个发送域名。只在你有权限的自家账号和获授权测试环境中查询，不要把关闭保护或绕过抑制当成通用修复方式。
在控制台的 Email Sending 区域查看 Suppressions，核对目标地址、原因和适用范围；必要时通过官方支持的接口查询。Cloudflare 的抑制管理文档提示，删除条目会允许后续再次尝试发送，因此应先确认地址归属、测试授权和抑制原因。若条目来自投诉或硬退信，直接删除可能让系统再次联系一个已拒收或投诉的地址。
如果记录确认服务器接受了邮件，再核对发信域名的 DNS 认证配置。检查位置应是 Email Sending 对应的设置，而不是把 Email Routing 的入站记录当成发信配置。Cloudflare 域名配置文档分别列出两类配置；发信相关记录包括 cf-bounce 子域上的 SPF、DKIM，以及 _dmarc 记录。认证结果通过是重要证据，但不保证进主收件箱：收件服务仍会按自身过滤和信誉判断分类。Gmail 的发件人指南也说明，认证只是送达要求与指南的一部分，并非收件箱放置承诺。
用受控收件完成测试闭环
选择测试地址时，关键不是它看起来像不像真实邮箱，而是你能否读取邮件、保存必要证据，并确认测试不会污染个人或生产数据。
| 收件方案 | 适合的验证目标 | 主要限制 |
|---|---|---|
| 团队控制的测试邮箱 | 需要查看完整邮件头、长期重复回归或保留审计证据 | 需管理访问权限、测试数据和邮箱清理 |
| 临时收件箱 | 临时注册、单次通知或确认邮件是否可读 | 不适合重要账户找回、长期收信或需要稳定保留原始证据的测试 |
| 转发地址 | 需要把测试邮件送到受控主邮箱，同时隔离公开地址 | 需确认转发链路不会改变你要核查的邮件特征 |
按下面的检查清单闭环，每一步都留下一条可复核证据：
- ✅ 固定测试对象：仅测试自家产品或已获授权的环境；选定一个受控收件地址，确认你能实际访问它。
- ✅ 记录触发信息：保存环境、触发动作、收件地址和时间，避免把不同测试批次混为一谈。
- ✅ 关联发送记录：触发一封可识别的测试邮件，在应用日志与 Activity log 中核对同一地址和
Message-ID。 - ✅ 读取 Activity log 详情：记录状态、收件方响应及可用的认证信息；若为
Delivered，把它记录为“服务器接受”，不要写成“已进收件箱”。 - ✅ 检查收件方位置：搜索收件箱及垃圾邮件等文件夹，找到邮件后记录实际位置，并确认正文、链接和模板渲染可读。
- ✅ 需要时取得原始邮件：让有权限的测试收件人导出完整邮件头，保存
Authentication-Results等接收侧证据。 - ✅ 形成结论：分别记录发送状态、收件方接受证据和邮件实际可读结果；缺少最后一项时，测试尚未完成真实收件验收。
如果你需要判断一次性测试地址是否适合当前验证任务，可先看测试收件地址选择指南。若遇到“发送成功但验证码或邮件没出现”的另一类问题，分层投递排查指南也能帮助你区分发送方限制、地址错误与收件箱检查。临时地址适用于短期、可读取且不承担账户找回责任的测试；银行、支付、政务等重要账户，或需要长期收信、回信和保留完整证据的场景，应使用你长期控制的测试邮箱。
如果你只需为自家产品的一次性注册或通知测试提供一个可打开查看的临时收件入口，Emailbye 的免注册临时收件箱可作为受控测试方案之一；它不能替代 Cloudflare Activity log，也不保证特定邮件必达。先确认当前测试场景允许使用临时地址，再以“邮件是否实际出现并可读”为验收标准，不要把 Delivered 单独当作最终结论。