每天，攻击者都会发送数十亿封冒充知名品牌的邮件。伪造的发票、伪造的密码重置邮件、伪造的CEO请求——这些手段之所以奏效，是因为默认情况下任何人都可以在邮件的发件人字段中填入任意地址。SPF、DKIM和DMARC正是为了堵住这个漏洞而存在。三者结合，让邮箱服务商能够验证一封邮件是否真的来自它所声称的域名，并且它们已经悄然成为进入收件箱的门槛：自2024年2月起，Gmail和Yahoo要求所有发件人进行身份验证，并要求批量发件人完整配置SPF、DKIM和DMARC。本指南将逐一讲解每种协议的工作原理、您需要的确切DNS记录、悄悄破坏它们的常见错误，以及一份您本周就能执行的落地方案。
核心要点
SPF、DKIM和DMARC已不再是可选项。Gmail和Yahoo要求所有发件人进行身份验证，并对每天发送5,000+封邮件的发件人强制执行SPF、DKIM和DMARC。未经身份验证的邮件越来越多地在内容尚未被评估之前就被拒收——而身份验证只有与干净、经过验证的列表相结合，才能发挥最大效果。
为什么邮件身份验证很重要
核心问题在于，SMTP这个在互联网上传递邮件的协议，诞生于一个讲究信任的时代。它不会对可见的发件人地址进行任何身份核实。这一设计缺陷助长了大规模的钓鱼攻击和商业邮件诈骗（BEC）：美国联邦调查局（FBI）互联网犯罪投诉中心统计显示，仅2023年一年，已报告的BEC损失就高达29亿美元。当犯罪分子仿冒您的域名时，您的客户会被欺诈，而您的送达率也会受损——邮箱服务商根本无法区分您真实的营销邮件和仿冒邮件。
身份验证通过三种互补的基于DNS的协议来解决这个问题：
- SPF声明哪些服务器有权代表您的域名发送邮件
- DKIM对每封邮件进行加密签名，使篡改和伪造行为可被检测
- DMARC将两者与可见的发件人地址关联起来，并告诉接收方在验证失败时应如何处理
Gmail和Yahoo的强制要求
2024年2月，Google和Yahoo将一项长期以来的最佳实践变成了硬性要求。所有发件人都必须至少使用SPF或DKIM进行身份验证。向某个服务商每天发送量超过约5,000封邮件的发件人，必须同时具备SPF和DKIM，外加一份DMARC策略（至少为p=none）、与身份验证对齐的发件人域名、在两天内响应一键退订请求，以及低于0.3%的垃圾邮件投诉率。不合规的邮件首先会被临时错误延迟，随后会被直接拒收。微软已在2025年为Outlook.com的大批量发件人宣布了同等要求，因此整个行业的方向已毫无悬念。
普及率正在攀升，但远未达到全面覆盖：EasyDMARC对全球180万个顶级域名的分析发现，2025年只有47.7%拥有DMARC记录——而行业研究一致显示，已发布记录中有相当大一部分仍停留在仅监控的p=none策略上，并未提供任何实际的仿冒防护。把这件事做对，依然是一种竞争优势。
SPF：发件人策略框架（Sender Policy Framework）
SPF的工作原理
SPF是一条DNS TXT记录，列出了所有被授权代表您的域名发送邮件的服务器。当接收服务器接受一个连接时，它会查看Return-Path域名（也称为envelope from或MAIL FROM地址——不是您的收件人看到的发件人字段），获取该域名的SPF记录，并检查连接的IP是否在列表中。如果在列表中，SPF验证通过；如果不在，则根据您的策略，SPF会失败或软失败（soft-fail）。
记录语法详解
一家使用Google Workspace、一个营销平台和一个专用发送IP的公司，其典型的SPF记录看起来是这样的：
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"从左到右解读：
- v=spf1——版本标签；每条SPF记录都以它开头
- include:_spf.google.com——通过引用Google自己的SPF记录，授权Google Workspace的发送服务器
- include:servers.mcsv.net——授权一个营销平台（本例中是Mailchimp）
- ip4:203.0.113.10——授权一个特定的IPv4地址，例如您自己的SMTP服务器
- ~all——兜底规则：任何未列出的服务器都应软失败。限定符很关键：
-all是硬失败（建议在记录完整后使用），~all是软失败，而+all则授权整个互联网——切勿使用
10次DNS查询限制
RFC 7208将SPF评估限制在10次DNS查询以内。每个include、a、mx、ptr和exists机制都会被计入——而且include是递归计数的，因此单单一个营销平台的include就可能消耗三到四次查询。一旦超过限制，接收方就会返回permerror，许多服务商会将其视为SPF失败。纯粹的ip4和ip6机制不消耗查询次数，因此应尽量优先使用它们，移除不再使用的服务，并在确实需要接入很多服务商时考虑对SPF进行扁平化处理。
常见的SPF错误
- 发布多条SPF记录。一个域名必须有且只有一条以
v=spf1开头的记录。两条记录会产生永久性错误，导致验证失败。请将所有机制合并到单一记录中。 - 使用+all。这相当于告诉全世界任何服务器都可以冒充您发送邮件——实际上等于禁用了SPF，并将您的域名标记为配置错误。
- 遗漏某个发送服务。您的客服系统、账单系统和CRM都会发送邮件。如果它们不在记录中，它们发出的邮件就会软失败。
- 放任记录腐化。已停用的服务会留下悬空的include项，既浪费查询次数，又可能带来安全风险。
- 误以为SPF能覆盖可见的发件人地址。它只检查Return-Path。与发件人字段的对齐是DMARC的工作，这也是为什么仅靠SPF几乎无法阻止仿冒的原因。
DKIM：域名密钥识别邮件（DomainKeys Identified Mail）
DKIM签名的工作原理
DKIM为每封发出的邮件添加一个加密签名。您的发送服务器持有一个私钥，并对邮件正文加上部分选定的邮件头（发件人、主题、日期等）的哈希值进行签名。对应的公钥发布在您的DNS中，接收服务器用它来验证签名。有效的签名可以证明两点：该邮件已获得签名域名的授权，并且签名内容在传输过程中未被篡改。与SPF不同，DKIM签名在转发后依然有效，这使它成为两种机制中更具韧性的一种。
选择器与DNS记录
公钥存放在一个由选择器（selector）构建出的DNS名称下：selector._domainkey.yourdomain.com。选择器让多个密钥可以共存——每个发送服务一个，或者在轮换密钥时新旧密钥并存。一条已发布的密钥记录看起来是这样的：
s1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"而每封已签名的邮件都会带有一个引用该记录的邮件头：
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3... d=标签指明签名域名，s=标签指明选择器——两者结合，准确告诉接收方应该到哪里获取公钥。
密钥长度与轮换
- 使用2048位RSA密钥。1024位密钥被认为强度不足，部分服务商会因此降低评分；2048位是当前标准，也是Google推荐的长度。
- 定期轮换密钥。M3AAWG的最佳实践建议至少每六个月轮换一次DKIM密钥。将新密钥发布在新的选择器下，切换签名，几天后再停用旧记录。
- 用您自己的域名签名。许多平台默认使用自己的域名签名（这能验证邮件身份，但不会与您的发件人地址对齐）。请完成该平台的自定义域名DKIM配置，使
d=与您的域名一致。
DMARC：策略、报告与对齐
SPF和DKIM各自验证一件事，但两者都不会检查您的收件人实际看到的地址。DMARC补上了这个缺口：只有当SPF或DKIM通过验证，并且通过验证的域名与可见的发件人域名对齐时，一封邮件才算通过DMARC。DMARC还允许您发布一条策略，告诉接收方应如何处理验证失败的邮件，并为您提供报告，让您了解谁在以您的域名发送邮件——无论是合法的还是非法的。
DMARC记录与策略的逐步推进
DMARC是位于_dmarc.yourdomain.com的一条TXT记录。一条合理的初始记录如下：
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100" p=标签是这条记录的核心，它被设计为分阶段逐步收紧：
- p=none——仅监控。验证失败的邮件仍会正常投递，但您会收到报告。每次部署都应从这里开始。
- p=quarantine——验证失败的邮件被投入垃圾箱。使用
pct=逐步提高比例，例如p=quarantine; pct=25会将策略应用于四分之一的失败邮件。 - p=reject——验证失败的邮件被直接拒收。这是最终目标：提供完整的仿冒防护，也是启用BIMI的前提条件。
一条已强制执行的记录最终会是这样的：
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"rua与ruf报告
rua=标签用于请求聚合报告：每个接收服务商每天发送的XML摘要，显示哪些IP以您的域名发送了邮件、哪些通过验证、哪些未通过。这些报告不包含邮件正文内容，是发现被遗忘的发送服务的主要工具。ruf=标签用于请求失败（取证）报告——针对单封邮件的失败样本。很少有服务商发送此类报告，而且它们可能包含个人数据，因此大多数团队只依赖rua报告，并通过DMARC报告工具处理，而不是直接读取原始数据。
对齐：宽松模式 vs 严格模式
对齐是绝大多数真实DMARC失败案例发生的地方。aspf=和adkim=标签控制经过身份验证的域名需要与发件人域名匹配到什么程度。在宽松模式（r，默认值）下，子域名匹配即可通过——来自news.yourdomain.com的邮件可以与yourdomain.com对齐。在严格模式（s）下，域名必须完全一致。建议先从宽松模式开始；只有当报告显示不会破坏合法邮件时，才切换到严格模式。请记住：SPF对齐比较的是Return-Path域名，DKIM对齐比较的是d=域名，而DMARC只需要两者中的一个通过对齐验证即可通过。
三种协议一览
| 协议 | 证明什么 | DNS记录 | 失败原因 |
|---|---|---|---|
| SPF | 发送服务器已获得Return-Path域名的授权 | 位于域名根部的TXT记录，以v=spf1开头 | IP未列入名单、超过10次查询、邮件转发、存在多条记录 |
| DKIM | 邮件由该域名签名，且在传输过程中未被篡改 | 位于selector._domainkey的TXT记录，以v=DKIM1开头 | 密钥缺失或错误、内容被修改、密钥强度不足或已过期 |
| DMARC | 可见的发件人域名与SPF或DKIM验证通过的域名一致 | 位于_dmarc的TXT记录，以v=DMARC1开头 | SPF和DKIM均未通过与发件人域名的对齐验证 |
分步实施方案
- 盘点所有发送服务（第1周）。清点所有以您域名发送邮件的系统：邮件套件、营销平台、CRM、客服系统、账单系统、监控告警。漏掉一个，日后就会破坏它的邮件发送。
- 发布或修复SPF（第1周）。只保留一条记录，涵盖所有合法来源，查询次数不超过10次，以
~all结尾（之后再收紧为-all）。 - 在所有平台启用DKIM（第1-2周）。在盘点清单中的每个平台上启用自定义域名DKIM签名，使用2048位密钥，并用一封测试邮件逐一验证。
- 以p=none发布DMARC并配置rua报告（第2周）。不影响邮件投递——您只是在收集数据。
- 监控4-6周。每周审查聚合报告。修复所有未能对齐的合法来源；剩下持续失败的就是仿冒行为。
- 逐步收紧。切换到
p=quarantine; pct=25，逐步提升到pct=100，维持几周后再切换到p=reject。持续监控——新的工具和供应商会不断出现。
DMARC之外：关于BIMI的一点补充
一旦进入强制执行阶段，BIMI（Brand Indicators for Message Identification，品牌标识邮件识别）就能让参与的邮箱服务商在您的邮件旁显示经过验证的品牌标志。它要求DMARC处于p=quarantine或p=reject且pct=100，需要一个SVG格式的标志，而对于Gmail的蓝色认证对勾，还需要一份与注册商标绑定的Verified Mark Certificate（Google也接受Common Mark Certificate用于显示标志）。BIMI本身并不会直接改变过滤规则，但可见的信任标志能切实提升品牌识别度和互动率，也是完成整个DMARC历程后一份不错的回报。
身份验证+列表验证：完整的技术栈
这正是许多指南会跳过的部分：身份验证证明的是您是谁，而不是您的邮件是否受欢迎。邮箱服务商会同时参考这两个信号。一个身份验证做得完美无缺的发件人，如果向一份陈旧的列表群发邮件，依然会产生退信和垃圾邮件投诉，而Gmail自身0.3%的投诉率门槛无论您的DMARC策略如何都同样适用。高退信率损害的恰恰是身份验证本应保护的发件人信誉。
这就是为什么身份验证和列表卫生是同一套送达率策略的两个组成部分。AT Valid运行超过20项验证检查——包括语法、MX、SMTP、一次性邮箱和全收邮箱检测——准确率高达99.5%，确保您用DKIM签名的每一封邮件，背后都真的有一个真实的收件箱在等待。您可以通过API在采集环节即时验证，也可以借助Salesforce、HubSpot、Mailchimp、RD Station、Pipedrive、Zapier和webhook等原生集成，批量清理现有列表。我们的邮件送达率完整指南详细介绍了这两门学科如何相互强化。
AT Valid优势
经过身份验证的域名加上经过验证的列表，是目前最强的送达率组合。创建一个免费的AT Valid账户，即可获得200个免费积分，在DMARC报告陆续送达的同时清理您的列表。
结论
SPF、DKIM和DMARC共同构成了一套分层的身份体系：SPF授权发送服务器，DKIM为内容签名，DMARC将两者与您收件人看到的地址对齐，并强制执行验证结果。自Gmail和Yahoo的强制要求出台以来，它们已是基本要求，而非高级选项——路径也十分清晰：盘点您的发件人，发布SPF，启用2048位DKIM，先在p=none下监控，再收紧到p=reject。
把这项工作与持续的列表验证结合起来，您就能同时回答邮箱服务商提出的两个问题：这个发件人是否真实？这封邮件是否受欢迎？准备好补全您的送达率技术栈了吗？立即获取200个免费验证积分，亲自体验经过身份验证、经过验证的邮件带来的不同。