一份邮件协议文档很少能引出争议,但RFC 9989做到了。它把DMARC的判断范围写得很窄:只看可见的From地址有没有通过对齐的SPF或DKIM结果拿到授权,不看邮件内容,不看链接,不看攻击者的意图。这个窄范围恰恰是问题所在——很多团队把域名策略调到p=reject,以为自己已经挡住了钓鱼邮件,实际上挡住的只是"冒用你家域名"这一种攻击。
这不是危言耸听。RFC 9989和CISA、微软、NIST的公开文档拼在一起,能列出至少七八种在p=reject下依然能顺利通过认证的攻击路径。这份清单,比"DMARC=反钓鱼"这句流行说法要长得多,也危险得多。
p=reject挡得住的,只有"冒充你家域名"这一种
DMARC能验证的只有一件事:发件人是不是真的有权用你家域名发信。CISA把这种防护明确定义为针对"直接域名伪造"的最强手段——攻击者在From里写your-bank.com,却没有对齐的SPF或DKIM,p=reject会请求收件方拒绝这封信。
这条防线是硬的。它还带来一个额外收益:aggregate报告会把所有代你域名发信的系统曝出来,帮你揪出那个被遗忘的营销工具或配置错误的转发服务器。
但RFC 9989写得很清楚:DMARC只校验域名,不校验显示名,也不校验本地部分。一个攻击者只要不冒用你的域名,DMARC对他毫无约束力。
从近似域名到账户被攻陷:八条路径都能过关
原文只提到近似域名一种局限,实际的攻击矩阵要宽得多。显示名伪装是最容易被忽略的一种——收件人看到的名字是"某银行安全中心",实际地址却是完全不相关的域名,DMARC照样判定通过,因为它压根不检查显示名。
更麻烦的是账户被攻陷。攻击者用钓来的凭证登录一个真实邮箱,通过合法基础设施发信,SPF、DKIM、DMARC三项全过,因为在协议眼里这就是"授权发信"。NIST的文件专门点出这一点:域名级认证机制天生识别不出账户背后是不是真人在操作。
供应商或合作伙伴账户被滥用、DKIM私钥被窃取、SPF记录配置过宽把不该信任的第三方也纳入授权、Reply-To字段被单独篡改、邮件会话被劫持——这些场景的共同点是:每一种都能拿到干净的DMARC通过结果。
- 风险.
p=reject打开后,团队容易把"域名不会被冒用"等同于"邮箱是安全的",从而砍掉本该保留的账户安全和内容审查预算。
"拒绝"是请求,不是命令
p=reject这个词本身就有误导性。RFC文档写的是收件方"应当拒绝",但收件方始终保留最终裁量权,可以结合自己的反滥用信号做出不同处置——也就是说,同一封失败邮件,在A邮箱服务商那里可能被拒,在B邮箱服务商那里可能因为白名单规则被放行。
微软把"域名与用户伪装保护"做成了独立于DMARC的检测功能,专门盯近似域名和被伪装的用户身份,这个动作本身就说明主流邮箱厂商也认定DMARC覆盖不到这块。CISA的配套建议则落在账户层面:优先部署抗钓鱼的多因素认证,尤其是FIDO2安全密钥或passkey,把"账户被攻陷"这条最难防的路径先堵一半。
该补的层,和该核实的数字
把这些信息拼起来,能看出一条清楚的分层逻辑:DMARC解决域名归属问题,抗钓鱼MFA解决账户被攻陷问题,伪装检测功能解决近似域名和显示名问题,剩下的内容审查和人工核实,解决"认证通过但邮件本身在骗你"的问题。四层缺一层,攻击面就露一块。
有一个数字反而要谨慎对待:目前没有权威口径统计全球DMARC采纳率——不同统计是否计入p=none、是否剔除停用域名,差异很大。任何"全网多少域名已部署DMARC"的说法,读者和媒体引用前都该先问一句统计口径是什么。
对企业IT和安全团队来说,现实的动作清单很短:先确认自己的域名认证策略处在哪个阶段,再单独评估账户安全(MFA覆盖率)和近似域名监测是不是已经补上,而不是把p=reject当成一次性的安全升级。