理解 SPF、DKIM 与 DMARC：邮件为何被拒收

三种机制承担不同职责

SPF 公布哪些系统可以代表域名发送邮件，并针对技术层面的 Envelope-From 域名进行检查。DKIM 添加加密签名，其公钥发布在 DNS 中。DMARC 将身份验证与用户可见的 From 域名联系起来，并公布验证失败时建议接收方采取的策略。

邮件通过 DMARC，需要 SPF 或 DKIM 中至少一项验证成功，并且通过验证的域名与可见发件人域名对齐。对齐机制可防止攻击者仅因控制了另一个已验证的发信域名，就冒用无关的可见发件人域名。

理解这些 DNS 示例记录

以下 example.com 记录用于说明语法，并不是可以不加判断地直接复制的配置。缩写后的 DKIM 密钥不能实际使用。真实记录必须匹配该域名获授权的服务与密钥。

• SPF: example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"
• DKIM: default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
• DMARC: _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
• p=none 表示监控，不要求基于 DMARC 进行隔离或拒收；p=quarantine 请求将可疑邮件隔离处理；p=reject 请求拒收。

不要在未检查发信来源时直接设置 reject

受控部署通常从 p=none 和一个报告邮箱开始。报告可以揭示合法来源、被遗忘的新闻通讯系统以及滥用行为。先修正发信来源和 DKIM 配置，再逐步引入 quarantine 或 reject；适用时可先覆盖有限比例。只有合法邮件能够可靠对齐后，才应收紧策略。

每个域名只发布一条 SPF 记录，并遵守 DNS 查询次数限制。冗长的 include 链会带来运行风险。使用足够强度的 DKIM 密钥，并规划轮换。子域名、邮件转发和第三方发件服务需要整体设计，而不是零散修改 DNS。多条 SPF 记录、错误的 include 和缺少对齐，都是常见故障。

身份验证有助于信任，但不是垃圾邮件过滤器

SPF、DKIM 和 DMARC 改善接收方判断信任的基础。身份验证还需配合稳定的发信行为、维护良好的收件人名单和较低的投诉率。通过检查并不保证进入收件箱；配置错误却可能严重影响合法邮件。

监控 DNS 变更、DKIM 签名和 DMARC 报告。新的发信服务应在测试发件人域名、Return-Path、DKIM 和退信后才投入生产。签名无效或缺失时，应结合背景调查，不能假设每封没有 DKIM 的邮件都一定被篡改过。