用于事务性电子邮件的 DKIM SPF DMARC 设置

电子邮件认证中的 DKIM、SPF 和 DMARC 是什么

当一封事务性电子邮件离开您的系统时，它不仅需要被发送。它需要证明它属于它声称属于的地方。这就是 DKIM、SPF 和 DMARC 的工作：这三个标准共同帮助接收邮件服务器决定一条消息是否是合法的。

SPF，或发件人策略框架，告诉世界哪些服务器被允许代表您的域发送电子邮件。这是一个基于 DNS 的允许列表。如果您的消息来自一个被批准的发送 IP，SPF 可以通过。如果来自其他地方，可能会失败。

DKIM，或域名密钥识别邮件，采取不同的方法。它在消息头中添加一个加密签名。接收服务器检查该签名是否与在 DNS 中发布的公钥匹配。如果签名匹配，服务器就知道消息在传输过程中没有被更改，并且是由授权域签名的。

DMARC，或基于域的消息认证、报告和一致性，位于 SPF 和 DKIM 之上。它告诉接收服务器如果消息未通过认证该怎么办，并检查对齐：简单来说，就是可见的发件人地址中使用的域是否与 SPF 或 DKIM 验证的域匹配。DMARC 是将所有内容联系在一起的政策层。

这些协议一起使用时，给接收系统提供了更强的信号，表明您的消息是真实的。这很重要，因为事务性电子邮件不仅仅是另一种营销发送。密码重置、订单收据或安全警报通常在用户期待时立即到达。如果认证薄弱或配置错误，这些消息可能会落入垃圾邮件，标记为可疑，或根本无法到达。

为什么事务性电子邮件需要适当的认证

事务性电子邮件承载着客户关系中的实际时刻。它们包括密码重置、账户验证消息、发票、发货通知、收据确认和登录警报。这些是人们在需要关注时首先寻找的消息。

这就是为什么糟糕的认证不仅仅是技术上的麻烦。如果收据没有到达，客户可能会认为付款失败。如果安全警报被过滤掉，用户可能会错过真正的威胁。如果密码重置邮件进入垃圾邮件，支持票据就会开始堆积。换句话说，投递能力是产品体验的一部分。

这也是一个信任问题。垃圾邮件过滤器和邮箱提供商在设计上是谨慎的，它们通常将未经验证的邮件视为风险。即使内容完全合法，弱的发件人声誉或破损的身份验证设置也会使消息看起来不可信。对于事务性邮件来说，这尤其痛苦，因为用户通常期望快速、可靠的投递。

如果您已经在考虑更广泛的投递情况，查看整个链条而不是单个设置可能会有所帮助。身份验证、发件人声誉、内容质量和退信处理都会影响收件箱的投递。要获得更完整的视图，请参见电子邮件投递测试工具。

SPF记录的工作原理及其设置方法

SPF通过发布一个DNS记录来工作，该记录列出了被允许为您的域发送邮件的服务器。当接收服务器收到一条消息时，它会检查发送IP是否在该记录中。如果IP被包含，SPF可以通过。如果没有，服务器可能会将消息视为未经授权。

SPF记录通常作为DNS中的TXT记录存储。它通常以v=spf1开头，后面跟着机制，如ip4、ip6或include，并以限定符结束，如-all或~all。确切的结构取决于您的基础设施和提供商。

对于事务性电子邮件设置，您通常需要识别每个代表您发送邮件的服务。这可能包括您的应用服务器、电子邮件投递平台、支持台或计费工具。如果它从您的域发送，则每个都必须在SPF记录中列出。

一个简单的配置可能通过包含语句授权一个电子邮件提供商。一个更复杂的配置可能列出一个专用发送IP和一个或多个第三方服务。重要的是不要猜测。只授权您实际使用的系统。

有一些值得记住的实用规则：

• 每个域名只能发布一个SPF记录。
• 保持记录尽可能简洁。
• 确保发送的IP和包含语句是正确和最新的。
• 根据您希望如何严格处理未授权邮件，在最后使用正确的限定符。

