域名的 DKIM SPF DMARC 设置

域名的 DKIM SPF DMARC 设置：电子邮件认证的完整指南

电子邮件仍然是任何域名中最脆弱的部分之一，网站可能构建得很精美，服务器也得到很好的保护。如果以公司名义发送的消息容易被伪造，问题就会迅速出现：网络钓鱼活动、用户投诉、信任丧失，以及在最坏的情况下，您自己电子邮件的投递率下降。这就是为什么域名的 DKIM SPF DMARC 设置并不是一个“细小的技术细节”——这是基本的电子邮件基础设施卫生，也是电子邮件认证的重要组成部分。

如果您曾经遇到过电子邮件无缘无故地进入垃圾邮件，或者客户问：“你真的发了这个吗？”——那么现在就该开始进行域名认证了。而越早越好。从这个意义上说，电子邮件的工作方式与网站非常相似：如果没有定期关注，即使是一个稳固的系统也会开始表现得不可预测。我们经常在关于 网站安全：保护不是一个插件或一个设置，而是一组协同工作的措施。如果您在想 如何配置 SPF DKIM DMARC，关键是将它们视为一个协调的过程，而不是单独的修复。

什么是 DKIM、SPF 和 DMARC 以及它们的重要性

DKIM、SPF 和 DMARC 解决了类似的问题，但它们的方式不同。如果您计划 为域名设置电子邮件认证.

SPF 回答了这个问题：“哪些服务器实际上被允许代表该域发送邮件？”在 DNS 中，你发布一个批准的发件人列表，收件人的邮件服务器将其与消息实际来源的 IP 地址进行比较。

DKIM 为消息添加了一个加密签名。收件人检查电子邮件是否确实由你的域签名，以及在传输过程中是否被更改。这不仅仅是一个允许列表——它是发件人身份和消息完整性的证明。

DMARC 将 SPF 和 DKIM 结合成一个政策，并告诉邮件系统如果消息未通过检查该怎么做：投递、发送到隔离区或直接拒绝。DMARC 还让你收到关于谁试图从你的域发送邮件以及如何发送的报告。

这就是为什么这些机制不仅仅是为了防止伪造邮件。它们直接影响邮件的投递率。邮件服务越来越多地关注的不仅是消息的内容，还有其身份验证的设置情况。对于商业域名来说，这一点至关重要：丢失几条消息是一回事，但反复出现在客户、合作伙伴和服务的垃圾邮件中则完全是另一回事。

DKIM、SPF 和 DMARC 如何协同工作

每个协议单独使用都很有用，但结合在一起，它们创建了一个更可靠的验证系统。

SPF 确认消息来自一个被批准的服务器。但它有一个限制：如果邮件被转发，SPF 可能会“失效”，因为最后发送者的 IP 地址发生了变化。在这种情况下，DKIM 通常会有所帮助，因为签名在转发后仍然有效，只要消息本身没有被修改。

DMARC 反过来检查的不仅是 SPF 和 DKIM 是否存在，还要检查它们是否与发件人字段中的域名一致。这很重要。一条消息可以在技术上被签名，但用户看到的发件人名称却是完全不同的域名，而 DMARC 有助于防止这种混淆并阻止明显的欺诈行为。

简单来说：SPF 是入口处的宾客名单，DKIM 是文件上的印章，而 DMARC 是针对没有通行证或印章的访客的安全规则。单独使用某一措施会留下漏洞。

这就是为什么它们应该一起实施。这对于使用多个电子邮件来源的公司尤其重要：CRM 系统、新闻通讯服务、工单平台、联系表单、交易通知。如果这些没有对齐，电子邮件基础设施就会像一组不相连的孤岛一样运作。

准备设置：域名、DNS 和电子邮件服务

在创建任何记录之前，您需要了解究竟是谁代表该域发送邮件。可能是一个电子邮件服务，或者多个：企业电子邮件、邮件平台、通知系统、网站的单独SMTP服务。没有这个全貌，您可能会冒险允许过多，或者相反，意外阻止所需的发件人。

