电子邮件认证是基础设施领域之一，在这个领域中，”我设置了它”和”它实际工作”之间的差距巨大，而”它工作”和”它工作良好”之间的差距则更为显著。开发者发布产品，配置 SPF 和 DKIM，因为他们的交易服务提供商的入职清单要求这样做，然后在数月后发现他们的密码重置邮件对相当比例的用户进入了垃圾邮件箱。邮件可送达性 SPF DKIM DMARC 设置背后的机制实际上并不复杂——但它们需要以正确的顺序理解协议链，而大多数教程只停留在语法层面，没有解释使决策显而易见的理由。
为什么邮件会进入垃圾邮件：真实情况
接收邮件服务器——以及越来越多的这些服务器咨询的声誉网络——通过组合信号来评估入站消息。认证是一个类别。发送声誉是另一个。内容分析是第三个。大多数工程师认为内容是主导因素，并据此进行优化，添加取消订阅标头并避免垃圾邮件触发词。实际上，对于从正确配置的域发送的交易邮件，失败或缺失的认证是进入垃圾邮件文件夹的最快途径。
认证三要素——SPF、DKIM 和 DMARC——旨在回答接收服务器在将消息路由到收件箱之前需要回答的三个问题：
- SPF：这条消息是否从域名所有者授权的服务器发送的？
- DKIM：这条消息是否由发送域名进行了加密签名，并且在传输过程中是否被篡改？
- DMARC：如果 SPF 或 DKIM 失败，接收方应该怎么做，以及如何强制执行对齐？
这些每个都在 DNS 和 SMTP 层独立运行。一条消息可以通过 SPF 但失败 DKIM，或者通过 DKIM 但失败 DMARC 对齐。理解失败模式需要先理解每个组件的独立运作，然后再理解它们如何相互作用。
SPF：在 DNS 中声明的授权发送者
SPF（发件人策略框架）通过在您的域名上发布一个 DNS TXT 记录来工作，该记录列出了被允许发送邮件的服务器，这些邮件声称该域名为它们的 MAIL FROM。当接收服务器接受入站消息时，它会查找信封发件人地址中域名的 SPF 记录，并检查发送服务器的 IP 是否包含在内。
一个最小的 SPF 记录如下所示：
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
v=spf1 前缀标识记录类型。每个机制（include:、ip4:、a、mx）都指定了授权发送者的来源。末尾的限定符 — -all、~all 或 ?all — 决定了不匹配任何机制的消息会发生什么：硬失败、软失败或中性。在生产环境中使用 -all。 软失败（~all）告诉接收方”可能未授权”，但许多系统将其视为允许。硬失败是唯一真正强制执行您的策略的信号。
10次查找限制
SPF 在评估过程中最多进行 10 次 DNS 查找。这是 RFC 7208 中定义的硬性限制，而非指导原则。每个 include:、a、mx、redirect= 和 exists 机制都会触发一次查找。ip4: 和 ip6: 机制不会，因为它们直接指定 IP 地址。
这个问题很快就会变得实际。单个 include:_spf.google.com 可能本身包含子引用，内部消耗 3-4 次查找。加上 SendGrid、Mailchimp、事务性邮件提供商以及您自己的邮件服务器，您在完成入职清单之前就已经达到了限制。超过 10 次查找会导致 SPF 返回 permerror，这与硬失败相同对待。
解决方案：定期使用 dmarcian 的 SPF Surveyor 或 MXToolbox 等工具扁平化您的 SPF 记录。这意味着将 include: 链替换为其已解析的 IP 范围作为静态 ip4: 块。权衡在于，当您的提供商更新其 IP 范围时，扁平化记录需要维护。一些提供商提供 SPF 宏语法或专门的扁平化服务来自动化此过程，如果您有三个以上的发送服务，这值得付费购买。
常见的 SPF 错误
- 同一域名上有两条 SPF 记录。 RFC 7208 要求每个主机名只能存在一条 SPF 记录。多个以
v=spf1开头的 TXT 记录会导致permerror。添加新的发送服务时，请编辑现有记录 — 不要创建第二条记录。 - SPF 记录放在了错误的域名上。 SPF 验证的是信封发件人（
MAIL FROM），而不是用户看到的From:头部。如果您的交易服务提供商从bounce.yourapp.com发送，那么 SPF 记录需要存在于bounce.yourapp.com上，而不仅仅是在yourapp.com上。 - 忘记子域名发件人。 SPF 不会被子域名继承。如果您从
notifications.example.com发送，该子域名需要有自己的 SPF 记录。 - 永久使用
~all。 软失败（soft fail）在初始测试阶段是合适的，但不应该作为永久策略。将~all视为”可能是垃圾邮件”的接收方最终会训练其过滤器相应地处理您的域名。
DKIM：能在转发中存活的加密签名
DKIM（DomainKeys Identified Mail）解决了 SPF 的一个局限性：SPF 在邮件转发时会失效，因为转发服务器的 IP 不在原始发件人的 SPF 记录中。DKIM 则改为在消息头和正文中附加加密签名，使传递链中的任何下游接收方都能使用发布在 DNS 中的公钥验证该签名。
发送服务器使用私钥生成签名，并将其作为 DKIM-Signature 头插入。该签名覆盖选定的头部（通常是 From:、Subject:、Date:、Message-ID:）和消息体的哈希值。接收服务器从 [selector]._domainkey.[domain] 的 TXT 记录中检索相应的公钥并验证签名。如果消息在传输过程中被修改或密钥不匹配，验证将失败。
选择器和密钥管理
DKIM DNS 路径中的选择器允许一个域同时发布多个 DKIM 密钥。这对于密钥轮换至关重要。当您轮换 DKIM 密钥时，您会在新选择器下发布新密钥，配置您的发送基础设施使用新密钥签名，并在经过一段传播延迟后才删除旧选择器。这可以防止在轮换窗口期间，使用旧密钥签名的在途消息验证失败。
常见的选择器命名约定是嵌入日期或版本：k1._domainkey、k2._domainkey 或 2024q1._domainkey。具体的命名并不重要；重要的是它是唯一的，并且您可以在整个发送基础设施中跟踪哪个密钥对应哪个选择器。
密钥长度很重要。RSA-1024已被弃用，不应使用——Gmail开始拒绝它，其他主要服务提供商也相继跟进。RSA-2048是当前的最小要求。Ed25519更紧凑且计算效率更高，但在较旧的接收软件中支持不完善。如果您的ESP支持两者，请在不同的选择器上发布一个Ed25519密钥和一个2048位的RSA密钥；发送服务器可以配置为先尝试Ed25519。
DKIM常见实际错误
- 未对From头中的所有内容进行签名。不包括
From:头的DKIM签名提供的保护较弱。大多数现代签名配置默认包含它，但请在您的ESP的DKIM配置面板中验证这一点。 - 在轮换前将DKIM密钥TTL设置得过高。如果您的DKIM TXT记录的TTL为86400，并且您开始使用新密钥进行签名，接收方可能会缓存旧密钥长达24小时，导致无法验证新签名。轮换前将TTL降至300。
- 使用第三方提供商而未验证DKIM是否已启用。一些ESP会自动启用SPF，但需要通过其控制面板手动配置DKIM。检查DKIM签名是否处于活动状态，而不仅仅是SPF委托。
DMARC：策略、对齐和可见性
DMARC（基于域的消息认证、报告和一致性）做两件事：通过对齐要求将SPF和DKIM与From:头域绑定，并告诉接收方如何处理未能通过该对齐检查的消息。它还启用聚合和法医报告，使域所有者能够了解其域名在互联网上的使用情况。
DMARC记录是在_dmarc.[域名]发布的TXT记录：
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s
策略级别
| 策略 | 效果 | 使用时机 |
|---|---|---|
p=none |
仅监控。对失败的邮件不采取任何行动。 | 初始部署。在强制执行前收集报告。 |
p=quarantine |
失败的邮件进入垃圾邮件文件夹。 | 在确认合法邮件通过后。中间强制执行阶段。 |
p=reject |
失败的邮件在SMTP层被拒绝。 | 完全强制执行。所有发送域的目标状态。 |
从 none 到 reject 的路径应该是谨慎规划的。从 none 开始，设置聚合报告处理，并花上两到四周的时间了解哪些来源正在发送声称来自您域名的邮件。只有在确认所有合法发送者都已通过身份验证后，才应移至 quarantine，然后再到 reject。
对齐模式
DMARC 对齐要求通过 SPF 或 DKIM 的域名与 From: 标头中的域名匹配。宽松对齐（aspf=r，默认设置）允许组织域名匹配 — mail.example.com 与 example.com 对齐。严格对齐（aspf=s）要求完全匹配。
严格对齐是更安全的方式，但需要更仔细的配置。如果您的交易服务提供商出于退回跟踪的目的从您的子域发送邮件，严格的 SPF 对齐将会失败。在设置严格模式之前，请了解您的发送基础设施实际使用的是什么。
聚合报告
rua= 标签指定聚合报告（XML 文件，总结了所有声称来自您域名的邮件的身份验证结果）应发送的位置。这些报告是发现未经授权使用您的域名并确认所有合法发送来源已正确身份验证的唯一可靠方式。
在任何数量下处理原始 DMARC XML 都不切实际。使用 DMARC 报告服务：dmarcian、Valimail 或 Postmark 的 DMARC 监控。所有服务都提供免费层级，足以满足大多数独立开发者和小型团队的需求。价值在于可见性 — 您将发现营销自动化工具、CRM 平台和遗留邮件脚本正在从您的域名发送邮件，而您当前的 SPF 记录并未涵盖这些。
谷歌和雅虎 2024 年要求
2024 年 2 月，谷歌和雅虎对批量发送者（每天向 Gmail 或雅虎账户发送超过 5,000 封邮件的发送者）实施了新要求。这些要求将多年来已被视为最佳实践指导的内容正式化：
- SPF 或 DKIM 必须通过（强烈建议两者都通过）
- DMARC 至少必须发布
p=none From:域名必须与 SPF 或 DKIM 对齐- 营销邮件需要包含退订标头（
List-Unsubscribe和List-Unsubscribe-Post） - 必须在两天内执行一键退订
- 垃圾邮件投诉率必须保持在 0.3% 以下（目标为 0.1%）
对于事务性邮件的实际影响是，许多忽视 DMARC 的发件人突然发现邮件投递率在 Gmail 地址上下降了。每天 5,000 封邮件的门槛比听起来要低——一个拥有几千活跃用户的 SaaS 服务，仅通过密码重置、通知和每周摘要的组合就很容易超过这个数字。即使低于此阈值的发件人也观察到，缺少 DMARC 与垃圾邮件分类增加之间存在相关性。
正确的应对方式不是纯粹为了合规而添加 p=none 的 DMARC。正确的应对方式是将此视为实际达到 p=reject 的推动因素。
事务性邮件服务：诚实比较
ESP（邮件服务提供商）的选择会影响投递率、开发体验和运营复杂度。主要的事务性邮件选项各有值得了解的真实权衡。
Resend
Resend 于 2023 年推出，面向开发者，提供了 React Email 集成和感觉现代化的 API。DKIM 签名是自动处理的。他们在共享 IP 上的投递率对于大多数用例来说都很好，他们的仪表板提供了真正有用的每封邮件日志，便于调试。弱点是：他们是较新的服务，因此其共享 IP 的声誉历史比 Postmark 或 SES 更浅，而且他们的专用 IP 服务的最低发送量要求相对于成本更高。对于开发体验重要且月发送量在 10 万封以下的新项目，这是一个强有力的选择。
Postmark
Postmark 在共享 IP 服务提供商中拥有最佳的事务性邮件投递声誉。他们的业务建立在严格的发件人政策基础上——他们拒绝批量邮件和营销邮件，保持共享 IP 的清洁，专门用于事务性邮件。他们的退件处理和垃圾邮件投诉处理都很全面。API 文档完善。每条消息比 SES 更贵，但对于密码重置投递率至关重要的应用来说，这种投递率的溢价是值得的。
Amazon SES
SES 是价格领导者。每 1,000 封邮件 0.10 美元，并且实际上没有发送量限制，它是基于 AWS 基础设施构建的高发送量发件人的默认选择。权衡之处在于 SES 的共享 IP 是混合使用的——营销邮件和事务性邮件发件人共存——因此共享 IP 的声誉不如 Postmark 那样可预测。SES 奖励那些配置了专用 IP 并谨慎管理自己声誉的发件人。配置开销更高：DKIM 设置需要通过 SES 控制台或 CDK 手动创建 DNS 记录，而且新账户的沙盒模式意味着您需要明确请求生产访问权限。对于已经在 AWS 上且月发送量超过 50 万封的团队来说，SES 很难被替代。
SendGrid
SendGrid（现为 Twilio SendGrid）是当前的市场领导者。它功能正常，API 文档完善，并且跨平台有广泛的集成支持。诚实的评价：他们的共享 IP 可送达性历史上比 Postmark 更不稳定，定价层级不如看起来那么透明，而且对于低层级客户，他们的支持响应时间比替代方案更慢。如果 SendGrid 运行良好，没有理由迁移，但对于新项目，有更好的默认选择。
域名预热：为什么新域名需要它
接收服务器和声誉网络对新的域名或新的发送 IP 没有任何历史记录。没有历史记录被视为可疑历史。无论身份验证设置如何，第一天从新域名发送 10,000 封邮件都会触发速率限制、垃圾邮件分类或来自主要服务提供商的直接屏蔽。
预热过程涉及在两到六周内逐步增加发送量，从您参与度最高的用户（那些最有可能打开和互动的用户）开始，仅发送高优先级事务性邮件。大致的时间表：
- 第一周： 每天 50-200 条消息，仅限参与度最高的收件人
- 第二周： 每天 500-1,000 条消息，扩展到确认选择加入的用户
- 第三至四周： 每天 5,000-10,000 条消息，完整的事务性邮件量
- 第五至六周： 如适用，完整的营销邮件量
全程监控垃圾邮件投诉率。预热期间投诉率超过 0.1% 表示列表卫生存在问题，随着邮件量增加，问题会恶化而非改善。Google Postmaster Tools 提供 Gmail 收件人的投诉率数据，应该是您预热期间的主要指标。
专用 IP 与共享 IP
共享 IP 意味着您的发送声誉部分取决于同一 IP 范围内的其他发送者。在信誉良好的 ESP（电子邮件服务提供商）中，事务性邮件的共享 IP 通常没问题——ESP 会积极管理其发送者基础。专用 IP 的论点是您可以完全控制自己的声誉。
在以下情况下，专用 IP 是合理的选择：
- 您的发送量足以维持一个预热好的 IP（通常每月超过 50,000 封邮件，且每日发送量稳定）。使用不一致的专用 IP 比信誉良好的共享 IP 更差。
- 您有运营能力来监控 IP 声誉，主动处理黑名单条目，并在添加新 IP 时管理预热过程。
- 您的可送达性要求证明额外成本是合理的（大多数 ESP 的专用 IP 通常为每月 20-30 美元）。
每月邮件量低于 50,000 封时，Postmark 或 Resend 上的信誉良好的共享 IP 优于没有可送达性专业知识团队管理的专用 IP。良好维护的共享池所带来的声誉是一项优势，而非限制。
监控工具
Google Postmaster Tools提供发送至 Gmail 的邮件的域名声誉、IP 声誉、垃圾邮件率和认证通过率。免费。设置需要在您的域名中添加 TXT 验证记录。如果您向 Gmail 地址发送任何数量的邮件，这是必不可少的。域名声誉仪表板是您了解 Gmail 如何分类您域名级别声誉的最直接指标。
MXToolbox是快速 DNS 记录检查和黑名单检查的首选工具。他们的 SuperTool 可以在一个视图中检查 SPF、DKIM、DMARC 和 MX 记录。黑名单监控会在您的发送 IP 出现在任何主要黑名单时发出警报。免费版本足以满足大多数使用场景。
dmarcian提供 DMARC 汇总报告解析、用于简化分析的 SPF 调查工具和域名健康检查。他们的 DMARC 管理工作流程是专用工具中最清晰的。免费版本限制每月处理的域名记录数量，但对于每月发送量低于 100,000 的域名来说是可行的。
Mail-Tester(mail-tester.com)在初始设置时很有用。向他们的独特地址发送测试消息，并获得包含 SPF、DKIM、DMARC、内容分析和邮件头清洁度方面的具体诊断反馈的评分。这不是持续监控的替代方案，但对初始验证很有帮助。
当所有配置正确但邮件仍进入垃圾箱时
这是最令人沮丧的邮件可送达性问题类别，因为解决方案从协议配置转向了声誉管理。认证通过是邮件进入收件箱的先决条件，而非保证。
按以下顺序进行诊断：
- 检查 Google Postmaster Tools 的域名声誉。 “低”或”差”的评级意味着 Gmail 除了单个消息信号外，还与您的域名有历史记录。这是尽管通过身份验证但仍持续被归类为垃圾邮件的最可能原因。
- 通过 MXToolbox 检查 IP 黑名单状态。 如果 IP 地址被列入 Spamhaus、SORBS 或其他主要黑名单，将导致广泛投递失败。使用专用 IP 的用户需要积极监控这一点。
- 检查垃圾邮件投诉率。 如果您在 Gmail 或 Yahoo 上的投诉率超过 0.1，无论身份验证状态如何，都会被算法性地归类为垃圾邮件。解决方案是列表清理，而不是 DNS 配置。
- 验证 DMARC 对齐，而不仅仅是通过。 SPF 通过但 DMARC 未对齐（因为
From:域名与 SPF 通过的信封发件人不匹配）可能会导致分类问题，即使各个机制都通过了。查看已投递消息的Authentication-Results:标头，了解确切通过的内容和对齐情况。 - 检查内容和发送模式。 极低的打开率向邮箱提供商表明收件人不需要这些邮件。清理列表、取消不活跃订阅者的订阅，并将邮件定向给有参与证明的用户，是声誉恢复的长期解决方案。
在确认身份验证和 IP 声誉干净后仍然存在的投递问题，几乎总是列表质量问题。发送更少的邮件给更活跃的收件人，声誉就会改善。在这方面没有技术捷径。
身份验证设置是一个已有明确正确答案的已解决问题。拥有配置身份验证的开发者与正确配置身份验证的开发者之间的差距——严格 SPF 并维护查找计数、使用可轮换选择器管理的 DKIM、DMARC 向 p=reject 进展并具有汇总报告可见性——才是真正赢得收件箱位置的地方。正确设置协议，选择共享 IP 声誉符合您用例的事务性服务提供商，并将投递监控视为持续运营问题而非一次性设置任务。
关键要点
- SPF、DKIM 和 DMARC 分别解决不同的身份验证问题。三者都需要，不能相互替代。
- SPF 的 10 次查询限制是一个实际的操作约束，而非边缘情况。随着发送基础设施的增长，请监控并简化记录。
- DMARC 设置为
p=none是起点。p=reject是目标。这条路径需要聚合报告监控，以在强制执行前确认所有合法发送者都已通过身份验证。 - Google 和 Yahoo 2024 年的要求是最低基准线—它们描述的是下限，而非上限。
- Postmark 注重可靠性，SES 注重发送量和成本，Resend 注重开发者体验—每个都有其真正的优势。
- 专用 IP 需要足够的流量和运维关注才能超越信誉良好的共享 IP 池。
- 通过身份验证后仍被持续归类为垃圾邮件，几乎总是列表卫生或发送信誉问题，而非 DNS 问题。
常见问题
我是否需要全部三种—SPF、DKIM 和 DMARC？
是的。仅 SPF 身份验证信封发件人，但不验证可见的 From: 地址。仅 DKIM 不为接收方提供关于如何处理未验证邮件的策略信号。DMARC 将它们与 From: 域绑定并提供策略执行。Google 2024 年的要求使 DMARC 成为批量发送者的强制要求，并且趋势是要求所有发送类别都采用 DMARC。
SPF 和 DKIM 的更改需要多长时间才能传播？
DNS 传播取决于 TTL 设置和解析器缓存。如果 TTL 为 3600（一小时），请计划在更改全球可见前等待最多一小时。在更改前 24 小时将 TTL 减少到 300 秒，可以最小化传播窗口。通过 MXToolbox 或 dnschecker.org 确认更改已全球传播后，将 TTL 恢复为正常值。
我应该从哪种 DMARC 策略开始？
从 p=none 开始，并配置聚合报告投递（rua= 标签）到您实际监控的邮箱或 DMARC 报告服务。经过两到四周的报告分析，确认所有合法发送者都通过身份验证后，迁移到 p=quarantine。在另一个监控期间，如果没有合法邮件进入隔离区，再迁移到 p=reject。
我的事务性服务提供商自动设置 DKIM—我还需要做些什么吗？
验证设置。许多提供商会添加指向其自身 DKIM 密钥的 CNAME 记录，这意味着他们使用自己的基础设施代表您进行签名。这通过了 DKIM 验证，但也意味着提供方控制着签名密钥。对于安全性要求更高的应用，请考虑通过独立生成密钥并配置提供方使用这些密钥来拥有自己的 DKIM 密钥。对于大多数用例，提供方管理的 CNAME 方法是实用且可接受的。
我可以将同一域名用于营销邮件和事务性邮件吗？
可以，但将它们分离到不同的子域名（mail.example.com 用于事务性邮件，news.example.com 用于营销邮件）是更好的架构。本质上，营销邮件的投诉率高于事务性邮件。子域名分离意味着高投诉率的营销活动不会损害事务性邮件的发送声誉。两个子域名都需要自己的 SPF、DKIM 和 DMARC 记录。