整理说明：本文属于“2025-2026 技术笔记整理”系列，于 2026 年 8 月集中整理并公开发布。
SPF、DKIM、DMARC：从可观测到严格保护的配置路径
三项机制解决的是不同问题：SPF 声明哪些系统可以代表域名发信，DKIM 为邮件生成数字签名，DMARC 则检查它们是否与用户看到的 From 域名对齐，并给出失败邮件的处理策略。认证能降低冒用风险，却不是群发许可或进箱保证。
SPF：约束信封发件来源
收件方用连接 IP 检查信封 MAIL FROM（退信地址）域名的 TXT 记录，必要时也检查 HELO。一个域名只能发布一条有效 SPF 记录，多个来源应合并。include、a、mx 等会触发 DNS 查询，评估过程最多允许 10 次此类查询，因此不要无限叠加服务商。
example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.provider.example ~all"转发可能改变连接来源，使 SPF 失败；同时，SPF 通过也只说明信封域名获授权。DMARC 要求该域名与 From 域名按严格或宽松模式对齐。
DKIM：验证签名与内容完整性
发信系统用私钥对选定邮件头和正文摘要签名，收件方从 selector._domainkey.example.com 查询公钥。私钥不得放入 DNS 或代码仓库；选择器让旧、新密钥可以并行，便于轮换。转发时只要已签名部分未被破坏，DKIM 通常仍可验证。
s2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"DMARC：以 From 域名做最终对齐
DMARC 在“对齐的 SPF”或“对齐的 DKIM”至少一项通过时通过。策略可设为 none、quarantine 或 reject；rua 接收聚合报告，可能包含基础投递元数据，应设置访问控制并按隐私要求保存。
推荐的渐进上线步骤
- 盘点业务系统、客服平台、营销平台和退信域，先停止未知来源。
- 合并 SPF，先用
~all观察，确认来源完整后改为-all；为合法来源启用 DKIM。 - 发布
p=none，连续分析聚合报告，修复未对齐的合法流量。 - 逐步使用
pct提升quarantine覆盖率，确认无误后再到reject。 - 用
sp明确子域策略，并定期移除停用供应商与轮换 DKIM 密钥。
策略升级应基于真实报告，而不是一次性照抄模板。对营销邮件还要取得适当同意、标明发件主体、提供有效退订并抑制已退订地址；对交易邮件也应限制用途和频率。认证负责证明身份，合规发送和良好名单维护才决定长期信誉。