先证明哪些身份被验证，再判断是否对齐；认证通过不等于收件箱投放保证。
一、收不到验证码，先查认证结果而不是猜测
周岚的工具收到「验证码没来」的反馈。测试邮箱中，有的邮件进了垃圾箱，有的未见；排查发现同一个 SPF 查询名下有多条候选 SPF 记录，DKIM 未配置，DMARC 也没有部署。
这是教学情境。它足以说明要修配置，却不能推出「没有认证几乎一定进不去」，也不能凭几封测试信量化全体用户的垃圾箱率。正确做法是保留发送、退信、可信接收方认证结果与测试样本，分别判断故障发生在哪里。
二、三种机制，不是固定三条 TXT 记录
| 机制 | 验证什么 | 部署位置 | 不能推导什么 |
|---|---|---|---|
| SPF | 连接 IP 是否获信封域名授权 | MAIL FROM 域名的 SPF TXT；空反向路径另按 HELO 身份处理 | 不直接验证用户看到的 From |
| DKIM | 签名域及被签名内容是否验证通过 | selector._domainkey.签名域，按服务商要求设置 TXT 或 CNAME | 不加密正文，也不保证所有未签名字段未被改动 |
| DMARC | 已验证的 SPF/DKIM 身份与 From 域是否对齐，并发布处理偏好 | _dmarc 策略及相应报告配置 | 不保证收件箱投放或逐封报告 |
SPF 的「一条」以查询名为范围。 同一个查询名选择到多条 SPF 记录会产生 permerror，不是无记录的 none；主域和不同发信子域各有自己的查询名。单个 TXT 内可以有多个字符串拼接，不能把它误当多条 SPF 记录；其他用途的 TXT 也不算 SPF 候选。
SPF 的十项限制不是所有 DNS 数据包总数。 RFC 7208 §4.6.4 对会触发 DNS 查找的机制和修饰符计数，包括递归的 include 与 redirect 等；ip4、ip6、all 不计入这项上限，另有空结果及 MX 等限制。上线用能展开依赖的检查器核验，不凭服务商个数判断是否超限；SPF 通常也不会从父域自动继承。
DKIM 选择器用于定位公钥与轮换。 使用一个当前选择器并非天然错误；需要轮换时先发布新公钥，切换签名，再给旧信验证保留适当过渡期。选择器名字由服务商配置决定，不必叫 s1 或 s2。同一 DNS 名称不能随意混设 CNAME 与 TXT，以服务商指引核验。
DMARC 策略表达域所有者的处理偏好。 none 用于观察，quarantine 与 reject 表达更严格的偏好，接收方仍会结合自身策略决定处置。不是写入 reject 后所有接收方就一定拒收。
三、对齐：至少一条通过路径，而不是三项全 pass
SPF 看已验证的信封域，DKIM 看通过验证签名的 d= 域；这两个身份各自与 From 域比较。Reply-To 不参与 DMARC 的身份对齐。
SPF 路径 = SPF 验证通过 且 SPF 身份与 From 域对齐
DKIM 路径 = 至少一个 DKIM 签名验证通过 且该签名域与 From 域对齐
DMARC 通过 = SPF 路径 或 DKIM 路径
| SPF 路径 | DKIM 路径 | DMARC 结果 | 说明 |
|---|---|---|---|
| 成立 | 不成立 | pass | SPF 这一条路径足够 |
| 不成立 | 成立 | pass | DKIM 这一条路径足够 |
| 成立 | 成立 | pass | 两条都成立 |
| 不成立 | 不成立 | fail | 某项认证单独 pass 但未对齐也不够 |
这张表描述身份认证判定，不代表邮件最终是否被接收。主动配置可同时追求 SPF 与 DKIM 正常，收件平台也可能要求两者都部署；这些部署要求不改变上面的 DMARC 通过条件。
严格对齐要求域名完全一致；宽松对齐按组织域关系判断，不能用「字符串末尾相同」或「取最后两个标签」代替。2026 年 5 月发布的 RFC 9989 已取代旧的 RFC 7489 核心规范，引入 DNS Tree Walk 等发现规则；聚合报告另见 RFC 9990 。实际接收方可能仍有旧实现，应记录接收方结果与部署配置，不能假定所有系统已经同步升级。
四、分离发信用途，但不要承诺完全隔离声誉
| 用途 | 示例身份 | 要分开的控制 | 仍可能共享的因素 |
|---|---|---|---|
| 事务 | mail.example.com | 队列、容量预算、模板与监控 | 账号限额、IP、组织域名与基础设施 |
| 营销 | news.example.com | 偏好、抑制、频率与退订 | 接收方可能聚合主域或共享 IP 的行为 |
| 人工支持 | support@example.com | 回复入口、人员权限与日志 | 同样需要正确认证与账号保护 |
这些是文档示例域名，不是可直接用于生产的 DNS 配置。每个实际 MAIL FROM、DKIM 与 From 域都应登记；换服务商后核验真实信封域与签名域，不能只看控制台的绿色勾。
子域名有助于分类和配置，却不保证营销投诉只影响营销，或事务永远不受牵连。必要时另分容量与传输资源，并保留独立的故障提醒入口。
验证码和用户请求的收据不与营销退订混为一个开关；但「事务子域名」不能把促销内容变成必要通知。按消息目的决定偏好与退订，正文可查凭证、回复联系人与站内入口分别设计。营销或订阅邮件的适用收件平台要求，还可能包括 RFC 8058 的退订头和 HTTPS POST；只有正文里的链接不一定满足该要求。
五、分阶段部署与可复现检查
- 清点所有实际发送源，包括告警、备份、人工工具与旧脚本，分别记录发信域、信封域、签名域、用途与负责人。
- 按服务商文档配置 SPF 与 DKIM；确认查询名、记录选择、依赖查找、签名验证及转发后的变化。
- 发布 DMARC 观察策略并配置
rua。报告接收地址在外域时，按报告规范和服务商要求核验外部报告授权；有地址不代表一定能收到全部报告。 - 用真实存在、已授权的测试邮箱检查可信接收系统写入的
Authentication-Results，结合原始邮件、服务商记录与聚合报告验证两条对齐路径。不要信任邮件发送者自行夹带的伪造认证头。 - 确认正常发送源、主要接收方与低频发送场景覆盖后，再考虑
quarantine和reject。观察两周只能是排期假设，不能替代月度账单或低频系统的覆盖；变更前准备已知良好配置与回退流程。 - 更换服务商、域名或签名后立即复测，并持续检查；聚合报告有时延和覆盖限制，不保证逐封、实时定位所有失败。
验收分成配置与协议两层。 自有直发样本争取 SPF、DKIM 均验证正常；DMARC 按至少一条验证且对齐的路径判断。额外测试转发导致 SPF 失败但对齐 DKIM 仍通过，以及两项验证通过却都不对齐的情况，不能只测一封成功信。
下面仍用原稿的 5000 封与两组比例演算，但不把它称为「垃圾箱率实测」。假设在同一完整观测口径下，两组未进目标收件箱的比例分别为 18% 与 2%；实际通常无法逐封观测全部用户。
第一组不达目标收件箱 = 5000 × 18% = 900
第二组不达目标收件箱 = 5000 × 2% = 100
差额 = 900 − 100 = 800
另假设新增可见邮件中的有效动作率为 22%
预计新增有效动作 = 800 × 22% = 176
另假设其中 5% 为关键事务 → 800 × 5% = 40 封
这些是条件推算，不能单凭认证变更前后的对比证明全部差异来自认证；打开追踪也不能可靠验证「有效动作」或准确收件箱投放。要测验证完成、真实点击后的业务动作等适当结果，并记录其他变更与样本差异。
行动清单与实操验收
- 区分 From、MAIL FROM、DKIM 签名域与 Reply-To。
- 核对 SPF 记录选择及依赖查找，避免把 TXT 字符串数当记录数。
- 验证 DKIM 签名范围、公钥位置与轮换恢复流程。
- 分别记录认证结果与对齐结果，解释 DMARC 的通过路径。
- 登记转发、低频脚本、第三方代发与外部报告授权场景。
- 保留变更日期与恢复步骤，不以认证通过替代收件箱和业务体验检查。
本文核对了标准与公开服务说明，未操作真实 DNS 或发信账号；教学比例不代表本轮发送实验。
关键参考与核验范围
核验日期：2026-10-25。
- RFC 7208 ：SPF 身份、记录选择与 §4.6.4 查找限制。
- RFC 6376 ：DKIM 的签名域、选择器及验证范围。
- RFC 9989 与 RFC 9990 ：当前 DMARC 核心与聚合报告规范；旧 RFC 7489 用于理解历史实现，不能继续作为唯一现行依据。
- Gmail 发信指南 ：个人 Gmail 收件场景下的额外要求，不外推成所有邮箱平台统一规则。
- RFC 8058 ：基于邮件头的 one-click 退订机制，与仅放正文链接不同。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。