指南 · Cloudflare 邮件路由

产品团队应如何安全地实施 Cloudflare 邮件路由？

实施 Cloudflare 邮件路由的步骤是：接入一个使用 Cloudflare DNS 的域名，审阅 MX 和身份验证记录，验证每一个转发目标地址，并且一次只创建一条明确的路由。只有在转发规则无法满足需求时才使用 Worker。在 Worker 中，要把邮件头和 MIME 内容视为不可信输入，限制解析和存储的规模，为每封邮件选定唯一一个明确的处理结果，并记录尽量少含隐私信息的路由证据。使用一个无关的发件人进行测试，监控失败情况，并在启用 catch-all 流量之前准备好禁用和回滚流程。

明确入站任务和责任边界

首先写清楚入站任务的具体内容：哪个域名和哪些本地部分应当接收邮件，每个目标地址归谁负责，邮件应当被转发、交给代码处理还是丢弃，以及运维证据可以保留多久。Cloudflare Email Routing 是一个入站路由层。它本身不会创建支持工单，不会确立发件人身份，不能证明转发的邮件已被人看到，也不保证邮件在目标邮箱中进入收件箱。请把这些后续的应用状态分开处理。为 DNS、路由规则、Worker 代码、目标地址验证、安全事件和回滚分别指定运维负责人。在首次上线时，请使用 support@ 或 invoices@ 这类专用别名，而不是 catch-all。范围较窄的路由可以减少意外收集的邮件，让测试结果易于解读，并限制目标地址配置错误或 Worker 分支出错带来的影响。

接入域名时，不要把 DNS 当作可以盲目执行的安装步骤

Cloudflare 现行的 Email Service 文档规定，使用 Email Routing 的域名必须使用 Cloudflare DNS。接入流程可能会添加用于入站路由的 MX 记录，以及产品文档中描述的 SPF 和 DKIM 相关 TXT 记录。在应用之前，请审阅拟议的具体记录。首先盘点现有的 MX、SPF、DKIM、DMARC、邮箱、转发服务、验证令牌和子域名委派。替换 MX 记录会改变新的入站 SMTP 会话的去向，因此请协调一个维护窗口，并把原有的值保存为回滚记录。不要在同一个所有者名称上创建多条 SPF TXT 记录。变更完成后，查询权威解析器和公共解析器，然后从一个与目标地址无关的账户测试投递。DNS 传播时间的估计并不能证明每个发件方现在看到的都是同一个应答，控制台显示绿色也不能证明端到端的转发已经生效。

在创建生效的路由之前先验证目标地址

Cloudflare 的文档将目标地址描述为账户级资源，必须先完成验证，路由规则才能使用它们。验证步骤是一道重要的防滥用边界：它证明了当时对该邮箱的控制权，但并不能确立长期的业务授权或正确的团队归属。请在您自己的系统中记录申请人、用途、验证日期和复核日期。优先使用由团队控制的目标地址，而不是员工的个人地址。及时移除已离职用户的目标地址，并在删除前检查哪些规则依赖该地址，因为 Cloudflare 的文档说明，删除目标地址会停用使用它的路由。验证邮件属于安全敏感信息，切勿自动点击其中的链接，也不要把它们转发给不可信的自动化流程。对于生产环境的变更，即使控制台允许单个操作员保存规则，也应在您常规的基础设施流程中要求第二人复核。

创建明确的规则并理解优先级

一条路由规则把一个邮件地址模式与一个已验证的目标地址或一个 Worker 配对。Cloudflare 的文档列出了三种操作：发送到邮箱、发送到 Worker 以及丢弃。请先创建最具体的本地部分路由，在变更记录中注明负责人，并确认每个模式只有一条预期的规则。文档警告，如果多条规则使用同一个模式，只有排在最前面的规则会处理收到的邮件。不要把界面上的排列顺序当作非正式的业务规则，而应当消除这种歧义。丢弃规则必须有充分且范围很窄的理由，因为删除本身就意味着有意不投递。只有在逐一评估了隐私、垃圾邮件量、拼写错误和存储方面的后果之后，才启用 catch-all。catch-all 可能会收集到没人打算创建的地址，因此它应该有专门的目标地址或 Worker 策略、告警以及快速禁用的途径，而不是悄悄地沿用某个个人邮箱。

