第 1 幕 · 问题
伪造发件人
骗子把 From 写成你的银行或品牌,信封看上去和真的一模一样。收件人靠肉眼看显示名称,几乎分不出真假——这正是 DMARC 要解决的起点。
- From 头
- 品牌仿冒
- 钓鱼邮件
!显示名称可以随便写,真正的身份藏在域名和 DNS 里。
等不及?直接去生成记录PART A · 动画讲解
从一封假邮件出发,经过 SPF 港口、DKIM 蜡封、对齐检查与报告回港,最后爬上部署阶梯。点按播放,或自己一幕幕翻。
第 1 幕 · 问题
骗子把 From 写成你的银行或品牌,信封看上去和真的一模一样。收件人靠肉眼看显示名称,几乎分不出真假——这正是 DMARC 要解决的起点。
!显示名称可以随便写,真正的身份藏在域名和 DNS 里。
等不及?直接去生成记录第 2 幕 · 检查
邮件到了收件服务器,它不会直接相信信封上的字。它会去 DNS 查这个域名公布的规则:谁可以代发、有没有签名、验证失败后该怎么处理。
!判断发生在收件方,不在发件方;规则必须提前公布。
第 3 幕 · SPF
SPF(发件人 IP 授权)是一张「授权港口名单」。邮件只能从名单里的服务器出发;从别处开来的船,会被标记为可疑。
!SPF 只校验服务器 IP,邮件经过转发后容易失真,所以要配合 DKIM。
第 4 幕 · DKIM
DKIM 给邮件盖上一枚只有域名主能盖的蜡封(数字签名)。收件方用 DNS 里的公钥验封,途中被改一个字,封印就对不上。
!封印坏了不等于一定是骗子——转发也可能破坏签名,所以还得看对齐。
第 5 幕 · DMARC
DMARC 检查两件事:SPF / DKIM 是否「对齐」显示域名,以及验证失败时怎么办。p=none 只观察,quarantine 进垃圾箱,reject 直接拒收。
!「通过」还不够:通过但域名不对齐,DMARC 仍判失败。
第 6 幕 · 报告
域名主可以在记录里留下 rua(汇总报告)和 ruf(取证报告)地址。收件方定期把「谁在冒用你」写成报告寄回,像信鸽和报告船回港。
!ruf 含邮件内容片段,因隐私原因很多收件方已不再发送。
第 7 幕 · 部署
别一上来就用 reject。先用 p=none 收几周报告,确认营销平台、工单系统这些合法邮件都能通过,再升到 quarantine,最后 reject。
!阶梯可以停:小域名停在 none 或 quarantine,也远比没有记录好。
第 8 幕 · 收束
DMARC = 策略(policy)+ 对齐(alignment)+ 报告(reporting)。记住这三个词,就抓住了它的全部骨架:失败了怎么办、算不算你的域名、以及把结果寄回给谁。
!DMARC 不是单独的验证方法,它把 SPF / DKIM 的结果组织成一条可执行的规则。
去拼一条 DMARC 记录失败之后做什么:观察、隔离,还是直接拒收。
SPF / DKIM 的域名,是否就是邮件头里显示的域名。
用 rua / ruf 留下地址,收件方定期把结果寄回。
PART B · 动手
填几项,右边实时拼出 TXT 记录。生成的语法始终以 v=DMARC1 开头,空的可选标签会自动省略。所有计算都在本页完成,不联网。
PART B · 解读
已有一条 DMARC TXT?粘贴进来看中文说明,也可一键填回上方生成器。或者输入域名,用公共 DNS 查询 _dmarc 再解释。粘贴解读可离线;按域名查询需要联网。
支持完整 TXT,例如 v=DMARC1; p=none; rua=mailto:…。带引号、前后空白,甚至前面写了 _dmarc.example.com 主机名都可以。
查询 _dmarc.<域名> 的公开 TXT。示例:google.com、github.com。
查询走公共 DNS API(Google DNS-over-HTTPS),结果取决于公开解析,非合规审计。
上船前 · 检查清单
三条 TXT 记录互相配合:SPF 授权服务器,DKIM 公布公钥,DMARC 规定策略和报告地址。先有前两条,DMARC 才有意义。
主机名一般是 _dmarc,记录值以 v=DMARC1 开头。不同 DNS 面板的写法略有差别。
登录域名服务商的 DNS 面板 → 添加记录 → 类型选 TXT → 填入主机名与记录值 → TTL 保持默认或 3600。
用 dig TXT _dmarc.你的域名 确认。看到 v=DMARC1 后,先收一两周 rua 报告再收紧策略。
0 / 3 已确认
这只是提醒,不是完整的 SPF / DKIM 生成器;不同发信服务商的配置方式请以它们的文档为准。