您需要访问域的DNS面板。通常这是注册商的界面、您的托管提供商或单独的DNS提供商。确切知道记录在哪里编辑是很重要的：有时一个人会在邮件服务中寻找问题，而记录实际上是在另一个提供商那里。

另一个重要步骤是收集电子邮件提供商的详细信息。通常您需要：

• SPF数据或推荐的SPF记录；
• DKIM密钥或生成密钥的说明；
• DKIM选择器名称（如果提供商使用的话）；
• DMARC建议；
• 用于发送的域和子域列表；
• 了解当前哪些服务正在发送邮件，哪些将在以后添加。

如果您不是在处理一个新域，首先查看当前配置是个好主意。有时SPF已经存在，但仍列出旧服务。有时DKIM在某个时刻已启用，但邮件系统后来转移到另一个提供商。有时DMARC存在，但只是“为了展示”，没有报告和有意义的政策，最好在进行更改之前捕捉到这些问题，而不是在用户投诉之后。

为域名设置 SPF

SPF 记录以 TXT 记录的形式发布在 DNS 中。它的作用是列出被批准的发送源。基本思想很简单：您指定哪些服务和服务器被允许代表域发送邮件，其他所有内容都被视为未经授权。

在设置时，请记住这一点：一个域名应该只有一个 SPF 记录。不是两个，不是三个——一个。如果您添加多个带有 SPF 的 TXT 记录，许多收件人会将其视为错误。这是电子邮件基础设施支持中最常见的问题之一，为域名设置电子邮件认证在这里对细节特别敏感。

另一个常见的错误是过于宽泛。有时人们使用过于宽松的规则只是为了“避免破坏任何东西”。结果，允许的发送者比必要的要多。这在开始时很方便，但对安全性更糟糕，如果您重视防止伪造邮件，SPF 应该是精确的，而不仅仅是“粗略正确”。

发布记录后，检查它是否在 DNS 中实际可见，并与您当前的发送源匹配。如果您通过多个平台发送邮件，请验证每一个。否则，您可能会轻易陷入一种情况，即 CRM 邮件通过，但网站通知却不通过。

发布记录后，检查它是否在 DNS 中实际可见，并与您当前的发送源匹配。如果您通过多个平台发送邮件，请验证每一个。否则，您可能会轻易陷入一种情况，即 CRM 邮件通过，但网站通知却没有。

设置 DKIM：生成密钥并发布 DNS 记录

DKIM 使用一对密钥：私钥保留在发送者手中，公钥发布在 DNS 中，当消息发送时，服务器使用私钥对其进行签名。接收者从 DNS 中获取公钥并验证签名。如果一切匹配，消息被视为真实的。

DKIM 通常通过电子邮件服务进行配置。在提供商的仪表板中，您选择域名，生成密钥或接收现成的设置，然后发布带有公钥部分的 TXT 记录。记录中通常包含选择器——一个特殊名称，用于帮助区分一个密钥与另一个密钥。如果域名有多个发送系统或您计划轮换密钥，这尤其有用。

发布 DNS 记录后，您需要在服务本身中启用外发消息的签名，否则 DNS 记录是无用的：密钥将停留在区域中，但电子邮件将保持未签名。从故障排除的角度来看，这是一个常见的陷阱：“记录已添加，但 DKIM 不工作。”实际上，签名只是没有在发送者一侧启用，因此 为域名设置电子邮件认证 仍然不完整。

从技术上讲，重要的是检查：

• 选择器在 DNS 和服务设置之间是否匹配；
• TXT 记录是否正确发布；
• 粘贴时密钥是否意外被截断；
• 是否所有必要的消息类型都已签名，而不仅仅是其中一些；
• 签名后消息是否发生变化，例如由于中间服务的额外处理。

DKIM 对于事务性电子邮件特别有用：注册确认、密码重置、订单通知。这些消息需要稳定地到达。如果网站有良好的结构和坚实的发布后支持，比如 网站上线后的支持，电子邮件认证通常是不会被推迟到“以后”的事情。这是正确的方法。

设置 DMARC 策略和报告

DMARC 增加了控制。没有它，你可以分别查看 SPF 和 DKIM，但你没有明确的规则来处理可疑消息。DMARC 记录也作为 TXT 记录发布在 DNS 中，通常在 _dmarc 子域下。

