SPF/DKIM/DMARC 没配好，邮件为什么进垃圾箱

邮件进对方垃圾箱、而你又收不到任何退信，最常见的原因是发信域名的身份认证没配全。 收件方的反垃圾系统在决定邮件去向时，先看域名有没有通过 SPF、DKIM、DMARC 三项验证；三项缺失或配错，你的邮件在过滤器眼里与批量伪造发信是一样的。

一、反垃圾过滤器在收件前做了什么

反垃圾过滤不是一条规则，而是分层计分：每封邮件在进收件箱之前要过连接层、认证层、内容层，任何一层得分偏低都可能被判去垃圾箱。

理解这套分层的实际用途是避免排查方向跑偏——如果问题出在连接层或内容层，无论怎么改 SPF 记录都不会好转。

1.1 连接层：看发信 IP 本身

这一层与你的域名配置无关，只看发信 IP：

最常见的踩坑场景：直接用云服务器默认分配的公网 IP 自建邮件服务器发信，而该 IP 没有配置 PTR 记录——在连接层就会被标记为可疑来源。用邮箱服务商的发信通道则不存在这个问题，因为 PTR 由服务商维护。

1.2 认证层：看域名的三项记录

这一层核验发件域名在 DNS 中的 SPF、DKIM、DMARC。三项不是独立评分，而是有依赖关系：DMARC 的最终裁决要求 SPF 或 DKIM 至少一项通过且与 From 域对齐 [3]。

如果把整套过滤比作机场安检：连接层是进航站楼时的外围核验，认证层是登机口的证件比对，内容层是行李扫描。三道各查一件事，任何一道不过都走不到下一步。

1.3 内容层：看邮件本身

扫描正文关键词、链接域名信誉、图片与文字比例。几种常见扣分项：

所以会出现一种情况：SPF、DKIM、DMARC 全部 pass，邮件仍被投到垃圾箱或促销标签页。此时要查的是内容层，不是继续改 DNS。

这也说明三项认证是进收件箱的入场券，但不是充分条件。认证通过说明“这封邮件确实来自你声称的域名”，不说明“这封邮件的内容可信”——两件事分别由认证层和内容层负责。

二、SPF：授权谁才能用你的域名发信

SPF（Sender Policy Framework）在域名的 DNS 里发布一条 TXT 记录，声明哪些 IP 或服务器有权用该域名发信。收件方查询这条记录，比对实际发信 IP 是否在授权范围内 [1]。

相当于给域名列一份“可信发信人名单”，不在名单上的发信源都视为可疑。

2.1 记录怎么写

一条典型记录：

各段含义 [1]：

段	作用
v=spf1	协议版本标识，必须在最前
include:	引入另一个域名的 SPF 记录（用于授权第三方发信平台）
ip4: / ip6:	直接指定允许的 IP 地址或网段
a	允许该域名 A 记录对应的 IP 发信
mx	允许该域名 MX 记录对应的服务器发信
-all / ~all / ?all	结尾策略，见 2.3

对多数企业，用 include 引入邮箱服务商的 SPF、再用 ip4 列出自有发信服务器，是最常见的组合。

2.2 一条硬限制：DNS 查询不能超过 10 次

RFC 7208 对 SPF 解析设了硬性上限：单次验证过程中触发的 DNS 查询不得超过 10 次，超出则返回 permerror，整条 SPF 验证失败 [1]。

include 会递归展开，每一层都算查询次数。当企业同时接入邮箱服务、CRM、工单系统、营销平台，每个平台的 SPF 记录内部又各自嵌套若干条，累计次数很容易触顶。

两种解法：

子域隔离还有一个附带好处：如果营销邮件的发信 IP 被列入黑名单，受影响的只是营销子域的信誉，不会波及主域的交易邮件。

阿里邮箱的官方文档也强调了同一方向的约束：一个域名只能有一条 SPF 记录，多个发信来源必须合并进同一条、用多个 include: 串联，而不是新增第二条 TXT；官方另外专门提醒 ip4 不要误写成 ipv4，且 include 的 IP 段范围不宜开得过大，否则存在被仿冒发信的风险 [4]。

2.3 结尾策略：-all 与 ~all 的实际差别