有意识地使用子地址

Cloudflare 的文档介绍了可选的加号地址功能，与 RFC 5233 一致。启用后，发往 user+detail@example.com 这类地址的邮件可以匹配基础地址 user@example.com 的规则，同时在提供给 Worker 和日志的邮件收件人中保留 detail 部分。这可以用于路由标签、测试标识符或按工作流区分的别名，但 detail 部分是由发件人控制的文本。不要把它当作经过验证的租户身份、授权依据或机密信息。在将其用作数据库键、指标维度或队列名称之前，请先进行规范化并限制其长度。Cloudflare 的文档还说明，针对完整子地址的明确规则优先于基础规则。请同时测试明确规则和回退两种情况，以免之后新增的具体规则悄悄改变现有的工作流。不要在加号标签中放入个人或机密数据，因为它们可能出现在邮件头、日志、转发的邮件、支持数据导出和分析数据中。

只有在确实需要处理邮件时才选择 Worker

如果需求只是把一个地址转发到一个已验证的邮箱，请使用直接转发。当您需要受控的分支、邮件检查、存储、拒收、回复或多路转发时，再路由到 Worker。Cloudflare 的邮件处理程序会提供信封发件人和收件人、邮件头、原始 MIME 流及其大小，以及转发、回复和拒收的方法。让处理程序保持精简：先校验收件人策略，强制执行邮件大小和解析的上限，尽可能通过有时限的队列发起外部调用，并为每一种错误定义处理结果。邮件头、主题、显示名称、附件、链接和 MIME 边界都可能被攻击者控制。默认情况下不要记录原始正文或完整地址。如果必须存储内容，请加密存储，按租户和任务限制访问，定义删除策略，并在同步路由路径之外扫描附件。解析异常绝不能落入意料之外的转发或回复分支。

实现一条明确的决策路径

安全的处理程序应当先计算出一个获准的操作，再执行任何副作用。例如，把确切的信封收件人映射到一个已配置的工作流，拒收未知收件人，将一条有大小上限的元数据记录放入队列，然后只转发到从配置中选出的已验证目标地址。绝不要从邮件头、主题、加号标签或正文中读取目标地址。在转发到多个目标地址时，Cloudflare 的限制文档说明，Worker 必须针对每个已验证的目标地址分别调用一次 forward；请决定部分成功是否可以接受，并分别记录每一次尝试。在日志中使用稳定的内部关联标识符，而不是收件人内容。如果处理程序可能会回复，请遵循 Cloudflare 现行的回复限制，并加入防循环保护。自动回复并不代表人工团队已确认收到。如果需要可靠的应用端受理，请在发送自动回复之前先存储工单或事件，并对结果不明确的失败进行核对，而不是承诺工作已经创建。

将转发和回复视为有证据范围的结果

Worker 方法调用成功，只能证明平台层面的操作成功，而不是最终的用户结果。SMTP 定义的是系统之间的传输，之后的过滤、转发、隔离、邮箱规则和人工阅读都不在这一跳的范围内。请分别为以下状态建模：Cloudflare 已接收、Worker 已调用、已尝试操作、目标服务器已受理、已延迟或失败，以及应用记录已创建。不要把它们统统标记为已送达。保留结构化且尽量少含隐私信息的日志，包括规则标识、Worker 版本、操作、时间戳、关联标识符和粗粒度的结果；只有在有书面记录的运维需要时，才存储完整地址或内容。针对调用失败、因大小被拒、catch-all 流量异常、重复出现的发件人模式、目标地址失败以及流量突变设置告警。持续抽样发送受控的测试邮件，但绝不要用真实的客户内容作为可观测性的测试数据。

遵守平台当前的限制并了解其故障模式

