邮件相关记录

这一课你将能做到

1. 写出本站可用的 MX 配置并解释优先级机制，画出一封外发邮件到达本域邮箱的解析与投递路径
2. 说清 SPF、DKIM、DMARC 三者各防什么攻击，写出本站推荐的 TXT 记录并回查验证
3. 解释 PTR 反向解析与邮件信誉的关系，知道自建邮件服务器时该找谁配置

为什么要学

DNS 不只为网站服务，电子邮件是 DNS 的另一大主战场。收件方判断一封邮件是不是伪造的，几乎全部依据 DNS：发送方 IP 在不在 SPF 白名单里、DKIM 签名能不能用域名 TXT 里的公钥验通、DMARC 要求伪造邮件怎么处理。这三样缺一个，系统发出去的注册验证码、找回密码邮件就可能直接进垃圾箱；一样都没有，你的域名还会被人冒名群发诈骗邮件。

后端开发经常用 Spring Boot 的 spring-boot-starter-mail 发邮件，但配完 SMTP 账号只解决了「怎么发出去」；「发出去对端信不信」取决于本课讲的记录。

先建立图像

① 收件路径：别人发信到 user@coderoadmap.cn

  发件服务器要找 coderoadmap.cn 的 MX
     dig MX coderoadmap.cn
        → 10 mail.coderoadmap.cn
     再解析 mail.coderoadmap.cn 的 A
        → 203.0.113.10
     SMTP 连接 203.0.113.10:25 投递

② 反伪造三件套（收件方检查本域发出的信）

  SPF    查 coderoadmap.cn 的 TXT：哪些 IP 允许以 @coderoadmap.cn 发信
  DKIM   查 选择器._domainkey.coderoadmap.cn TXT：取公钥，验证邮件体签名
  DMARC  查 _dmarc.coderoadmap.cn TXT：SPF/DKIM 都不过时，拒收还是标记？报告发哪？

机制	防什么	记录位置	一句话
SPF	冒名 IP（信封 MAIL FROM）	域 TXT	白名单 IP 列表
DKIM	内容篡改 + 冒名	选择器._domainkey 子域 TXT	非对称签名，公钥在 DNS
DMARC	前两者策略统一与上报	_dmarc 子域 TXT	失败策略 + 聚合报告
PTR	动态 IP/垃圾邮件信誉	IP 反向区域	IP 要能反查出主机名

跟着做

步骤 1：配置与查询 MX

dig coderoadmap.cn MX +short
dig mail.coderoadmap.cn A +short

本站推荐形态（Cloudflare 添加；如用企业邮箱则按服务商文档，常见 Google/腾讯/阿里企业邮各有固定值）：

类型 MX  主机 @  值  10 mail.coderoadmap.cn
类型 A   主机 mail  值 203.0.113.10（灰云）

优先级数字越小越优先；配两条 MX（10 主、20 备）做容灾，主 MX 不可达时发件方按 SMTP 规范自动尝试下一条。MX 的值必须是主机名，不能是 IP；且主机名不能是 CNAME。

步骤 2：写一条严格的 SPF

dig coderoadmap.cn TXT +short

本站若只通过指定邮件服务商发信，SPF 示例：

# 通过第三方邮件商（示例：其 include 机制）与本机服务器发信，其余全部拒收
v=spf1 ip4:203.0.113.10 include:spf.thirdmail.com -all

尾部限定符	含义	适用阶段
-all	不在列表内一律拒绝（硬失败）	正式环境推荐
~all	标记为软失败，通常进垃圾箱	上线观察期
?all	中立，等于没管	不推荐

本站若暂时不自己发任何邮件，最安全的是 v=spf1 -all（任何 IP 都不允许），防止域名被冒名。SPF 只校验信封发件人（SMTP MAIL FROM / Return-Path），不校验邮件头里的 From——后者靠 DKIM/DMARC 对齐。

步骤 3：理解并验证 DKIM

# 选择器由发信系统决定（如 google、s1、default），先查 TXT
dig s1._domainkey.coderoadmap.cn TXT +short

示例输出（一条长 TXT，公钥材料）：

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...（公钥，省略）

工作过程：发信服务器用私钥对邮件头/正文的选定部分签名，签名放进邮件头 DKIM-Signature: d=coderoadmap.cn; s=s1; ...；收件方按 s（选择器）._domainkey.d（域） 取回公钥验签。密钥轮换时新建一个选择器（如 s2），两边平滑切换后再删旧记录。

