在域名基础设施层面，邮件投递的可信度直接取决于 DNS 认证记录的完整性与正确性。Cloudflare Email Routing 作为一款免费的邮件转发服务，其核心价值不仅在于简化邮件地址创建与路由流程，更在于通过与 Cloudflare DNS 的深度集成，为用户提供自动化的 SPF、DKIM、DMARC 记录管理能力。然而，要在生产环境中确保邮件成功投递并避免被标记为垃圾邮件，管理员必须深入理解这三种认证机制的协作原理与配置细节。
SPF 记录：授权发件服务器的第一道防线
发送方策略框架（Sender Policy Framework，SPF）通过在域名 DNS 中发布一条 TXT 记录，声明哪些邮件服务器被授权代表该域名发送邮件。当收件方服务器收到邮件时，会查询发件域名的 SPF 记录并验证实际发件服务器 IP 是否在授权列表中。Cloudflare Email Routing 本身不改变域名的 SPF 策略，但管理员需要确保所有实际发送邮件的来源都被纳入 SPF 记录。
配置 SPF 记录时，记录类型选择 TXT，记录名称使用 @ 或域名本身，记录值遵循 v=spf1 [来源机制] [限定符] 的语法格式。来源机制包括 include 用于引用其他域名的 SPF 记录（如 Google Workspace 的 _spf.google.com）、ip4 或 ip6 用于直接指定 IP 地址段、a 和 mx 用于引用域名解析结果。限定符方面，~all 表示软失败（邮件仍被接收但可能被标记），-all 表示硬失败（邮件可能被拒收），+all 则允许任何服务器发送，安全性最低。生产环境建议先使用 ~all 进行测试验证，确认所有合法发件来源都已纳入后再切换至 -all。
一个典型的多来源域名 SPF 记录可能包含：Google Workspace 的 include 机制、SendGrid 或 Mailgun 等营销邮件平台、Cloudflare 自身的邮件转发服务器，以及直接指定的外发 IP 段。需要注意 SPF 记录存在 10 个查找次数的上限，超出后验证将失败，因此应尽量精简 include 链的深度。
DKIM 签名：加密验证的核心层
域名密钥识别邮件（DomainKeys Identified Mail，DKIM）采用公钥加密技术为邮件内容生成数字签名，收件方通过 DNS 查询获取公钥并验证签名完整性。与 SPF 不同，DKIM 签名由发件服务器动态生成，而非静态记录在 DNS 中。Cloudflare Email Routing 在转发邮件时会保留原始 DKIM 签名，但域名管理员仍需为实际发送邮件的来源配置 DKIM 记录。
DKIM 记录的发布具有提供商特异性。每个邮件服务商会提供专属的选择器（selector）和公钥内容，记录名称格式为 [选择器]._domainkey.yourdomain.com，记录值包含 v=DKIM1; k=rsa; p=公钥内容。在 Cloudflare DNS 面板中发布 DKIM 记录时，必须关闭代理（将橙云切换为灰色），否则 TXT 记录可能被 Cloudflare 拦截导致验证失败。不同服务商可能使用不同的选择器名称，管理员需要分别为每个发送来源创建对应的 DKIM 记录。
DMARC 策略：统一认证框架的落地执行
基于域名的邮件认证报告（Domain-based Message Authentication, Reporting and Conformance，DMARC）在 SPF 和 DKIM 基础上构建了完整的策略框架和报告机制。DMARC 记录同样以 TXT 记录形式发布在 _dmarc.yourdomain.com 域名下，核心参数包括策略（p）、报告 URI（rua、ruf）和失败选项（fo）。
策略参数 p 控制认证失败时的处理方式：none 仅监控不采取行动，适合部署初期；quarantine 将可疑邮件隔离至垃圾邮件文件夹；reject 直接拒收未通过认证的邮件。报告 URI 参数用于接收聚合报告（rua）和失败报告（ruf），聚合报告以 XML 格式每日发送，失败报告则实时推送详细诊断信息。fo 参数控制失败报告的触发条件，0 为默认报告所有失败，1 为报告任一机制失败，d 仅报告 DKIM 失败，s 仅报告 SPF 失败。
实际部署建议采用渐进式策略：首先设置 p=none 并配置报告收集地址，持续观察一到两周的认证对齐情况；确认 SPF 和 DKIM 签名正确工作后，升级至 p=quarantine；最终在完全验证通过后切换至 p=reject 实现最强保护。
工程实践中的关键参数与监控要点
在 Cloudflare 环境中配置邮件路由认证时，有几个工程实践细节值得关注。首先，所有 DKIM 和 DMARC 的 TXT 记录必须保持为 DNS only 状态，不可经过 Cloudflare 代理，这直接关系到验证机制的正常运作。其次，DNS 变更的传播延迟通常在数分钟至 48 小时不等，建议使用 dig 命令或在线验证工具逐条确认记录已正确发布。
对于使用 Cloudflare Email Routing 进行邮件转发的场景，管理员还应关注转发链条的认证一致性。当邮件从发件人发送至 Cloudflare 再转发至目标邮箱时，如果转发过程中的某跳未正确配置 SPF 或 DKIM，可能导致 DMARC 对齐失败。Cloudflare 本身提供了钓鱼检测机制来过滤恶意邮件，但最终的对齐验证仍依赖于域名自身的认证配置完整性。
监控层面，建议配置专门的邮箱地址接收 DMARC 聚合报告，定期分析报告数据以发现潜在的配置问题或未授权发件行为。报告中的 "pass" 与 "fail" 比例、对齐失败的具体原因（如 SPF 和 DKIM 都不通过、仅 DKIM 失败等）都是重要的运维指标。
资料来源：本文配置参数参考自 PowerDMARC 的 Cloudflare DMARC/SPF/DKIM 配置指南及 Cloudflare 官方 DNS 记录文档。