一开始，许多人选择无政策。这是一种监控模式：消息不会被阻止，但域名所有者会收到报告，可以看到谁在发送邮件，检查是否通过，以及哪里存在漏洞。这是一个明智的第一步，特别是如果基础设施复杂，你不想突然切断合法消息。

在监控期后，政策可以收紧：隔离将可疑消息发送到垃圾邮件或隔离区，而拒绝则直接阻止它们。选择哪个选项取决于你的电子邮件设置有多成熟，以及你对所有合法来源是否已经考虑周全的信心。

在 DMARC 报告中，查看错误不仅有用，还要关注意外的发送来源，有时旧服务、测试平台或被遗忘的集成会出现在那里。这是一个清理的好机会。

如果你正在为企业域名实施 DMARC，值得检查是否重要的流程依赖于第三方服务。例如，如果网站积极使用表单和电子邮件通知，并且网站结构是通过多个模块发送消息的，提前对齐每个发送点是有帮助的。我们还在主题中涵盖相关问题 企业网站结构架构越清晰，电子邮件层面的意外就越少，电子邮件认证设置就越顺利。

部署后的验证和故障排除

设置后，不要依赖“似乎可以工作”的感觉。验证应该是有意识和系统的。

首先，确保SPF记录在DNS中可见，并且仅包含当前来源。然后发送测试消息并检查收件方的头部：它们通常显示SPF是否通过，是否有DKIM签名，以及DMARC是否被触发。

如果消息未通过验证，请逐步查找原因：

1. DNS记录是否正确输入；
2. DNS传播是否经过足够的时间；
3. 发件人中的域名是否与签名域名匹配；
4. 消息是否由您期望的服务进行签名；
5. 是否有中间系统在签名后修改消息。

测试不仅仅是一条消息，而是多个场景非常有用：网站上的表单、CRM电子邮件、注册通知、通过电子邮件营销服务发送的新闻通讯。有时问题只出现在一个渠道，而其他渠道看起来完美。

检查 DNS 记录的解释方式也是值得的。错误可能很微小：多了一个空格、错误的引号、不正确的选择器、多个 SPF 记录而不是一个。像这样的细节可能会破坏结果，即使一开始看起来一切都是正确的。

保持设置健康的常见问题和建议

如果您的电子邮件服务发生变化，您应该怎么做？首先，将新的发件人添加到 SPF，使用新提供商设置 DKIM，测试发送，然后再关闭旧的服务，您不能仅仅“切换”服务并希望旧记录会自行失效。电子邮件基础设施喜欢精确，为域名设置电子邮件认证需要一个序列。

如果发送了几条消息，其中一些来自网站，而其他一些来自外部平台怎么办？那么，列出所有发件人的完整清单就很重要。对于一个网站，这可能包括 SMTP 插件、通知系统、邮件服务，甚至是一个单独的联系表单工具。清单越清晰，维护 SPF 和 DMARC 时就越容易避免冲突。

设置需要定期检查吗？是的。特别是如果您更改了主机、移动了域名、连接了新的 CRM 或更新了邮件系统。有时 DNS 记录会过时，仅仅是因为没有人再记得它们。而被遗忘的记录往往是错误的隐秘来源。

如果您不确定当前的电子邮件发送设置是否透明，考虑整体情况是有意义的：谁发送，谁签名，记录存储在哪里，谁负责更改。在更复杂的项目中，这成为整体支持和技术架构的一部分，而不是一个五分钟的“IT 任务”。

还有一个实用的小贴士：如果域名较旧且有许多不相关的发件人，不要急于启用严格的拒绝政策。首先收集数据，开启报告，去除不必要的内容，然后再逐步收紧政策，在电子邮件认证中，急于求成几乎总是会导致阻止你实际需要的邮件。

如果你想要一个不仅在地址栏中看起来不错，而且能够自信地通过邮件检查的域名，SPF、DKIM 和 DMARC 应该被视为项目的必要部分。这不是一种装饰性措施——而是保护你的品牌、建立信任并使邮件投递可预测的方法。实践证明，可预测性比任何华丽但脆弱的设置更有价值。