CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
DNS 与域名解析/课时/邮件相关记录
RawBlame
课时目录12 节

DNS 与域名解析

  1. 01DNS 是什么
  2. 02记录类型
  3. 03解析过程
  4. 04域名层次
  5. 05诊断工具
  6. 06本站域名配置
  7. 07DNS 与 HTTPS
  8. 08邮件相关记录
  9. 09K8s CoreDNS
  10. 10常见故障
  11. 11DNS 与 CDN
  12. 12综合练习

邮件相关记录

MX、SPF、DKIM 直觉。

25 分钟

邮件相关记录

这一课你将能做到

  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 TXTRFC 规定只允许一条,直接 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。
加载本节练习…
← 上一课DNS 与 HTTPS下一课 →K8s CoreDNS