标记	含义	收件方通常怎么处理
-all	严格拒绝（邮件头里的结果值是 fail，不是 hardfail）	未授权服务器发出的邮件应被拒收
~all	软失败（soft fail）	不直接拒收，但扣信任分，多数落入垃圾箱
?all	中立	等同于没表态，几乎不提供保护

选择本质是安全性与灵活性的权衡：-all 不给伪造者留余地，但一旦漏掉某个合法发信源，正常邮件会被拒收；~all 多一层缓冲，代价是伪造邮件不会在 SPF 层被彻底阻断。

过渡期的稳妥做法：先用 ~all，同时开启 DMARC 聚合报告观察各发信源的通过情况，确认覆盖完整后再切到 -all。

2.4 SPF 管不到的事

SPF 只解决“发信服务器是否被授权”，它不加密内容、不防篡改。

还有一处更关键的边界：SPF 验证的是信封发件人（Return-Path／smtp.mailfrom）的域，不是用户在客户端里看到的 From 头部域 [1]。这意味着攻击者可以让信封域通过 SPF、同时在 From 头伪造一个你的域名——SPF 本身识别不了这种情况。

把这个缺口补上的是 DMARC 的对齐要求，见第四节。

发信来源固定、不希望被仿冒的企业用 -all，安全性最高。发信来源较多、还在逐步梳理的阶段用 ~all 更稳，避免漏掉某个合法发信源导致正常邮件被拒收。判断标准不是“哪个更好”，而是“是否已确认所有第三方代发服务（CRM、工单、营销自动化、ERP）的发信 IP 或域名都进了 SPF 记录”——确认了就切 -all，没确认就先留 ~all 并用 DMARC 聚合报告核对。

三、DKIM：让每封邮件带上可验证的签名

SPF 解决了“谁有权发”，但拦不住邮件在传输途中被改。DKIM（DomainKeys Identified Mail）补的是完整性这一层 [2]。

流程是：发件服务器用私钥对指定的邮件头部与正文计算签名，附在邮件头里；收件方按签名中标示的选择器去查发件域的 DNS 取公钥，重新计算并比对。一致则说明内容未被篡改 [2]。

签名覆盖的不只是正文，还包括 From、Subject、Date 等关键头部字段——改动其中任何一项都会导致验签失败 [2]。私钥始终在域名所有者手里，所以中间人即使截获邮件，改完也无法重新生成有效签名。

3.1 公钥怎么发布

公钥以 TXT 记录发布，记录名格式为 选择器._domainkey.域名 [2]，例如：

这个设计允许同一域名下并存多个密钥，对应不同发信系统或不同轮换周期。

选择器命名建议按“系统 + 年份”来，例如 mail2026._domainkey 表示自建邮件服务器 2026 年配置的密钥、crm2026._domainkey 表示 CRM 平台的密钥。这样做的收益在排障时才显现：验签失败时能直接从选择器定位到是哪个发信系统的问题，不必逐台服务器排查。

3.2 签名算法

算法	特点	建议
rsa-sha256	兼容性最好，主流服务商普遍支持	优先使用
ed25519-sha256	椭圆曲线算法，密钥更短、强度更高	可作为增强项额外配置，但部分老系统不识别

密钥长度目前推荐 2048 位。仍在使用 1024 位的系统建议安排轮换——密钥越短，被穷举的理论门槛越低。

3.3 两个高频失效原因

一是密钥轮换后没同步更新 DNS 公钥。 只把新私钥部署到发信服务器、忘了发布对应的新公钥，收件方拿旧公钥验新签名，必然失败。麻烦之处在于邮件照样能发出去，发件人毫无察觉，直到域名信誉逐步下滑、大批邮件被判垃圾才发现。

二是多套发信系统共用域名时漏配某个选择器。 例如自建服务器配了 mail._domainkey，第三方营销平台的 crm._domainkey 忘了配——从营销平台发出的邮件就完全没有签名。

阿里邮箱官方文档给出了 DKIM 签名无效时的三个检查点：公钥是否被换行或空格截断、选择器名称是否与后台一致、以及在 1024 位与 2048 位之间切换过的，需要重新配置最新记录值并重新进入配置界面以触发服务端加签生效 [4]。第三条最容易漏——改过密钥长度却没回配置界面确认，签名不会生效。

