电子邮件认证设置指南：SPF 和 DKIM 解释

如果您从一个您关心的域发送电子邮件，身份验证不是可选的。这是您设置的一部分，它告诉接收邮件服务器：“是的，这条消息确实来自我们。”没有它，即使内容完全合法，您的邮件也可能看起来可疑。有了它，您可以给收件箱提供更清晰的信号，减少欺骗的机会，并让试图借用您品牌名称进行自己计划的网络钓鱼者的生活变得更加困难。

SPF和DKIM是大多数团队首先设置的两个支柱。它们的工作不同，并且在一起使用时最强大。SPF检查发送消息的服务器是否被允许为您的域发送邮件。DKIM检查消息是否由您的域签名，以及在发送过程中是否发生了更改。DMARC位于顶部，告诉接收者如何处理未通过这些检查的消息。如果您想更全面地了解身份验证如何融入整体收件箱投递，阅读电子邮件投递最佳实践将有助于您与本指南一起使用。

这是简短版本。更长的版本更实用：您需要知道在DNS中发布什么，您的邮件提供商需要您提供什么，以及如何确认设置在上线后确实有效。

什么是电子邮件身份验证以及它为什么重要

电子邮件身份验证是一组技术检查，帮助接收系统决定一条消息是否确实与其声称来自的域相关。可以把它看作是一系列证明。一条消息可以声称来自您的公司，但如果发送者的IP未被授权、内容被更改，或者消息未通过政策检查，则该声明的可信度降低。

这为什么如此重要？因为电子邮件仍然是最容易被冒充的渠道之一。伪造的消息在发件人字段中包含您的域可能会混淆客户，损害信任，并造成支持上的麻烦。身份验证并不能阻止每一次滥用尝试，但它为邮箱提供商和安全过滤器提供了更好的证据。结果通常是更少的欺骗机会和更健康的收件箱投递路径。

这对于普通的、非恶意的原因也很重要。大型提供商通常会对未经过身份验证的邮件保持谨慎。如果身份验证的情况看起来薄弱，合法的时事通讯、密码重置或订单确认可能会被归类为垃圾邮件或直接被拒绝。这对于事务性电子邮件尤其痛苦，因为速度和可靠性至关重要。如果您的应用程序发送系统消息，您可能还想查看DKIM SPF DMARC事务性设置以获得更专注于事务性的视角。

关于身份验证，有一个有用的思考方式：它不仅仅关乎安全，也不仅仅关乎可送达性。两者都是。当技术证明清晰时，邮件服务器可以更快地信任你，攻击者也更难假装成你。

电子邮件身份验证如何在SPF、DKIM和DMARC之间工作

SPF、DKIM和DMARC是相关的，但它们的功能不同。每个标准检查消息旅程的不同部分。

SPF，或发送者策略框架，验证发送IP是否被允许为某个域发送电子邮件。它通过在DNS中发布允许的发送源列表来工作。当接收服务器收到一条消息时，它会将发送者的IP与该列表进行比较。

DKIM，或称为域名密钥识别邮件，用私钥对消息进行签名。接收服务器从DNS中检索公钥，并使用它来验证签名。如果签名匹配，则证明该消息是由控制该密钥的域签署的，并且电子邮件的签名部分在传输过程中没有被更改。

DMARC，或称为基于域的消息认证、报告和一致性，将SPF和DKIM结合在一起。它检查用户可见的域是否与通过SPF或DKIM的域一致。然后，它告诉接收方在不一致时该怎么做：监控、隔离或拒绝。

使用这三者的实际价值很简单。SPF有助于源授权。DKIM有助于完整性和身份验证。DMARC帮助接收方一致地执行策略。如果一种方法失败，另一种方法可能仍然通过，这很有用，因为电子邮件并不是一个完全整洁的系统。消息通过中继、网关和过滤器传递，并不是每条路径的行为都相同。

在大多数设置中，SPF和DKIM是首先要正确配置的记录。一旦这些稳定，DMARC就变得更加有用，因为它有真实的信号可以评估。

SPF设置：将授权发送源添加到您的DNS中

