指南 · Cloudflare DMARC

产品团队应如何安全地实施 Cloudflare DMARC？

在 Cloudflare 中配置 DMARC 的步骤是：盘点所有使用您可见 From 域名发信的服务，在受控邮件上验证 SPF 或 DKIM 对齐，然后在准确的 _dmarc 名称上添加一条 TXT 策略记录。先从报告阶段开始，保留变更前的 DNS 状态，验证权威和递归查询结果，并在请求 quarantine 或 reject 之前审阅汇总报告。Cloudflare 负责托管或分析 DNS 策略；它不会让发件方自动对齐，也不能证明邮件已送达。

将 Cloudflare DNS 与发件方配置分开看待

Cloudflare 可以运营权威 DNS，而由另一家服务商提交并签名应用邮件。在修改任何内容之前，先记录这些职责边界。DNS 区域发布 DMARC TXT 策略；每个邮件服务商控制自己的退信路径（return path）、DKIM 签名域名和选择器、验证流程，有时还控制报告；应用则控制租户、邮件类别、收件人、模板、可见 From 地址和服务商路径。一条有效的 DNS 记录无法修复未经授权的发件方、缺失的 DKIM 签名、未对齐的退信路径或跨租户的 From 值。请按可见 From 域名盘点生产、预发布、客服、账单、身份、监控、CRM、营销以及人工邮件系统。为每个系统指定负责人和回滚联系人，并在提高强制执行级别之前对未知的报告来源进行分类。

查询收件方实际评估的策略名称

对于来自 alerts@notify.example.test 的邮件，应从 _dmarc.notify.example.test 上的 TXT 记录开始。不要误把策略发布到网站主机名、邮件交换器、DKIM 选择器或退信路径名称上。当作者域名没有有效记录时，现行的 DMARC 发现机制可能会选用适用的组织域或公共后缀策略，因此请同时记录查询的名称和最终选中的策略域名。在打开 Cloudflare 之前，先查询现有的权威和递归应答。同一名称下存在多条策略记录、标签语法格式错误或存在冲突的 CNAME，都可能导致结果无法使用。记录旧内容、TTL、解析器输出、负责人以及变更后的预期值，这样回滚就是精确还原，而不是在事故中临时重建。

在 Cloudflare 中创建一条经过审核的 TXT 记录

打开正确的 Cloudflare 账户和区域，进入“DNS Records”，选择“Add record”，然后选择 TXT。对于根域策略，名称使用相对名称 _dmarc；对于目标子域，则使用准确的 _dmarc 标签。输入一个经过审核的值，不要混用不一致的引号；Cloudflare 文档说明，保存时未加引号的新 TXT 内容会被自动加上外层引号。选择与上线和恢复计划相匹配的 TTL，必要时添加不含隐私信息的变更编号，并在核对区域、名称、旧值和新值之后再保存。TXT 策略是 DNS 数据，不是被代理的 Web 路由。如果区域由托管合作伙伴或其他权威服务商管理，请在那里进行变更，而不要默认 Cloudflare 控制台就是权威来源。

基于明确的决策构建 DMARC 值

观察阶段的记录可以从 v=DMARC1; p=none 加上一个经批准的汇总报告 URI 开始，但这只是示例，并非通用值。版本标签要放在最前面，所请求的策略要是有意为之，并且每个报告目标地址都要经过授权。只有在有书面需求并依据现行标准解读时，才审阅子域策略、对齐模式、百分比和报告相关标签。不要照搬包含他人 rua 邮箱的厂商示例，也不要因为语法校验通过就直接跳到 p=reject。一条有效的记录只表达了您请求收件方如何处理邮件；它不能证明 SPF 或 DKIM 验证通过、任一已验证标识符与 From 域名对齐、所有合法发信路径都已盘点，也不能证明任何邮件进入了收件箱。

在真实邮件上验证 SPF 和 DKIM 对齐

从每条应用发信路径向您能查看原始邮件头的收件人发送受控示例邮件。记录可见 From、SMTP MAIL FROM、发送 IP、DKIM d= 域名和选择器、Authentication-Results、服务商标识符、邮件类别、环境和时间。DMARC 可以通过已对齐且验证通过的 SPF，或已对齐且验证有效的 DKIM 签名来通过。SPF 评估的是 SMTP 身份，在转发时可能发生变化；DKIM 验证的是对选定内容的签名。两者都不能替代应用层授权。请有意识地测试宽松或严格对齐，包括子域和故障切换路由。服务商 API 受理、目标服务器接收、DMARC 通过、邮箱中的投放位置和用户互动是不同的观测结果。请将这些状态区分开，避免把一次成功的 API 调用或绿色的策略指示升级为更强的投递证据。

在控制台之外验证 DNS 和报告

保存后，向 Cloudflare 的权威名称服务器和多个独立的递归解析器查询准确 _dmarc 名称上的 TXT 记录。保存原始应答、选中的策略域名、TTL、解析器、时间戳和解析结果。确认只存在一条可用记录、v=DMARC1 位于最前、必需的值有效，且报告 URI 均已获批。在预期的缓存时间窗口过后重复查询。再次发送受控邮件并检查收件方的邮件头。Cloudflare 将 DMARC Management 描述为查看发信来源以及 SPF、DKIM 和 DMARC 汇总结果的工具，但报告是由收件方提供的延迟观测数据，并不是完整的实时统计。请将其与服务商证据相互印证。遇到解析器结果不一致、低频流量缺失、存在未知的合法来源、受控邮件未对齐或报告量出现意外变化时，请暂停推进。