用自建 Postfix 等 MTA 时可用 opendkim 生成密钥与记录；SaaS 邮件服务在后台点「启用 DKIM」后会给你现成 TXT。

步骤 4：配置 DMARC 策略

dig _dmarc.coderoadmap.cn TXT +short

本站分阶段推进的推荐路径：

# 第 1 阶段：只收报告、不拦截（观察谁在用你的域发信，跑 1~2 周）
v=DMARC1; p=none; rua=mailto:dmarc@coderoadmap.cn; ruf=mailto:dmarc@coderoadmap.cn; fo=1

# 第 2 阶段：未通过的进垃圾箱
v=DMARC1; p=quarantine; rua=mailto:dmarc@coderoadmap.cn; pct=100

# 第 3 阶段：直接拒收（最终目标）
v=DMARC1; p=reject; rua=mailto:dmarc@coderoadmap.cn; pct=100

字段解释：p 策略；rua 每日聚合报告（各收件方发来的 XML）；ruf 失败取证邮件；pct 策略应用比例（渐进放量用）；fo=1 任一校验失败就发取证。DMARC 的核心是对齐（alignment）：要求 SPF 或 DKIM 通过，且其认证的域与邮件头 From 的域一致（严格/宽松模式）。

步骤 5：检查 PTR 反向解析

dig -x 203.0.113.10 +short

理想返回：

mail.coderoadmap.cn.

PTR 不在 Cloudflare 面板配——它属于 IP 地址块持有者的反向区域（10.113.0.203.in-addr.arpa）。云主机需在云控制台或提工单设置。邮件三要素（正向 A、反向 PTR、HELO 主机名）保持一致是收件方的基本信誉要求；住宅 IP 段、缺 PTR 的 IP 发信通常被直接拒。

步骤 6：端到端验证一封系统邮件

# 1) 应用触发一封注册/找回密码邮件到 Gmail/QQ 邮箱
# 2) 在收件箱打开「显示原始邮件」（Gmail：右上角三个点 → 显示原始邮件）
#    检查：SPF: pass  DKIM: pass  DMARC: pass
# 3) 命令行复查所有记录
dig coderoadmap.cn MX +short
dig coderoadmap.cn TXT +short
dig s1._domainkey.coderoadmap.cn TXT +short
dig _dmarc.coderoadmap.cn TXT +short

Gmail 原始邮件页的关键行示例：

ARC-Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass

三项任何一个显示 neutral/fail/none，按本课对应步骤排查记录是否生效、选择器是否匹配、发信 IP 是否在 SPF 列表。

讲清楚要点

1. MX 定义收信入口，SPF 定义发信授权：方向相反，缺一不可，且都写在 DNS 上、不依赖任何中心化邮件机构。
2. SPF 是 IP 白名单，机制有 include/a/mx/ip4 等；它只对信封发件人生效，且受 DNS 查询次数（10 次）限制，include 不要嵌套太多。
3. DKIM 把信任锚放在 DNS TXT：即使邮件被中间人转发、改了 SMTP 信封，只要签名覆盖的内容没被改，DKIM 仍 pass。
4. DMARC 不做新校验，它做「策略与对齐」：没有 DMARC，SPF/DKIM 失败了对端也可能只是放行；有了 p=reject 才有强制力，rua 报告还能让你看到冒名流量。
5. 上线节奏 p=none → quarantine → reject：直接 reject 而记录没配齐，可能把自己的业务邮件全部拒掉。
6. PTR + SPF + DKIM 共同构成发信信誉：另外 IP 历史信誉、退信率、投诉率也由收件方综合评分，不是配了 DNS 就 100% 进箱。
7. 子域可单独设 SPF/DMARC：营销邮件常用独立子域（mailer.example.com），即使信誉受损也不波及主域。

你可能会懵的地方

• SPF 通过了，为什么 DMARC 还可能 fail？ DMARC 要求「对齐」：SPF 校验通过的域必须与邮件头 From 的域一致。若 From 写 coderoadmap.cn，而 MAIL FROM 用了第三方邮件商的域（SPF 只对齐了第三方域），SPF 本身 pass 但 DMARC 不通过。DKIM 的 d= 域同样要对齐。

• DKIM 公钥为什么要放 DNS 而不是别的地方？ DNS 本身证明「域名控制者发布了这把公钥」，和域名所有权天然绑定；收件方验签时只需查 DNS，不需要额外的密钥分发机构。配合 DNSSEC 还能防止公钥记录被篡改。