传播时间也很重要。DNS更改并不总是立即在所有地方出现，因此在更新SPF后，允许时间让记录传播，然后再假设配置已完成。

为事务性电子邮件设置DKIM

DKIM为每个发出的消息提供数字签名。发送电子邮件的服务器使用私钥对选定的头部和消息正文进行签名。接收服务器在DNS中查找匹配的公钥，并检查签名是否有效。

在实践中，这意味着您需要两个部分：由您的发送系统或提供商保管的私钥，以及在DNS中发布的公钥。DNS记录通常位于特定选择器的子域下，这样您可以在不一次性破坏所有内容的情况下旋转密钥。

大多数事务性电子邮件提供商会通过几个标准步骤指导您完成此设置：

1. 生成或请求一个DKIM密钥对。
2. 将提供商的公钥作为TXT记录添加到您的DNS中。
3. 选择将在DKIM签名中使用的选择器。
4. 在您的发送平台或应用中启用签名。
5. 发送测试消息并确认签名存在且有效。

这听起来简单，通常确实如此，但细节很重要。如果选择器输入不正确，接收服务器将找不到正确的公钥。如果发送方的私钥未激活，电子邮件将以未签名的方式发送。如果其他系统在签名后修改了消息，签名可能会失效。

一个有用的习惯是将 DKIM 视为保管链的一部分。消息在离开您的系统时被签名，签名表示：“这个版本来自我。”如果脚注服务、网关或转发系统稍后更改了电子邮件，签名可能会失效。这并不总是意味着消息是恶意的，但它可能会影响邮箱提供商的处理方式。

对于事务性提供商，通常的目标是签署来自相关域或子域的所有外发邮件，并在每种消息类型中保持签名行为的一致性。密码重置和收据不应被视为特殊情况，除非您的架构要求这样。

配置 DMARC 以保护您的域名

DMARC 是身份验证变为政策的地方。它告诉接收服务器如何处理未通过 SPF 或 DKIM 的消息，并且还让您接收关于使用您域名发送的邮件的报告。

DMARC记录也作为TXT记录发布在DNS中，通常位于_dmarc.yourdomain.com。它包含一个可以从监控模式开始并随后转向强制执行的策略值。常见的策略选项有：

• none — 监控流量并收集报告而不阻止邮件。
• quarantine — 建议对失败的邮件持怀疑态度，通常会被送到垃圾邮件中。
• reject — 请求直接阻止失败的邮件。

DMARC还依赖于对齐。SPF或DKIM在技术上可能通过，但如果经过身份验证的域与可见的发件人域不对齐，DMARC仍然可能失败。这就是为什么第三方发送者和子域需要仔细设置的原因。来自billing@yourdomain.com的消息应该以某种方式进行身份验证，以便连接回yourdomain.com，而不是某个无关的发送域。

大多数团队从监控策略开始，以便在采取行动之前查看邮件的行为。这是明智的。报告帮助您发现被遗忘的工具、仍在发送邮件的旧平台以及否则会隐藏的配置错误。一旦您确信合法邮件正在正确进行身份验证，您可以转向隔离或拒绝。

DMARC报告起初可能感觉很复杂，但它们非常有用。它们显示谁在为您的域发送邮件，SPF和DKIM是否通过，以及对齐在哪里失败。如果您试图改善发送者设置的整体健康状况，这是最清晰的查看地方之一。

常见的DKIM SPF DMARC设置错误

即使是出于良好意图的设置也可能以小但有害的方式出错。最常见的错误通常并不戏剧化。它们是那些在可交付性开始下降之前潜伏的安静配置错误。

• 为同一域发布多个SPF记录，而不是一个合并的记录。
• 忘记包括一个正在积极用于事务性邮件的发送服务。
• 使用错误的DKIM选择器或将公钥复制到错误的DNS名称中。
• 允许在某些消息类型上禁用DKIM签名，而在其他类型上不禁用。
• 在验证所有合法邮件正确对齐之前设置DMARC策略。
• 更换供应商而不更新整个堆栈中的SPF、DKIM和DMARC引用。