3.4 部署后怎么验

向不同服务商的邮箱各发一封测试邮件，查看邮件头 Authentication-Results 中是否所有发信路径都出现 dkim=pass。多发信系统的情况下，为每个系统配独立选择器，失败时才能快速定位。

不是必然，但会丢掉一项重要的信任加分。多数反垃圾系统对无有效签名或验签不通过的邮件采取严格策略，落入垃圾箱的概率明显升高，部分系统会在 SMTP 会话阶段直接拒收（这种情况发件人会收到退信）。有一种边界情况：如果域名同时有有效的 SPF 记录、且 DMARC 策略为 p=none，DKIM 失败不一定导致拒收——但信任分下降仍会让邮件更容易被判为垃圾，内容层若同时有扣分项则更明显。

四、DMARC：把两份证据与 From 域绑在一起

SPF 验了发信服务器、DKIM 验了内容完整性，但两者各自独立，都没回答一个问题：域名所有者希望收件方怎么处置验证失败的邮件？ DMARC 补的就是这一层 [3]。

它让域名所有者在 SPF 与 DKIM 之上发布一条统一策略，明确指示收件方的动作。用比喻说：SPF 是身份证，DKIM 是防伪封条，DMARC 是一份公开的处置指南——写明证件和封条对不上时该怎么办。

4.1 最容易被忽略的是“对齐”

即使 SPF 与 DKIM 各自都验证通过，DMARC 仍可能判失败——只要信封域或 DKIM 签名域与用户看到的 From 头部域不一致 [3]。

对齐有两种模式 [3]：

模式	要求	例
relaxed（宽松，默认）	允许子域匹配	mail.example.com 的签名可与 example.com 的 From 对齐
strict（严格）	要求完全一致	子域也必须精确相同

现实中最常见的失败场景：主域 example.com 设了 strict 对齐，但营销邮件通过第三方平台从 news.example.com 发出，DKIM 签名域是 news.example.com，与 From 头的 example.com 不一致——DKIM 验签明明通过，DMARC 照样判失败。

原因往往是第三方平台默认用自己的子域做签名，而管理员没意识到需要与平台协商调整签名域，或把对齐模式改为 relaxed。

这也是本文开头那条判断的来源：spf=pass 且 dkim=pass 但 dmarc=fail，基本可以直接去查对齐，不用再回头改记录内容。

4.2 三种策略与渐进部署

策略	含义	适用阶段
p=none	仅监控，不处置	初始部署观察期
p=quarantine	标记可疑，投递至垃圾箱或隔离区	过渡期，验证合法邮件不受影响
p=reject	直接拒收	确认覆盖完整后的最终状态

配套两个参数 [3]：

聚合报告是 XML，建议用报告解析工具处理而不是人工读原始文件。开源方案与商业服务都有，作用是把 XML 转成可视图表，便于识别异常发信源和认证失败趋势。

4.3 一条完整的 DMARC 记录长什么样

记录发布在 _dmarc.example.com，类型 TXT。观察期的典型写法：

逐段拆开 [3]：

段	作用	说明
v=DMARC1	版本标识	必须在最前，且固定是这个值
p=none	处置策略	观察期用 none，之后依次升 quarantine、reject
rua=mailto:	聚合报告接收地址	这一项不填就等于白配观察期——没有报告就无从判断能不能升级
pct=100	策略执行比例	不写时默认就是 100。往下调时记住未选中的邮件走下一档策略，不是放行（见 4.2）
adkim=r	DKIM 对齐模式	r = relaxed（宽松，允许子域），s = strict（严格，须完全一致）
aspf=r	SPF 对齐模式	取值同上

adkim 与 aspf 就是 4.1 讲的对齐模式在记录里的实际参数名。两项默认都是 r（relaxed）——如果你没写这两段，用的就是宽松对齐。反过来说，4.1 那个“第三方平台用子域签名导致 DMARC 失败”的场景，成因往往是有人主动把它们改成了 s。

阿里邮箱官方文档给出的 DMARC 示例值是 v=DMARC1;p=quarantine;rua=mailto:user@example.com;ruf=mailto:user@example.com，其中报告接收地址需替换为自己的，官方建议使用同域邮箱接收 [4]。示例里的 ruf 是失败报告（单封明细）的接收地址，与 rua（聚合统计）是两类不同的报告。