SPF设置始于一个问题：谁实际上被允许为您的域发送邮件？这听起来很明显，但在实践中，它通常包括不止一个系统。您的网站可能通过一个提供商发送密码重置，您的营销团队可能使用另一个平台，而您的帮助台软件可能通过第三方服务发送支持回复。

首先列出每个合法的发送者。包括您的主要邮件主机、交易提供商、CRM平台以及任何代表您的域发送的基础设施。在这里要小心。如果您忘记了一个源，该系统的邮件可能会失败SPF。如果您添加了一个不再使用的源，您就打开了一个不必要的门。

接下来，为该域构建一个单一的SPF记录。SPF以TXT记录的形式发布在DNS中。内容是一个政策声明，通常以v=spf1开头，然后包括授权机制，如ip4、ip6、include或a，最后以政策限定符如-all或~all结束。确切的语法取决于您的环境，但想法始终相同：定义谁可以发送，然后指定其他所有情况应该发生什么。

有一条规则值得记住：每个域只使用一个SPF记录。多个SPF TXT记录可能会导致问题，因为接收方期望有一个单一的政策声明。如果您需要授权多个服务，请将它们合并为一个记录，而不是创建单独的条目。

基本工作流程如下：

1. 列出所有为该域发送电子邮件的平台。
2. 收集每个提供商的SPF指令。
3. 将它们合并为一个SPF TXT记录。
4. 在DNS中发布该记录。
5. 等待DNS传播并测试结果。

有一点需要注意：SPF在评估期间对DNS查找有一个限制。这意味着你应该避免在一个记录中堆叠过多的嵌套包含和辅助项。将每个提供商的包含字符串都添加进去并认为完成是很诱人的。要抵制这种诱惑。干净的SPF记录更耐久，也更容易排查故障。

如果你还在管理退信行为，SPF和退信处理通常在同一操作对话中一起进行。身份验证使邮件更值得信赖，而抑制和退信管理则保持你的列表健康。对于这方面的工作，电子邮件退信处理最佳实践是一个合理的伴读。

DKIM设置：使用加密密钥签署出站电子邮件

DKIM 是设置中感觉更技术性的部分，但概念很简单。您的邮件系统使用私钥对外发消息进行签名。您在 DNS 中发布匹配的公钥。当消息到达时，接收方检查签名是否与发布的密钥匹配，以及消息的签名部分是否完整。

第一步是密钥生成。许多电子邮件平台为您生成 DKIM 密钥，这通常是最简单的方式。如果您管理自己的邮件基础设施，您可能需要自己创建密钥对。重要的是私钥保留在发送方，而只有公钥在 DNS 中发布。

一旦您拥有公钥，您需要在选择器下创建一个 DNS TXT 记录。选择器是标识正在使用的特定密钥的标签。它允许您稍后轮换密钥，而不会一次性破坏所有内容。典型的 DKIM 记录包括选择器、域名和公钥值。

在 DNS 记录发布后，在您的邮件提供商或 MTA 中启用 DKIM 签名。此步骤因平台而异。一些服务要求您将选择器和私钥粘贴到他们的仪表板中。其他服务则允许您在 DNS 验证后通过单个切换开启签名。无论哪种方式，请确保系统正在对正确的发件域或与之密切相关的域进行签名，具体取决于您的配置。

然后发送一条测试消息。打开原始头部并查找 DKIM-Signature 头部。如果存在，则消息已被签名。如果接收系统报告 DKIM 通过，您就接近成功。如果失败，原因通常是以下三种情况之一：选择器错误、DNS 中的公钥与私钥不匹配，或消息以某种方式更改，导致签名失效。

DKIM 特别有价值，因为它比发送者 IP 检查更具韧性。如果消息被转发或中继，即使消息是合法的，SPF 也可能失败。如果签名内容保持完整，DKIM 仍然可以通过。这种灵活性是它成为电子邮件认证基石的原因之一。

如何测试和验证您的记录

测试是理论变为现实的地方。记录在纸面上看起来完美，但由于语法错误、DNS 延迟或被忽视的提供商设置而失败。

从基本的 DNS 检查开始。您可以直接查询 SPF 和 DKIM TXT 记录，以确认它们存在并包含您期望的值。检查域名、选择器和实际记录文本。小的拼写错误很重要。DKIM 公钥中的一个多余字符可能会使整个签名失效。