Cloudflare 当前文档列出的 Email Routing 限制包括：每个域名 200 条路由规则、每个账户 200 个目标地址、入站邮件大小上限 25 MiB，以及经由 Worker 路由的邮件适用标准的 Workers CPU 和内存限制。请把这些视为服务商当前的文档说明，而不是永久不变的常量。在规划阶段阅读实时的限制页面，并在接近上限之前尽早告警。如果解码时不够谨慎，大型 MIME 邮件即使低于平台的原始大小上限，也可能耗尽内存或 CPU。请以流式方式处理或拒收不必要的内容，限制附件数量，并将开销大的解析放到有上限的异步任务中。根据 Cloudflare 的路由文档，重命名 Worker 可能会破坏其路由绑定，因此请在部署验证中包含路由检查。失败的调用应当在 Workers 日志中可见，但日志本身并不能实现重放。请决定发件方是否应当通过 SMTP 重试、操作员能否安全地重放某个应用任务，以及如何防止在下游产生重复记录。

把上线和回滚当作同一个变更来测试

先创建一条预发布或低风险的路由。从与已验证目标地址不同的账户发送受控邮件，覆盖纯文本、多部分内容、预期的附件、加号地址、未知的本地部分，以及在安全范围内故意构造的畸形输入。验证 DNS 应答、控制台配置、Worker 版本、转发结果、下游记录和隐私行为。然后测试异常路径：未验证的目标地址、已禁用的规则、Worker 异常、超大邮件、重复投递，以及本应落入 catch-all 的规则。为每个阶段记录预期的证据。在扩大流量之前，演练禁用规则、在必要时恢复原有 MX 记录、解除 Worker 绑定，以及就延迟或被拒的邮件进行沟通。一旦出现无法解释的路由丢失、跨租户暴露、内容泄露、意外回复、无上限的存储或持续的 Worker 失败，立即回滚。保留配置快照和测试结果，但邮件内容的保留时间不要超过必要期限。

SendHQ 的适用场景

SendHQ 支持入站邮件。本指南介绍 Cloudflare Email Routing；请遵循各服务自身的文档进行设置并了解其限制。

常见问题

Cloudflare 邮件路由是否要求使用 Cloudflare DNS？

Cloudflare 现行的 Email Service 路由指南规定，该域名必须使用 Cloudflare DNS。在接入之前，请审阅拟议的 MX 和 TXT 变更，并保存用于回滚的原值。

路由规则可以转发到任意邮件地址吗？

不能直接转发。Cloudflare 的文档说明，必须先添加并验证目标地址，路由规则才能向其转发。

什么情况下应使用 Email Worker，而不是直接转发？

对于“一个模式对应一个邮箱”的简单路由，使用直接转发。只有在需要有上限的处理（例如分支、检查、拒收、回复、存储或转发到多个已验证目标地址）时，才使用 Worker。

转发成功是否能证明邮件已进入收件箱？

不能。它只是有限范围内的传输证据。目标服务器如何处理、垃圾邮件过滤、邮箱规则、最终所在的文件夹以及是否被人阅读，都是彼此独立的结果。

应该立即启用 catch-all 路由吗？

通常不应该。先从明确的本地部分开始，衡量流量和失败情况，然后只有在制定了专门的隐私、防滥用、存储、告警和回滚策略后，才启用 catch-all。

加号地址中的 detail 部分能否作为可信的用户或租户标识符？

不能。加号后的 detail 部分由发件人控制。请对其进行规范化并限制长度，绝不要把它用作身份验证、授权依据或机密信息。

SendHQ 支持入站邮件吗？

可以。SendHQ 支持入站邮件。本指南介绍 Cloudflare Email Routing；请遵循各服务自身的文档进行设置并了解其限制。

参考来源

继续学习

SMTP 邮件协议：应用邮件是如何传递的了解 SMTP 提交、中继、信封、响应码、TLS、重试和邮件内容如何塑造应用的邮件工作流。如何评估邮件送达率服务从服务范围、证据、身份验证、反馈环、抑制列表、隐私、可迁移性和运维适配度等方面评估邮件送达率服务。如何评估 SMTP 中继服务从提交安全、身份验证、队列、重试行为、限制、投递事件、抑制列表、隔离性和迁移适配度等方面评估 SMTP 中继服务。面向产品团队的邮件 API 实施指南设计安全的邮件 API 集成：已验证域名、队列化发送、稳定标识符、受控重试、投递事件、抑制列表和租户隔离。如何对应用邮件进行 DMARC 检查检查 DMARC 记录发现、语法、SPF 与 DKIM 对齐、策略、报告以及真实的应用邮件，不要把一次 DNS 查询当成投递结果。