观察期结束前不要改动这条记录的其他部分——升级时只动 p 和 pct 两个值，其余保持不变，这样聚合报告的口径才有可比性。

4.4 DMARC 带来的确定性

在 DMARC 之前，域名所有者配好 SPF 与 DKIM 之后只能被动等待——收件方各自决定怎么处置验证失败的邮件。有了 DMARC，处置动作由域名所有者声明，伪造自己域名的邮件才有了被稳定拦截的依据。

从 p=none 开始，先看聚合报告，确认所有合法发信源都通过了 SPF 或 DKIM 的对齐，再调到 quarantine，最后到 reject。周期取决于发信源数量与报告的响应速度：发信源单一的小企业可能一两周就能走完，接入了多个第三方平台的组织通常需要更长的观察期。

升级到 p=reject 之前建议用 pct 分档推进（例如 5% → 25% → 50% → 100%），每档观察至少一个完整的业务收发周期，确认没有合法邮件被误拦再进下一档。不要跳过观察期直接设 reject，原因见 6.3。

4.5 三项记录的部署顺序总表

前面三节分别讲了三项各自的原理。这里把它们合成一张按顺序执行的清单——顺序不能调，理由见开头 Quick Answer：DMARC 需要 SPF 或 DKIM 至少一项能通过才有判据。

顺序	记录	位置	记录值从哪来	这一步怎么验
1	SPF	TXT，主域 @	邮箱服务商文档给出的 include 值，加上自有发信服务器的 ip4 [4]	dig txt example.com 能查到；再用公开的 SPF 查询工具确认展开后未超 10 次 DNS 查询 [1]
2	DKIM	TXT，选择器._domainkey	邮箱管理后台生成公钥（私钥留在发信端，不要外发） [4]	dig txt 选择器._domainkey.example.com 能查到；发一封测试邮件，收件方邮件头出现 dkim=pass
3	DMARC	TXT，_dmarc	自己写，从 p=none 起步，格式见 4.3	rua 指定的邮箱开始收到聚合报告，说明记录已被收件方读取

三点补充：

五、邮件头诊断五步法

邮件被误判时，最快的定位方式是读原始邮件头。它记录了完整投递路径与每一步的认证结果，不依赖任何第三方工具、不必等工单回复。

5.1 第一步：拿到原始邮件头

各客户端的入口不同：

客户端	路径
Outlook 桌面版	双击邮件 → 文件 → 属性 → Internet 邮件头
Apple Mail	显示 → 邮件 → 原始邮件来源
国内主流邮箱网页版	通常在邮件菜单里叫「显示邮件原文」或「查看信头」

注意：要拿的是收件方那一侧的邮件头。自己发件箱里的副本没有收件方的认证判定结果。所以这一步通常需要请收件人配合导出。

5.2 第二步：定位 Authentication-Results

一封邮件可能有多个 Authentication-Results 段，分别来自不同中间服务器。通常最上方那条是最终收件服务器的判定，最具参考价值。

典型格式：

三个字段各自对应哪一层认证、以及涉及的是哪个域，一目了然。注意 smtp.mailfrom（信封域）与 header.from（用户可见的 From 域）是两个不同的值——它们不一致就是对齐问题的来源。

5.3 第三步：读懂返回值

值	含义
pass	通过
fail	验证失败。SPF 遇到 -all 策略时返回的就是这个值
softfail	软失败，对应 SPF 的 ~all：未被拒绝但扣了信任分
none	未配置对应记录
neutral	结果中立，对应 SPF 的 ?all
permerror	永久错误。多为记录语法错误，或 SPF 超出 10 次 DNS 查询上限 [1]
temperror	临时错误。通常是 DNS 查询超时，或选择器记录暂时查不到

5.4 第四步：按失败形态判根因

观察到的结果	大概率的根因
spf=fail，且 smtp.mailfrom 域与发信 IP 不匹配	SPF 记录未授权该 IP
spf=permerror	SPF 语法错误，或 include 嵌套导致查询次数超 10 次 [1]
dkim=fail	DNS 公钥与发信私钥不一致，或签名域的选择器未配置
dkim=temperror	DNS 查询超时，或该选择器记录不存在
spf=pass + dkim=pass 但 dmarc=fail	几乎可确定是对齐问题：查信封域或 DKIM 签名域是否与 From 域一致

