SPF、DKIM与DMARC详解:邮件发件人验证是如何运作的

曾几何时,任何人都能伪造邮件的"发件人"地址——这里讲清楚SPF、DKIM和DMARC是如何联手让这件事变得困难得多的。

邮件发件人伪造(欺骗)问题

SMTP是邮件收发所依赖的基础协议,它本身从来没有设计过验证发件人地址的机制。这意味着任何人都可以在"发件人"一栏原样填上某家银行或公司的地址,这也长期以来成为钓鱼邮件的根本基础。

SPF:发件服务器白名单

SPF(发件人策略框架)让域名所有者在DNS的TXT记录中登记"可以代表这个域名发送邮件的服务器列表"。收件服务器会检查实际发送邮件的服务器IP是否在这份列表中,以此来判断该邮件是否可能是伪造的。

DKIM:用数字签名检测篡改

DKIM(域名密钥识别邮件)在发送邮件时,用发件域名的私钥对邮件正文和部分主要邮件头进行签名,并将签名附加到邮件头中。收件服务器用DNS中公开的公钥验证这个签名,从而确认邮件内容自发出后是否被篡改过。

DMARC:综合结果制定策略

DMARC(基于域名的消息认证、报告与一致性)在SPF和DKIM检查结果的基础上,还会进一步核实实际显示的发件人地址是否与用于验证的域名一致(即"对齐")。域名所有者可以自行指定策略,决定验证失败的邮件是照常投递(none)、投入垃圾邮件(quarantine),还是直接拒收(reject),还能收到汇总验证失败情况的报告。

三种技术之间的关系

SPF和DKIM各自都是独立运作的认证手段,而DMARC则是位于两者之上的策略层,综合它们的结果来指示"验证失败时该如何处理"。只有三者同时具备,防止邮件伪造的效果才能真正发挥出来。

如何在收到的邮件中查看验证结果

打开邮件的原始邮件头,会看到一个名为"Authentication-Results"的字段,显示spf=pass、dkim=pass、dmarc=pass这样各项检查的结果。如果这些值显示为fail或none,就有必要重新怀疑一下这封邮件是否真的来自它所声称的发件人。

为什么三项检查缺一不可

仅靠SPF,攻击者仍可以从域名授权列表中的服务器发送邮件,同时伪造显示名称来绕过检测;仅靠DKIM,也无法验证显示出来的"发件人"地址是否与签名域名一致。DMARC通过要求显示发件人与实际通过SPF或DKIM验证的域名保持一致,填补了这个漏洞。这正是注重安全的组织不满足于只用其中一项、而要把三者组合配置起来的原因。

配置不当的严格DMARC策略会付出什么代价

如果在还没有把第三方营销工具、CRM系统等所有合法发件来源正确授权之前,就把DMARC策略过于激进地设为拒绝(reject),可能会导致本组织自己的合法邮件被其他邮件服务器悄无声息地拒收。多数组织通常会先从"none"(不采取行动)策略开始,收集报告以确认所有合法发件来源都已被识别,然后再逐步过渡到隔离(quarantine),最终升级到拒收(reject)。

常见问题

SPF验证通过,是否就能确定这封邮件一定是真实的?

不能仅凭这一点判断。SPF只能确认发件服务器是否获得了该域名的授权,并不能验证显示的"发件人"地址是否一致,也无法确认内容在传输过程中是否被篡改过。DKIM和DMARC正是用来弥补这些缺口的,所以这三者通常需要配合使用。

明明是合法邮件,为什么DMARC验证还会失败?

这种情况常见于通过第三方服务(比如营销平台或工单系统)发送邮件,却没有把该服务正确添加到域名的SPF记录中,或者没有为其配置专属的DKIM签名。负责管理某个域名邮件系统的人,需要把所有合法的发件来源都纳入授权范围,而不只是自己的邮件服务器。