• SPF 的 10 次 DNS 查询限制是什么？ RFC 7208 规定校验一封邮件的 SPF 最多触发 10 次 DNS 查询（include/a/mx/ptr 各计），超过即 permerror。所以 include 链要短，大服务商也建议用 ip4: 直写或扁平化。

• 企业邮箱的 MX 要改成服务商的，那我的 mail.coderoadmap.cn 怎么办？ 以服务商为准：如 MX @ 1 ASPMX.L.GOOGLE.COM.，自建的 MX/A 记录不再需要（可保留但不参与）。SPF 改用其 include，DKIM 在其后台启用。

• DMARC 报告（rua）那么多 XML，谁看得完？ 一般不手工看，用 Postmark/dmarcian 等报告聚合服务（很多免费）接收并汇总成面板；自建可用解析脚本入库，重点看来源 IP 和通过率趋势。

错法对照

错法	后果	正确做法
直接上 p=reject 且记录未配齐	业务邮件被全球收件方拒收	none → quarantine → reject 渐进
SPF 写 ~all 长期不收紧	伪造邮件仅软失败，仍可能进箱	观察期后改 -all
多个系统各写一条 SPF TXT	RFC 规定只允许一条，直接 permerror	合并进同一条，用 include 串联
DKIM 轮换密钥直接删旧记录	传输途中旧邮件验签失败	新旧选择器并存一段时间再删
自建发信却忽略 PTR	对端按垃圾邮件直接拒	找云厂商配反向解析，三处主机名对齐

卡点急救

1. 业务邮件进垃圾箱：先用 Gmail「显示原始邮件」看三项校验结果；缺啥补啥；记录都正常再查 IP 信誉（是否在黑名单、该 IP 是否为新购）。
2. SPF permerror / too many DNS lookups：精简 include 链，把邮件商的最终 IP 段用 ip4:/ip6: 直写；确认域上只有一条 SPF TXT。
3. DKIM fail 且公钥记录存在：核对选择器（签名头 s= 与 TXT 名一致）、密钥长度（低于 1024 位可能被拒）、长 TXT 是否被错误拆段；公钥变更后等待权威 TTL。

面试常问

• SPF、DKIM、DMARC 分别是什么？为什么三者要配合使用？ SPF 是声明哪些 IP 有权用本域发信的 TXT 记录，校验信封发件人；DKIM 用发信方私钥签名邮件、公钥发布在 _domainkey 子域，保证内容未篡改且域名背书；DMARC 位于 _dmarc 子域，规定 SPF/DKIM 失败时拒收还是隔离，并要求与 From 头对齐、收集报告。三者互补：SPF 管 IP、DKIM 管内容、DMARC 管策略统一，缺 DMARC 前两者失败没有强制后果，缺 DKIM 转发场景 SPF 易失效。

• 邮件服务器为什么需要 PTR 记录？ 收件方收到连接后会反向查询发送 IP 的 PTR，并与 HELO/EHLO 主机名、正向 A 做一致性校验。无 PTR 或 PTR 落在动态/住宅地址段是垃圾邮件的强特征，通常直接拒收或降权。PTR 由 IP 持有者（云厂商/运营商）管理，自建邮件要先确认能配反向解析再上线。

• 公司域名突然被大量冒名发钓鱼邮件，你怎么处理？ 立即检查/补齐 SPF（收紧到 -all）、启用 DKIM、把 DMARC 从 none 提升到 quarantine 或 reject，并配置 rua/ruf 观察来源；同时在邮件网关和安全团队侧加规则。若之前完全没配记录，冒名邮件此前在对端看起来毫无破绽——这也是即使不自建邮件也建议发 v=spf1 -all 和 reject 策略的原因。

自测三问

1. 一封发送到 user@coderoadmap.cn 的邮件，发件方依次做了哪两次 DNS 查询？
2. SPF pass 但 DMARC fail 的典型原因是什么？「对齐」指什么？
3. DKIM 密钥轮换的正确顺序是什么？为什么不能直接删旧记录？

小结一句话

MX 管收信，SPF/DKIM/DMARC 用三条 TXT 从 IP、内容、策略三层证明「我是我」，PTR 则在反向给发信 IP 做信誉背书。

延伸

• RFC 5321：SMTP 协议（MX 投递规则）
• RFC 7208：SPF
• RFC 6376：DKIM
• RFC 7489：DMARC
• 下一课预告：K8s CoreDNS——集群内部域名如何解析，CoreDNS 如何接管 svc.cluster.local。