最后那一行是整张表里最值得记住的——它把一类看起来最费解的故障直接指向了唯一的原因。

5.5 第五步：改完之后等 TTL

DNS 记录改完不会立即全网生效，要等旧记录的 TTL 缓存过期。比如腾讯云，解析的 TTL 默认值为 600 秒，数值越小改动后各地生效越快 [5]。

计划性修改的推荐顺序：先把 TTL 调小 → 等原 TTL 过期 → 执行修改 → 验证生效 → 再把 TTL 调回正常值。这样既能让改动快速铺开，也不必长期承受过小 TTL 带来的额外查询开销。

生效后重新发测试邮件，再读一次 Authentication-Results 确认三项都通过。需要注意各地递归 DNS 的缓存更新并不同步，稳妥做法是留出余量再做全面验证。

5.6 三项记录的配置位置速查

协议	记录类型与位置	配置目标	常见错误
SPF	TXT，主域（@）	授权发信服务器 IP 或域名	漏掉发信 IP；语法错误；超出 10 次 DNS 查询上限 [1]
DKIM	TXT，选择器._domainkey	发布公钥供收件方验签	选择器名不匹配；公钥与私钥不一致；公钥被换行截断 [4]
DMARC	TXT，_dmarc	声明处置策略与报告接收地址	长期停在 p=none；rua 地址无效；对齐模式与实际发信不符 [3]

六、三个错误怎么发现和修

前面三节讲的是机制——为什么会失败。这一节只讲操作：怎么主动发现，以及具体怎么修。三者的共同特征是 DNS 记录确实存在，“有记录就算配好了”这类检查发现不了。

错误	机制见	这一节给什么
SPF 超出 10 次 DNS 查询	2.2	怎么主动发现
DKIM 密钥轮换后公钥未同步	3.3	双选择器过渡的操作步骤
p=reject 设得太早	4.2	转发场景这个盲区，以及回退方案

6.1 SPF 查询次数：怎么发现已经触顶

这一项不能靠肉眼看记录长度判断，因为 include 是递归展开的——一条只有三个 include 的记录，展开后可能已经十几次查询。

可行的做法是用公开的 SPF 查询工具解析自己的域名，它会统计解析过程中实际触发的查询次数，接近或超过 10 次会给出警告。建议每次新增第三方发信平台后都跑一次，因为超限是逐步累积出来的，不是某一次配置的结果。

修法见 2.2：用 ip4／ip6 直接列关键 IP 段减少 include 依赖，或按用途做子域隔离。

6.2 DKIM 密钥轮换：双选择器过渡的四步

轮换本身的风险在 3.3 说过（只换私钥忘发公钥，且不会立即报错）。规避方式是不要覆盖旧记录，而是新增一个选择器：

关键是第 1 步不要图省事直接覆盖旧记录——保留旧公钥能让过渡期内已在投递途中的邮件仍可验签。

6.3 p=reject 的盲区：邮件转发

升级节奏在 4.2 讲过。这里要单独说一个光看聚合报告也容易漏掉的场景：邮件转发。

邮件被转发后，发信 IP 变成转发服务器的 IP，SPF 必然失败——这不是配置问题，是转发这个动作的必然结果。此时唯一还能维持 DMARC 对齐的凭据是 DKIM 签名（它跟着邮件走，不依赖发信 IP）。如果 DKIM 没配，所有经转发的邮件都会被 reject 拦掉。

用了邮件列表、转发服务、或者收件域设有自动转发规则时，这个问题一定会出现。很多企业是在关键客户的邮件被拒收之后才发现。

修法：

七、选服务商时该问的四个问题

功能清单、容量、客户端界面都容易横向比较，真正拉开差距的是域名认证配置指导与投递排障能力。原因很直接：认证不是一次配完就结束的事，发信路径变化、密钥轮换、策略升级都需要对应的技术支持。

企业新增一个营销平台、更换 CRM、调整邮件服务器 IP，每一处变动都可能影响认证链条。