对齐错误值得特别关注。人们很容易相信身份验证“正常工作”，因为测试工具显示SPF通过或DKIM通过。但DMARC关注的是这些通过是否与发件人域名对齐。这是许多设置在现实中失败的地方。

另一个常见的问题出现在团队添加转发、路由或消息处理工具时，这些工具会更改头部。有时电子邮件仍然会到达，但身份验证结果会改变。如果您注意到收件箱位置突然变化，值得检查交付路径中是否有东西在重写或中继消息。

是的，DNS错误发生的频率比人们承认的要高。缺少引号、带有错误标签的复制选择器或过时的包含语句都足以破坏身份验证。最安全的方法是在发布后验证每个更改，而不是假设仪表板立即反映现实。

测试和验证您的身份验证设置

一旦记录到位，测试就是理论与收件箱的结合。发送一条真实的事务消息并检查消息头。您希望看到SPF、DKIM和DMARC的明确通过结果，以及被评估的域名。

大多数邮箱提供商在原始消息源中包含身份验证详细信息。查找指示SPF是否通过、DKIM是否生成有效签名以及DMARC是否通过对齐的字段。如果其中一个失败，标题通常会提供有关原因的线索。

从多个邮箱提供商进行测试也是有帮助的，因为不同的系统可能以不同的方式显示身份验证结果。在一个收件箱中看起来正常的消息可能在另一个收件箱中显示出问题。这并不罕见，只是令人烦恼。

在检查事务邮件时，测试最重要的消息：密码重置、注册确认、账单通知和警报。不要仅依赖于提供商发送的简单“测试邮件”，因为真实系统可能使用不同的标题、不同的路由或不同的发件人身份。

如果您不确定您的配置是否随着时间的推移而保持有效，定期检查标题和DNS记录是值得的。您不需要过于复杂化；您只需要一个可重复的习惯。对于实际检查，电子邮件可送达性测试工具中涵盖的工具和方法可以帮助您确认消息实际落在哪里以及如何被评估。

维护电子邮件身份验证的最佳实践

身份验证不是一次性的项目。这是一项维护任务。域名易手，提供商更换，新产品开始发送邮件，而旧系统的存在时间往往超出预期。如果您不定期重新审视SPF、DKIM和DMARC，漂移最终会悄然发生。

良好的维护例程包括一些简单的习惯：

• 在任何供应商或基础设施变更后检查DNS记录。
• 审核每个从您的域或子域发送邮件的系统。
• 检查DMARC报告，查看是否有不熟悉的来源或对齐失败。
• 验证DKIM密钥是否仍然有效，并且选择器与发送设置匹配。
• 确认SPF没有变成一个冗长、脆弱的记录，充满过时的包含项。

记录每个记录的所有者及其存在的原因也是明智的。这样，当有人询问为什么某个服务出现在SPF中时，您就不必从记忆和旧票据中逆向推导历史。

当引入新的电子邮件供应商时，将身份验证视为入职的一部分，而不是事后考虑。询问提供商如何处理SPF、DKIM和DMARC对齐。确认他们是否为您的域签署邮件，是否需要自定义选择器，以及他们的发送地址是否符合您的政策目标。

最后，关注用户体验。如果密码重置开始失败或收据变得不可靠，不要假设问题出在内容或设计上。首先检查身份验证记录。在事务性电子邮件中，最小的DNS记录可能会产生最大的实际影响。

对于希望获得更广泛声誉和收件箱投放策略的团队，电子邮件投递最佳实践中的指导可能也会有用，特别是当身份验证只是更大投递图景的一部分时。

如果做得好，事务性电子邮件的DKIM SPF DMARC设置将创建一个坚实的基础。它告诉邮箱提供商您的邮件是合法的，帮助保护用户免受欺诈，并为您自己的团队提供更清晰的故障排除路径。回报很简单：为人们实际需要的消息提供更可靠的投递。