如何在 Cloudflare 中设置 SPF、DKIM 和 DMARC

如果您正在尝试学习如何在Cloudflare中设置SPF、DKIM和DMARC，请从一个简单的事实开始：Cloudflare存储DNS记录，但您的邮件提供商提供值。这听起来微不足道，但并非如此。

Cloudflare是记录存放的地方，这意味着您将在其DNS面板中编辑TXT或CNAME条目。实际的SPF包含字符串、DKIM选择器、公钥和DMARC策略来自发送您邮件的服务，无论是Google Workspace、Microsoft 365、SendGrid、Mailgun还是其他平台。没有这些值，您就是在猜测。

1. 确认Cloudflare在邮件认证中能做什么和不能做什么

Cloudflare并不创造SPF、DKIM或DMARC值。它只是发布这些值。如果您的提供商说要为SPF添加TXT记录，Cloudflare可以托管它。如果提供商给您一个DKIM选择器和一个CNAME目标，Cloudflare也可以托管它。但它无法决定哪些服务器可以为您发送邮件。

这很重要，因为人们通常首先打开Cloudflare并寻找一个魔法按钮。实际上并没有。您需要在接触DNS之前从发送方获取确切的记录内容，否则您可能会发布一个在仪表板检查中通过但在真实邮箱中失败的记录。

2. 从您的邮件发送平台收集DNS值

在您编辑任何内容之前，从提供商的文档中收集三样东西。首先，收集SPF包含机制和服务希望在您的SPF记录中包含的任何IP地址。其次，收集DKIM选择器名称和公钥数据，或者如果提供商使用基于CNAME的DKIM，则收集CNAME目标。第三，收集DMARC策略字符串，包括您计划开始使用的策略和任何报告标签。

将这些值写在一个地方。使用确切的选择器名称。如果您的提供商给您两个选择器，请不要因为它们看起来杂乱而重命名它们。如果文档说记录应该是`_spf.example.net`，就保持这样。微小的格式错误会导致漫长的下午。

这里有一个有用的习惯：在登录Cloudflare之前，将发送者名称、主机名、记录类型和目标字符串捕获在一个表格中。这使得编辑阶段更快，也防止了将正确值粘贴到错误名称字段的常见错误。

3. 在Cloudflare DNS中添加SPF记录

在Cloudflare中，打开DNS并在域的根目录创建或编辑TXT记录，如果您的提供商从裸域发送邮件。有些服务使用子域，例如`mail.example.com`，因此请使用提供商指定的主机名，而不是您假设的主机名。一个主机名。一个记录。

一个主机名通常应该只存在一个SPF记录。这是人们常常忽视的要点。如果您已经有一个SPF TXT记录，请不要在旁边创建第二个SPF TXT记录。将授权发送者合并为一个字符串，以便接收服务器看到一个策略，而不是两个相互竞争的答案。

一个典型的SPF值包括`include:`或`ip4:`等机制。如果您的服务稍后添加第二个发送者，请更新现有记录，而不是添加另一个。重复的SPF记录可能会导致permerror，这意味着接收系统可能会将检查视为失败，即使各个部分看起来正确。

使用您的提供商给您的记录名称。对于根域名，Cloudflare通常将`@`显示为名称字段。对于子域名，请输入该确切标签。除非您的提供商明确告诉您这样做，否则请不要在值周围添加引号。Cloudflare将文本存储为普通DNS内容。

4. 在Cloudflare中发布DKIM TXT或CNAME记录

DKIM 的选择器很重要。提供商可能会给你一个 TXT 记录，比如 `selector1._domainkey`，并附带一个长的公钥，或者它可能会给你一个指向另一个主机名的 CNAME 记录。Cloudflare 支持这两种方式，但类型必须与提供商所说的匹配。CNAME 字段中的 TXT 值不会对你有帮助。

许多服务使用两个选择器。这是正常的。Google Workspace 在轮换期间通常使用两个密钥，其他提供商也会做类似的事情，以便在不中断投递的情况下替换一个密钥。如果发件人给你 `s1` 和 `s2`，请发布这两个记录。如果第二个发件人使用不同的选择器系列，也要将这些记录分开。名称可能看起来重复；但记录并不冗余。

请准确输入 DKIM 主机名。如果提供商告诉你创建 `selector1._domainkey.example.com`，请在 Cloudflare 中使用该完整标签。如果提供商给出 CNAME 目标，请准确粘贴目的地。Cloudflare 不需要翻译。它需要的是准确性。

对于遵循 DKIM SPF DMARC 事务设置的团队，即使邮件量很小，规则也适用：DNS 中的选择器必须与邮件头中的选择器匹配。如果它们不同，DKIM 将失败。没有戏剧性，只是失败。

5. 在 _dmarc

DMARC 应该放在 `_dmarc.yourdomain.com`。在 Cloudflare 中，创建一个具有该确切名称的 TXT 记录。值以 `v=DMARC1` 开头，然后添加你的策略和可选标签。一个常见的起始策略是 `p=none`，因为它允许你在阻止任何内容之前收集报告。这是最不激进的起点。

