邮件 SPF/DKIM/DMARC 配置：提升邮件送达率与安全性
SPF、DKIM、DMARC 是邮件认证的三根支柱。它们解决的问题很实际：你的邮件送达率为什么忽高忽低、为什么发出去的信进了垃圾箱，以及别人能不能冒用你的域名发钓鱼邮件。三者分工不同：SPF 声明“谁可以发”，DKIM 证明“信确实是我发的”，DMARC 告诉收件方“SPF/DKIM 都失败时怎么办”。这三条 DNS 记录配齐，才能算把域名邮件身份真正管理起来。
一、SPF（Sender Policy Framework）
SPF 通过一条 DNS TXT 记录声明哪些服务器有权限以你的域名发信。只要邮件服务器的 IP 不在白名单里，收件方就可以判定为失败：
# DNS TXT 记录
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
| 机制 | 说明 |
|---|---|
| include | 引入指定域名的发送服务器（如第三方邮件服务） |
| ip4 / ip6 | 允许指定的 IP 地址段 |
| a | 允许域名 A 记录指向的服务器 |
| mx | 允许域名 MX 记录指向的服务器 |
| ~all | 软失败（推荐）：不明确拒绝，便于过渡 |
| -all | 硬失败：直接拒绝，只适合完全确定发送源后使用 |
一个常见坑：用第三方邮件服务（Google Workspace、Mailgun 等）时，把它们的 include 拼进 SPF，而不是把它们的 IP 抄过来——IP 会变，include 是更稳的引用方式。SPF 记录里有 DNS 查询次数上限（10 次），include 套 include 太多会直接导致验证失败。
二、DKIM（DomainKeys Identified Mail）
DKIM 用非对称加密给邮件签名：发信时用私钥签名，收件方用你公开在 DNS 里的公钥验签，从而确认邮件在传输中没有被篡改、确实来自你的域名：
# DKIM DNS 记录（选择器名由邮件服务商给出）
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
配置时注意几点：选择器（selector）名字由服务商决定，比如 Google Workspace 用 google，Cloudflare Email Routing 用 c1 之类；公钥 p= 的值必须完整，从服务商面板复制时别截断；如果同时用多个发信系统（营销邮件 + 事务邮件），建议各自独立的选择器和密钥，便于单独轮换和排查。
三、DMARC（Domain-based Message Authentication, Reporting & Conformance）
SPF 和 DKIM 各自给出“通过/失败”的判断，DMARC 则规定收件方在两者都失败时的处理策略，并通过报表让你看到认证全景：
# DMARC DNS 记录
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
| 策略 | 说明 | 建议 |
|---|---|---|
| none | 仅监控，不做处理 | 上线初期先跑 1-2 周，摸清真实失败量 |
| quarantine | 标记为垃圾邮件 | 确认误杀可控后升级到此档 |
| reject | 直接拒绝 | 发送源完全可控后的最终档位 |
rua 指定的邮箱会收到聚合报表（XML 格式），建议交给第三方工具（如 dmarcian、Google Postmaster Tools）解析，方便看清楚：哪些服务在冒用你的域名、哪条 SPF 链路偶尔失败。sp 参数可以为子域名单独设置策略。
四、配置与验证
配完记录后用工具验证，别凭感觉上线：
# 命令行验证
dig TXT example.com # 查看 SPF
dig TXT google._domainkey.example.com # 查看 DKIM 公钥
dig TXT _dmarc.example.com # 查看 DMARC
# 发送测试邮件后，用下面的服务核对认证结果：
# https://mxtoolbox.com/diagnostic.aspx
# https://www.mail-tester.com
一个完整的拦截案例
把三个协议串起来看，最能理解它们各自的位置。假设攻击者想冒充 example.com 给你发一封钓鱼信：
- SPF 先挡一层：攻击者的服务器 IP 不在 example.com 的 SPF 白名单里，SPF 判定失败。此时 Gmail、Outlook 这类收件方已经知道「这封信的身份存疑」。
- DKIM 再验一次：攻击者没有 example.com 的 DKIM 私钥，签名要么缺失要么验签失败。注意 SPF 和 DKIM 是「或」的关系——只要有一个通过，DMARC 就可能放行，所以两个都必须配。
- DMARC 做最终裁决：两者都失败时，收件方按你
_dmarc记录里的策略处理。p=reject直接拒收，p=quarantine丢进垃圾箱，聚合报表会记录这次尝试的源 IP 和结果，方便反查。
现实中很多域名只配了 SPF 就以为万事大吉，结果 DKIM 缺失、DMARC 根本没建，攻击者仍然可以借用邮件头里的「显示名」伪装成你——这类域名才是钓鱼重灾区。三条记录配齐，才能把这个口子彻底堵上。
一个更稳妥的落地细节：独立发信域
如果你的网站同时由多个系统发信——商城订单邮件、营销推送、客服工单——建议不要都挂在主域名上，而是单独建一个子域做发信域，比如 mail.example.com。理由很实际：打开率、退信率、垃圾投诉直接决定发信域的声誉，一旦某个系统被打上高投诉标签，收件方会连带着影响主域名的正常邮件。把发信域和主域分离后，即使某条营销链路出问题，订单通知、密码重置这类关键邮件依然能正常送达。代价只是多配几组 DNS 记录（SPF include、DKIM 选择器、DMARC 的 rua/sp 参数），运维成本几乎可以忽略。
常见问题
只有 SPF 没有 DKIM/DMARC 会怎样？ SPF 依赖信封地址，转发邮件时常常失败；DKIM 基于内容签名，转发后仍然有效，两者互补。只配 SPF 的域名很容易在 Gmail 被判为“via”邮件。
DMARC 刚上线会不会误杀正常邮件？ 会，所以流程必须是 none → quarantine → reject，每一档先观察报表再升级，通常需要两周以上。
用了第三方邮件服务，配置由谁负责？ 服务商通常提供现成的 SPF include、DKIM 选择器和 DMARC 建议值，你只需在 DNS 托管商那里添加记录；域名在自己手里，DNS 记录永远由你负责发布。
参考：RFC 7208 (SPF) https://www.rfc-editor.org/rfc/rfc7208 ；RFC 7489 (DMARC) https://www.rfc-editor.org/rfc/rfc7489 ；Google 发件人指南 https://support.google.com/a/answer/81126