别再猜你的 DNS：面向开发者的 MX、SPF、DKIM 和 DMARC 导览
电子邮件认证记录看起来晦涩，但并不神秘。本文说明每种记录实际做什么，以及如何配置它们而不破坏投递。
目录
为什么电子邮件 DNS 记录现在很重要
电子邮件认证过去是可选项。到 2026 年，它已经是基本门槛。Gmail 和 Outlook 都会对批量发件人强制执行 SPF 和 DKIM，而 DMARC 也正迅速成为任何发送事务性邮件的域名的必备项。如果你的 DNS 记录有误，你的邮件就到不了——没有退信，没有警告，只有沉默。
问题在于，这些记录的文档写得像 RFC，而不像工具说明。大多数开发者会从邮件服务商的设置指南里复制粘贴示例，然后寄希望于一切正常。这在你需要排查问题、添加第二个发信服务，或向客户解释为什么他们的联系表单邮件进了垃圾箱之前都还行。
本指南会按照你实际遇到它们的顺序，讲解 MX、SPF、DKIM 和 DMARC：既有足够的细节帮助你正确配置，也有足够的上下文帮助你在出问题时调试。
MX 记录：入站邮件去哪里
MX 记录告诉互联网哪些邮件服务器接受发往你域名的邮件。它们是这四类记录中最简单的，但也最容易配置错误。
一条 MX 记录包含两部分：优先级数字和主机名。优先级数字越低，越先尝试。如果你使用 Google Workspace，你的 MX 记录可能看起来像这样：
example.com. MX 1 aspmx.l.google.com.
example.com. MX 5 alt1.aspmx.l.google.com.
example.com. MX 5 alt2.aspmx.l.google.com.末尾的点很重要——它们表示该主机名是完全限定的。大多数 DNS 提供商会自动添加，但并非全部都会。
常见错误包括：把 MX 记录指向 A 记录而不是主机名，把所有优先级都设成相同数字（这会让备份失去意义），或者在迁移服务商时忘记删除旧的 MX 记录。过期的 MX 记录并不会无害地待在那里——它们可能导致邮件循环，或让投递分散到两个收件箱。
如果你在运行自己的联系表单，并希望在不依赖第三方服务的情况下避免垃圾邮件，了解表单如何成为垃圾邮件载体是一个有用的起点。
SPF：哪些服务器被允许以你的身份发送邮件
SPF（Sender Policy Framework）是一条 TXT 记录，用于列出被授权代表你的域名发送邮件的 IP 地址和域名。当邮件服务器收到一封声称来自你的邮件时，SPF 通常是它执行的第一项检查。
一条基本的 SPF 记录如下：
v=spf1 include:_spf.google.com ~all拆开来看：
v=spf1声明 SPF 版本include:_spf.google.com委托给 Google 的 SPF 记录~all是软失败——拒绝来自未列出来源的邮件，但不要过于严格
你也可以使用 ip4: 或 ip6: 将特定地址加入白名单，或使用 a 和 mx 引用你域名的 A 记录和 MX 记录。末尾的 all 机制控制来自未列出来源的邮件会发生什么：-all 是硬失败（拒绝），~all 是软失败（标记为可疑），?all 是中立（不表态），而 +all 是完全放开（不要使用）。
SPF 有两个锋利的边缘。第一，邮件被转发时它会失效，因为转发服务器不在你的 SPF 记录中。第二，SPF 记录有十次 DNS 查询的查找限制。如果你包含了太多第三方服务，就会超过这个限制，SPF 将停止工作。解决办法是扁平化你的 SPF 记录——用实际 IP 段替换 include: 指令——但当服务商变更 IP 时，这需要维护。
DKIM：发件人身份的加密证明
DKIM（DomainKeys Identified Mail）会为你的出站邮件添加数字签名。接收服务器会用发布在你 DNS 中的公钥检查签名。如果签名有效，并且邮件未被篡改，DKIM 就会通过。
与 SPF 不同，DKIM 可以经受转发，因为签名会随邮件一起传递。它也更灵活——你可以为不同的发信服务配置多个 DKIM 密钥，每个密钥都有自己的 selector。
一条 DKIM DNS 记录如下：
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."selector（此例中为 default）是任意的——由你的邮件服务商选择。p= 的值是公钥，通常是一段很长的 base64 编码字符串。你的邮件服务商会生成私钥，并用它为外发邮件签名。
DKIM 设置几乎总是由你的邮件服务商处理。你的工作是复制他们给你的 TXT 记录，并粘贴到你的 DNS 中。棘手之处在于，一些 DNS 提供商不能很好地处理很长的 TXT 记录——它们要么截断记录，要么要求你把值拆分成多个带引号的字符串。
要验证 DKIM 是否正常工作，向一个 Gmail 地址发送测试邮件并检查邮件头。在 Authentication-Results 头中查找 dkim=pass。
DMARC：策略执行与报告
DMARC（Domain-based Message Authentication, Reporting and Conformance）把 SPF 和 DKIM 连接起来，并告诉接收服务器在认证失败时该怎么做。它还启用报告功能，让你看到谁在以你的域名发送邮件——包括合法发送和伪造发送。
一条最小化的 DMARC 记录如下：
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"p=none表示仅监控——不要拒绝或隔离失败的邮件rua=mailto:[email protected]指定聚合报告的发送地址
一旦你确信 SPF 和 DKIM 正常工作，就可以把策略收紧为 p=quarantine（将失败邮件送入垃圾箱）或 p=reject（直接退回）。你还可以用 sp= 设置子域名策略，并用 pct= 指定策略应用到多少比例的邮件。
DMARC 报告是由主要接收方每天发送的 XML 文件。原始内容很冗长且难读，但它们会准确告诉你哪些邮件通过或未通过认证，以及原因。如果你看到合法邮件被拒收，报告会显示是哪项 SPF 或 DKIM 检查失败。
一个容易踩坑的点：DMARC 要求对齐。对于 SPF，Return-Path 头中的域名必须与 From 头中的域名匹配（或是其子域名）。对于 DKIM，DKIM 签名中的 d= 域名必须与 From 域名匹配。如果你使用第三方发信服务，它们需要支持使用你的域名作为自定义 return path，或使用你的域名进行 DKIM 签名，而不是它们自己的域名。
如何审计你当前的配置
大多数 DNS 问题在造成故障之前都是不可见的。下面是在出问题前检查记录的方法：
- 查询你的 MX 记录：
dig MX example.com应返回你的邮件服务器主机名和优先级。确认它们与你邮件服务商的文档一致。
- 检查 SPF 语法：
dig TXT example.com并查找v=spf1记录。用 SPF 验证器检查它，以捕获语法错误和查找限制违规。
- 验证 DKIM 密钥：发送一封测试邮件并检查
DKIM-Signature头。提取 selector 和 domain，然后查询dig TXT selector._domainkey.example.com，确认公钥存在。
- 验证 DMARC 策略：
dig TXT _dmarc.example.com应返回你的 DMARC 记录。确保rua=指向一个你确实会监控的地址。
- 端到端测试：使用 mail-tester.com 这样的服务，或发送到 Gmail 地址并检查完整邮件头。在
Authentication-Results头中查找spf=pass、dkim=pass和dmarc=pass。
如果你正在调试邮件为什么没有到达，邮件头是你最好的工具。大多数邮件客户端都允许查看原始邮件头——在 Gmail 中，打开邮件，点击三个点，然后选择“显示原文”。Authentication-Results 头会准确告诉你哪项检查失败以及原因。
何时使用子域名策略
如果你从多个子域名发送邮件——例如用 newsletter.example.com 做营销邮件，用 app.example.com 做事务性邮件——你可以为每个子域名设置 DMARC 策略。这样你可以对自己控制的子域名执行严格策略，同时在主域名上保持更宽松的策略。
代价是复杂度。每个子域名都需要自己的 SPF、DKIM 和 DMARC 记录，你还需要跟踪哪些发信服务被授权用于哪些子域名。对大多数小团队来说，一个配置良好的单一域名更简单，也同样安全。
认证失效时该怎么办
最常见的失败模式是在未更新 DNS 的情况下添加新的发信服务。如果你开始使用新的事务性邮件服务商，需要添加它们的 SPF include 或 IP 段，配置使用你域名的 DKIM 签名，并验证 DMARC 对齐。
第二常见的问题是转发。如果用户把你的邮件转发到另一个地址，SPF 会失败，因为转发服务器不在你的 SPF 记录中。DKIM 通常能经受转发，因此只要 DKIM 通过，并且你的 DMARC 策略允许部分对齐，邮件仍应被投递。如果你看到转发邮件被拒收，请检查你的 DMARC 策略——带严格对齐的 p=reject 会破坏转发。
第三个问题是 DNS 传播。DNS 记录变更可能需要数小时才能传播，而且不同邮件服务器缓存记录的时长也不同。如果你刚更新了一条记录但它还没生效，等几个小时后再测试。你可以使用 whatsmydns.net 这样的工具检查传播情况。
关键要点
- MX 记录路由入站邮件；SPF、DKIM 和 DMARC 认证出站邮件。它们解决不同问题，而你四者都需要。
- SPF 在转发时会失效，并且有十次查找限制。DKIM 能经受转发，但需要按服务配置。DMARC 将它们连接起来并启用报告。
- 在 DMARC 中从
p=none开始，监控报告几周；当你确信合法邮件都能通过后，再收紧到p=quarantine或p=reject。 - DNS 错误是无声的。用真实邮件测试你的配置，并检查邮件头，以确认 SPF、DKIM 和 DMARC 都已通过。
- 如果在添加新的发信服务后认证失效，请检查 SPF includes、DKIM selectors 和 DMARC 对齐。邮件头会告诉你哪项检查失败。
FAQ
Q: Can I have multiple SPF records?
A: 不可以。多条 SPF 记录会导致它们全部被忽略。如果你需要授权多个服务，请在单条 SPF 记录中使用 include: 指令，或直接列出 IP 段。注意十次查找限制。
Q: Do I need DMARC if I'm only sending a few emails a day?
A: 需要。DMARC 关注的不是数量——而是证明你就是你声称的身份。即使是小域名也能从 DMARC 中受益，因为它可以防止伪造，并让你了解投递问题。从 p=none 和一个报告地址开始。
Q: What happens if DKIM and SPF both fail but the email looks legitimate?
A: 这取决于你的 DMARC 策略。如果是 p=none，邮件会带着警告被投递。如果是 p=quarantine，它会进入垃圾箱。如果是 p=reject，它会被退回。这就是为什么你应该在执行严格策略之前监控 DMARC 报告——你可能存在自己并不知道的合法发送方。
Q: Can I use the same DKIM key for multiple domains?
A: 技术上可以，但不要这样做。每个域名都应有自己的 DKIM 密钥对。共享密钥会让轮换更困难，并在私钥泄露时扩大影响范围。
Q: How often should I rotate DKIM keys?
A: 没有通用规则，但对大多数域名来说，每年一次是合理的。如果你怀疑某个密钥已经泄露，请立即轮换。确保在开始用新私钥签名之前，先在 DNS 中发布新的公钥，并在轮换后将旧密钥在 DNS 中保留几天，以处理延迟邮件。
<!-- tool-cta:start -->
💡 试试这个： 使用 DMARC Lookup 检查任意域名已发布的策略，了解 MX、SPF 和 DMARC 记录在实践中如何配合使用。
<!-- tool-cta:end -->
Sources
- RFC 7208: Sender Policy Framework (SPF) — SPF 规范，包括语法规则和十次查找限制。
- RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM 规范，涵盖签名生成与验证。
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC 规范，包括策略语法和聚合报告格式。
- Google Workspace: Prevent spoofing and spam — 面向 Google Workspace 域名的 SPF、DKIM 和 DMARC 配置实践指南。
常见问题
我可以有多条 SPF 记录吗？
如果我每天只发送几封邮件，还需要 DMARC 吗？
如果 DKIM 和 SPF 都失败，但邮件看起来是合法的，会发生什么？
我可以为多个域名使用同一个 DKIM 密钥吗？
我应该多久轮换一次 DKIM 密钥？
来源与进一步阅读