接下来，向您控制的邮箱发送一条消息并检查完整的邮件头。大多数主要邮箱提供商在消息详情中包含身份验证结果。查找 SPF 通过或失败、DKIM 通过或失败，以及任何引用对齐的 DMARC 结果。

您还可以使用外部测试工具从接收方查看您的设置。这些工具通常会总结您的记录是否正确解析，以及消息是否通过身份验证检查。对于更结构化的测试工作流程，电子邮件可送达性测试工具在您需要第二意见时可能会很有帮助。

当您查看结果时，不要仅停留在“通过”或“失败”。查看原因。带有警告的通过可能仍然暗示未来的问题，特别是当您即将更换提供商或添加新的发送源时。失败可能指向 DNS 传播、对齐问题或意外的发件人。

如果您使用 DMARC 报告，它们对于查看您的邮件生态系统中发生的事情特别有用。它们可以揭示被遗忘的服务、过时的 IP 地址或未经授权的流量，这些您从单个测试消息中永远无法发现。

常见设置错误及其修复方法

大多数身份验证问题并不神秘。它们通常是由于一些常见错误造成的。

一个常见的问题是为同一域发布多个SPF记录。当不同团队管理不同系统时，这很容易发生。解决方法很简单：将授权源合并为一个记录。

另一个常见问题是超过SPF查找限制。当您的SPF记录通过过多的包含和机制链式连接，每个都需要DNS评估时，就会发生这种情况。如果遇到这种情况，请简化记录，删除未使用的发送者，或向提供商请求更平坦的SPF配置。

缺失或不正确的DKIM选择器是另一个经典问题。如果DNS中的选择器与您的邮件系统在签名时使用的选择器不匹配，即使公钥本身是正确的，验证也会失败。请仔细检查选择器名称、域名和确切的记录路径。

密钥不匹配也是常见问题。有时提供商会轮换密钥，或者有人将错误的密钥复制到DNS中。结果是一个看起来有效但无法验证的签名。如果需要，请重新生成密钥对，然后重新发布并重新测试。

对齐问题也可能导致DMARC失败。一条消息在技术上可能通过SPF或DKIM，但如果经过身份验证的域与可见的发件人域不对齐，DMARC仍可能将其视为失败。这就是为什么测试用户看到的确切域名而不仅仅是后端发送域名很重要。

最后，不要忽视DNS格式。引号、换行符和多余的空格都可能影响记录的解释。当有疑问时，请逐字符比较您的记录与提供商推荐的示例。

推荐的推出和维护清单

身份验证不是一次性的项目。它是一个随着您的邮件堆栈演变而维护的设置。

• 在进行更改之前，先对每个发件人进行清点。
• 每个域保持一个SPF记录。
• 对所有重要的外发流使用DKIM。
• 在广泛发布之前，在受控邮箱中测试新记录。
• 在提供商更改或基础设施更新后监控身份验证结果。
• 当您的安全政策或提供商设置要求时，轮换DKIM密钥。
• 定期查看DMARC报告，以便尽早发现不熟悉的发送者。
• 每当您添加、删除或切换电子邮件服务时，请更新DNS。

仔细的推出很重要。如果您正在从一个平台迁移到另一个平台，请在切换之前发布新的SPF或DKIM设置，然后在过渡期间测试旧路径和新路径。这可以减少在实时流量中突然出现身份验证失败的机会。

将身份验证与其他可交付性工作协调也是明智的。如果您正在为一个新的域名或IP进行预热，身份验证应该在预热开始之前就到位，而不是之后。如果您的邮件程序包括推送通知或其他消息渠道，比较您的电子邮件卫生与Web Push Notification Best Practices中的做法可能会很有用，以确保您的沟通堆栈保持一致。

随着时间的推移，目标很简单：让您的域名易于信任。SPF告诉世界哪些系统被允许代表您发言。DKIM证明消息是由您签名并保持完整的。它们共同为可交付性、安全性和品牌保护建立了更稳固的基础。这种管道在正常工作时没有人会注意到，这通常是身份验证能获得的最佳赞美。