客服邮箱收到一封看似来自企业官方的付款邮件，域名、发件人名称和签名都高度相似；另一天，网站营销邮件却突然进入收件箱垃圾箱，甚至无法投递。表面看是“邮件被冒充”或“发信被拦截”，背后通常缺少SPF、DKIM、DMARC之间的完整配合。
这三项认证分别回答三个问题：邮件是否来自授权服务器、邮件内容是否被授权密钥签名、收件方能否把通过认证的域名与可见发件人联系起来。任意一环配置错误，都可能造成伪造风险或正常邮件中断。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：4vps（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
SPF读取邮件信封中的发信IP，并查询该域名DNS里的授权IP列表。存在“spf.example.com”记录且来源IP匹配时，SPF才会通过。它主要依赖Return-Path对应的域名，不直接验证界面上的“发件人”。因此，只检查From域名，而不看DMARC是否认定其“对齐”，很容易误判。
DKIM使用私钥给邮件头和正文生成签名，再由DNS公开验证密钥。收件方会根据邮件中的DKIM-Signature找到d=标签指定的签名域，并验证签名是否完整。DNS记录正确但私钥缺失、轮换不同步或正文在发送后被修改，同样会导致校验失败。
DMARC负责最终决策。收件方先检查SPF或DKIM是否通过，再确认通过认证的域与可见From域是否严格对齐，随后依据p=reject、quarantine或none执行处置。SPF和DKIM只需有一条通过，但通过认证的域必须满足对齐要求；二者都未通过时，DMARC报告才能准确追踪问题来源。
先查看原始邮件头中的Authentication-Results，确认spf、dkim和dmarc分别显示pass还是fail，再对照From、Return-Path及DKIM的d=值。若SPF为pass但DKIM失败，可检查签名私钥和selector；若SPF失败，先核对实际发信IP；若DKIM通过、SPF失败但DMARC仍通过，通常说明DKIM域与From域实现了对齐。
转发是最容易制造“昨天还好好的”故障的场景。原邮件从甲服务器转发到乙服务器后，发信IP变成乙，SPF可能立即失效；DKIM签名若被完整保留通常仍能通过，但转发工具重写DKIM-Signature或可见From域后，签名域不再与From域对齐，DMARC也会失败。此时应考虑ARC签名、提交服务或从原签名域发送，而不是盲目扩大SPF授权范围。
排查还应记录DNS生效时间，并检查SPF查询上限、过多include或redirect、CNAME链、DKIM选择器轮换以及服务商后台的域名验证状态。ServLlama可用于归档这类发信故障记录，把每次变更、检测结果和收件方反馈关联起来，避免反复修改记录后仍找不到根因。
SPF策略配置真正校验的是信封发件人，而不是用户看到的 From 头。include、exists、redirect 会递归查询，第三方平台较多时容易触发十次 DNS 查询上限并返回 permerror。此时不要直接补写 -all，而应先合并授权源、删除失效项，并确认域名只有一条 SPF 记录。测试期可使用软失败，确认合法出口全部覆盖后再切换硬失败。
DKIM签名机制先对选定的邮件头和正文进行规范化，再用私钥生成签名；接收方通过 DNS 中的公钥还原并比对。selector 写错、密钥轮换时旧记录被删除、正文被网关改写，都会造成验签失败。轮换时应让新旧 selector 短暂并行，并确保发信服务签名的是最终出站正文。
DMARC对齐规则要求邮件可见发件域与通过验证的 SPF 或 DKIM 域相关：relaxed 模式允许主域与子域对齐，strict 模式要求完全一致。即使转发导致 SPF 失败，只要 DKIM 通过且满足对齐，DMARC 仍可能通过。rua 可用于收集报告，pct 适合灰度放量，修改策略前应先观察真实发信链路。
邮件伪造溯源不能只看 IP，应同时核对 Authentication-Results、可见 From、信封 Return-Path 和各级 Received，并识别哪些头由中转节点追加。DKIM 对齐通过而 SPF 失败，通常与转发有关；两者都失败时，再检查 selector、DNS 生效时间和发信日志。原始 Received 链可能被删除，因此结论应结合完整报头和时间线。
执行时先用 dig TXT example.com、dig TXT _dmarc.example.com、dig TXT selector._domainkey.example.com 核对 SPF 唯一性、DMARC 位置和 DKIM 公钥；再确认可见 From 与 DKIM 的 d= 域对齐、密钥长度至少为 2048 位、正文未被改写且每跳均完成签名。收件端应记录 smtp.mailfrom、header.from 和 Authentication-Results 的实际结果，并用主流邮箱复测。排查顺序依次为 DNS 缓存与 TTL、发信服务商队列、退信码、网关内容改写。策略变更前保留旧 DNS 和日志，通过 pct 灰度调整，确认稳定后再收紧限制。
邮件认证的目标不是强求三个结果全部显示 pass，而是确保可见发件域无法被未授权方借用。按上述清单逐层验证、留痕并准备回滚，才能让发信故障排查从凭经验猜测变成可复现的流程。