如果你的组织准备好接收报告，请添加 `rua` 标签和汇总报告地址，如果需要，还可以添加 `ruf` 标签用于取证报告。使用一个有人实际监控的地址。一个无人值守的邮箱不是策略。这是一个陷阱。

这里有一个实用的规则：从一个与当前对误报的容忍度相匹配的 DMARC 策略开始，然后在你知道合法发件人已对齐后再收紧。如果你行动太快，可能会阻止发票、警报或密码重置。这会立即引起注意。

Cloudflare 会像其他文本条目一样存储 DMARC TXT 记录，但细节很重要。记录名称必须是 `_dmarc`，而不是 `dmarc`，也不是 `_dmarc1`，更不是根域名。策略字符串必须遵循你的提供商所期望的语法。如果你的邮件平台建议使用 `sp`、`adkim` 或 `aspf` 等标签，只有在你理解其影响时才添加它们。

6. 检查可能阻止验证的 Cloudflare 特定 DNS 设置

Cloudflare 有一个设置造成的困惑比应有的要多：代理。电子邮件认证记录不应被代理。SPF、DKIM 和 DMARC 存在于 DNS 中，而不是在橙色云后面。如果不小心代理了与邮件相关的主机名，就会将 Web 流量规则与电子邮件 DNS 记录混合在一起。

记录名称是另一个常见的失败点。一个应该是 `selector1._domainkey` 的 DKIM 选择器可能被输入为 `selector1._domainkey.`（多了一个点），或者作为 `selector1 domainkey`（从提供商页面复制的空格）。Cloudflare 接受许多 DNS 条目，但接收系统对界面不那么宽容。

旧记录也可能干扰。如果旧的 SPF TXT 记录与新的记录并存，或者过时的 DKIM CNAME 仍指向已退役的服务，验证可能会以看似随机的方式失败。只有在确认不再需要后，才删除无效条目。这样可以保持活跃发件人的完整性。

如果您也在为事务性电子邮件的电子邮件认证设置工作，现在是检查供应商列出的每个发送主机的时刻。一个被遗忘的子域名可能会导致支持消息通过，而收据消息失败，这种分裂行为在客户投诉之前很难发现。

7. 验证来自Cloudflare管理的DNS的传播和邮件认证

保存记录后，等待DNS传播。确切的时间取决于您的TTL和您面前的解析器缓存，因此不要假设在Cloudflare说已保存的那一刻记录在所有地方都是可见的。使用DNS查找工具进行外部检查，并确认每个记录名称返回预期的值。

然后从使用这些记录的服务发送一条真实的测试消息。不要从绕过您正常邮件流的随机收件箱进行测试。在接收邮箱中打开消息头，查找SPF通过、DKIM通过和DMARC对齐通过。消息仍然可能因其他原因进入垃圾邮件，但认证结果应该告诉您DNS方面是否正确。

第一次检查只需快速检查一次，但从不同的邮箱进行第二次检查会给您更好的信号。如果一个解析器短暂地看到旧记录，而另一个看到新记录，Gmail测试和Microsoft 365测试的表现可能会有所不同。这并不罕见。它会发生。

如果可交付性是同一项目的一部分，请将此工作与电子邮件可交付性最佳实践配对。认证并不是全部，但它是让接收者决定您的域名是否在为自己发声的部分。

8. 当您的邮件提供商更改时更新记录

邮件设置会发生变化。提供商轮换DKIM密钥，添加营销平台，或在迁移后移动交易服务。当发生这种情况时，在切换流量之前更新Cloudflare中的DNS记录，而不是之后。这个顺序可以让您避免一天的签名损坏。

DKIM轮换通常是最干净的更改。提供商给您一个新的选择器和密钥，您在Cloudflare中发布它，并在新选择器验证之前等待退役旧选择器。如果提供商支持，在过渡期间保持两个选择器同时在线。两个选择器比一次停机更容易处理。

SPF更改稍微复杂一些，因为记录必须保持在SPF标准设定的DNS TXT大小和查找限制之下。如果有新的发送者加入堆栈，请将其包含机制添加到现有的SPF记录中，而不是在旁边堆叠另一个记录。如果您接近查找限制，请尽可能减少不必要的包含，并确认提供商的当前指导。

对于通过多个服务发送的团队，如果一个人负责授权发送者的列表，维护会变得更容易。该列表应包含服务名称、主机名、DKIM选择器和最后更改的日期。一个简单的表格可以保持Cloudflare编辑的一致性，而一致性比聪明更重要。

如果退信处理和发件人更改是同一个邮箱项目的一部分，那么相同的原则有助于电子邮件退信处理最佳实践。提供商迁移可以在同一天更改身份验证和错误行为，双方都不应猜测。

Cloudflare使发布部分变得简单，但记录仍然需要规范。一个发送者。一个SPF记录。每个DKIM选择器在正确的位置。一个DMARC记录在`_dmarc`。如果你保持这四个要点清晰，其余的主要是耐心，进行一些头部检查，以及在下一个平台变更到来之前愿意更新DNS。