将 Cloudflare DMARC Management 视为一次 DNS 变更

Cloudflare 表示，启用 DMARC Management 时，可能会在记录不存在时提示创建一条记录，或向现有的 rua 标签中添加一个 Cloudflare 汇总报告地址。请像对待生产基础设施一样审阅这项拟议变更：导出原有值，确认现有目标地址仍是有意保留的，核实域名范围，并保留回滚能力。其启用文档还说明了当前仅限根域的适用范围，以及关于外部 SPF 记录的注意事项。不要据此推断该功能可以安全改写托管在别处的 SPF 路径。列表中出现某个来源或 IP，并不能证明是哪个应用、租户或人员授权了它；没有对应的行，也不能证明不存在流量。请将该视图用于收集证据，同时保留权威 DNS、原始邮件、服务商日志和应用审计等证据。

依据分阶段的证据逐步提高强制执行级别

观察期要足够长，以覆盖每个合法发件方、邮件类别、工作日规律、批处理任务、故障切换路由和低频工作流。将来源分类为自有、已批准的供应商、转发、未知或滥用。在请求更严格的处理之前，先修复合法流量的对齐问题。上线决策关卡应包括：DNS 有效、受控邮件通过、已对齐覆盖率可接受、不存在未知的合法来源、事故有明确负责人、客服已做好准备，以及回滚方案经过测试。只能通过有边界、经批准的变更来提高策略级别，并同时监控身份验证失败和业务失败。如果出现合法邮件被拒、报告丢失、意外来源、解析器结果不一致、服务商迁移或子域继承带来的意外情况，请回滚或暂停。尽可能分别修改 SPF、DKIM 和 DMARC，以便清楚地定位回归原因。

避免常见的 Cloudflare DMARC 失败模式

常见的失败包括：修改了错误的区域、发布在错误的 _dmarc 名称上、留下两条策略记录、加入了错误的引号字符、替换了已批准的 rua 列表、误以为根域和子域策略完全相同，以及在低频发件方出现之前就使用 p=reject。另一个错误是把控制台中已保存或已检测到的状态当作邮件级别的证据。请使用精确的差异对比、受控收件人、独立查询、原始邮件头以及按收件人范围记录的事故日志。不要将客户地址、邮件正文、API 密钥和不加限制的报告数据写入工单和分析系统。如果权威应答与缓存应答的不一致持续超出计划时间、某个预期发件方缺失，或某封真实邮件对齐失败，请停止推进，并分别排查委派、缓存、记录语法、发件方清单、SPF 和 DKIM。

SendHQ 的适用场景

安全边界与服务商无关：应用授权邮件，发信服务商对其进行身份验证，Cloudflare 发布或分析 DNS 状态，收件方评估邮件。请依赖 Cloudflare 当前官方文档、当前 DMARC 标准、观测到的 DNS 响应以及受控的接收邮件证据。

常见问题

在 Cloudflare 中，根域 DMARC 策略应放在哪个名称下？

在该区域的 _dmarc 上创建 TXT 记录，解析为 _dmarc.example.com。如果 From 身份使用子域，请针对该作者域名并按照现行发现规则进行评估。

TXT 值需要手动加引号吗？

Cloudflare 表示，保存时未加引号的新 TXT 内容会被自动加上引号。请避免手动添加不一致的引号，然后核对权威原始应答和解析结果。

Cloudflare 会代理 DMARC TXT 记录吗？

这条 TXT 策略不涉及 HTTP 代理设置。请将其发布在权威 DNS 中并从外部进行验证；Web 代理行为是另一项功能。

DMARC Management 会修改记录吗？

Cloudflare 的启用文档说明，它可能会提议添加一条记录或一个 Cloudflare rua 目标地址。请明确审阅、保留、验证并在需要时回滚这项变更。

p=none 会拒收验证失败的邮件吗？

不会。它是以观察为目的的请求策略。在考虑向收件方请求更严格的处理之前，请借助报告和受控邮件盘点并修复合法发件方。

DMARC 通过能证明邮件进入收件箱吗？

不能。它只证明适用的对齐身份验证评估已通过。服务商受理、收件方接收、所在文件夹和用户互动都需要各自范围内的独立证据。

为什么 SPF 通过而 DMARC 失败？

经过验证的 SMTP 身份可能与可见 From 域名不对齐，也可能存在其他评估错误。请检查确切的身份标识和收件方的原始结果。

DMARC 记录能证明邮件服务商集成吗？

不能。仅凭 DMARC 记录不能证明邮件服务商集成。

参考来源

继续学习

如何对应用邮件进行 DMARC 检查检查 DMARC 记录发现、语法、SPF 和 DKIM 对齐、策略、报告以及真实应用邮件，避免把 DNS 查询误当作投递结果。应用邮件的 SPF 记录语法详解了解 SPF v=spf1 语法、机制、限定符、修饰符、DNS 查询次数限制、include 与 redirect 的行为、验证方法以及 DMARC 对齐。如何检查应用邮件的 DKIM通过检查真实签名、查询其选择器和域名、验证邮件、读取收件方结果并测试对齐来检查 DKIM。如何评估邮件送达率服务从范围、证据、身份验证、反馈环、抑制列表、隐私、可迁移性和运营适配度等方面评估邮件送达率服务。