四个可以直接拿去问的问题：

建议的验证方式：采购前用一两个具体排障场景实测对方的技术支持水平，比对比功能清单更有参考价值。第 1 项尤其有效，因为它无法靠话术糊过去。

这四个问题测的是技术能力。资质与契约层面还有另一组要核的东西——官方授权是否可查、SLA 是否写成书面条款、团队规模与历史实绩怎么验证等等。官方授权的阿里邮箱西南服务中心-大成云，凭借其过硬的技术能力，以及多年深耕经验，可以很好地为客户提供技术支持服务。

八、常见问题（FAQ）

按三个方向依次查。一是 DKIM 覆盖率：向收件人要邮件头，看 Authentication-Results 里 dkim= 的结果，确认所有发信路径都带签名。二是 DMARC 对齐：SPF 与 DKIM 各自通过不代表 DMARC 通过，信封域与 From 域不一致是高频遗漏点（见 4.1）。三是发信 IP 信誉与内容层：用公开工具查发信 IP 是否在黑名单里；同时检查邮件本身有没有图片文字比例失调、正文链接域名信誉不佳等问题——内容层扣分与认证结果无关，认证全通过也可能因此进垃圾箱。

会，而且相当常见。没有充分验证就设 reject，未被 SPF 或 DKIM 完整覆盖的合法邮件会被拒收。稳妥做法是用 pct 分档推进，同时确保 rua 报告邮箱有效，靠报告数据确认所有合法路径都通过后再提策略等级。特别提醒：如果用了邮件转发服务或第三方代发平台，务必在报告里单独确认这些路径——转发场景下 SPF 必然失败，没有 DKIM 就一定会被 reject 拦掉（见 6.3）。

取决于记录的 TTL，数值越小改动后各地生效越快 [5]。建议先用 dig 或 nslookup 确认 TXT 记录已能查到，再发测试邮件看邮件头里的认证结果。如果原 TTL 设得较长，可以先把 TTL 调小、等原 TTL 过期后再改记录内容。另外各地递归 DNS 的缓存更新不完全同步，即使 TTL 已过，个别地区仍可能返回旧记录，全面验证要留出余量。

几乎可以直接判定是对齐问题，不用再回去改 SPF 或 DKIM 的记录内容。检查两处：信封域（邮件头里的 smtp.mailfrom）是否与 From 头部域一致；DKIM 签名域（header.i 或 d= 标签）是否与 From 头部域一致。两者至少要有一项与 From 域对齐，DMARC 才会通过 [3]。常见成因是第三方平台默认用自己的子域做 DKIM 签名，而主域的 DMARC 设了 strict 对齐——解法是与平台协商调整签名域，或把对齐模式改为 relaxed。

协议层面没有任何区别。 SPF、DKIM、DMARC 都是公开的互联网标准 [1] [2] [3]，与邮箱定价无关，免费版同样能配出完全合规的记录。区别在配置出问题或邮件被误拦时能拿到什么支持：能否有人帮你直接读邮件头、协助验证 DNS 记录、给出针对性的 SPF 精简方案。另外部分免费方案在发信频率、发信 IP 池共用等方面可能有额外限制，这些与认证协议无关，但同样影响送达率——签约前应要求书面说明。

本文不给固定周期，因为它取决于企业自身的安全策略与合规要求。要点是轮换动作必须成套完成：生成新密钥对 → 发布新公钥到新选择器 → 服务器切换私钥 → 验证新旧选择器都能验签 → 过渡期后删除旧记录（见 6.2）。只换私钥不发布公钥是最常见的事故形态，而且不会立即报错。

结语

三项认证的分工可以一句话概括：SPF 管信封上的发信服务器，DKIM 管内容有没有被改，DMARC 把这两份证据与收件人真正看到的 From 域绑定，并声明失败时怎么办。

排查顺序也固定：先从收件方那边取原始邮件头，读 Authentication-Results 的三个值，再按第五节的对应表定位到具体层。最需要记住的一条是——spf 与 dkim 都 pass 而 dmarc 仍 fail 时，去查对齐，别再改记录。

对缺少专职运维的企业，域名认证的配置与后续的密钥轮换、策略升级也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含域名解析配置与相关的投递问题排查等 [6]。

References