你的DMARC记录里藏着一个安全隐患：报告域名过期后会发生什么

有个场景，让搞邮件安全的人夜不能寐：

你们公司花了好几个月部署DMARC，精心配置策略，天天盯着报告确保一切正常。结果呢？DNS记录里藏了个小问题，多年来一直在悄悄挖你邮件安全的后墙。

新西兰最大的橄榄球场——伊甸公园，就出了这么一档子事。安全研究员发现，这家场馆的DMARC配置把汇总报告和取证报告都发到了一个早就被放弃、过期三年多的域名上。

DMARC报告里到底有什么

先说说DMARC报告是怎么回事，为什么保护接收域名这么重要。

你在自己的域名上发布DMARC记录，就等于让全世界的邮件服务器每天给你发一份摘要，告诉你有哪些邮件声称是从你的域名发出的。

汇总报告（通过rua标签发送）包含很有价值的情报：谁在用你的域名发邮件、IP是多少、SPF和DKIM有没有通过，最关键的是——有没有人在冒用你的域名。

有些报告还会带上信封收件人数据，也就是这些报告真正的接收者。这些信息相当于给你公司的业务关系画了张活地图：和谁有邮件往来、用哪些供应商、接触过哪些政府部门、甚至哪个承包商在处理敏感项目。

研究员持有那个过期域名的期间，收到了超过12000条edenpark.co.nz的报告记录，发现大约600个不同的组织和这家场馆有过通信——从建筑承包商、餐饮公司，到体育协会、政府部门都有。

不保护报告目标的危险

这个漏洞的影响远不止你自己收不到安全报告这么简单。DMARC报告发到一个过期域名或不安全的域名，可能引发一连串问题：

1. 情报被偷走：这次案例就证明了这点——谁注册了那个被遗弃的报告域名，谁就能收集到你公司邮件规律、业务关系、第三方邮件服务商的大量信息。

2. 预警系统失灵：你的公司对域名被冒用、钓鱼攻击、品牌被利用等情况统统看不见了。

3. 合规出现盲区：很多行业都要求企业对邮件认证失败保持可见。报告域名一过期，合规漏洞就这么悄悄产生了，可能等到审计时才被发现。

这种情况是怎么发生的

伊甸公园的案例暴露了一个常见坑：在DNS记录里引用第三方服务，却从来没去关注这些服务的生命周期。

这次的情况是，报告域名（spamcontrol.co.nz）属于一个富士通的邮件过滤服务，2021年就已经停用了。伊甸公园DMARC记录里的引用，比这个服务本身还长寿。

这种事比你想象的常见多了。很多公司都会：

• 当时设置DMARC报告发到供应商域名的地址
• 后来换了供应商或者停用了服务
• 老DNS记录从来不清理
• IT人员一离职，相关知识也跟着没了

结果就是DNS记录指向的域名，最后被别人注册走了。

怎么保护自己

那怎么才能避免自己的DMARC报告跑到别人邮箱里？

1. 定期检查DMARC记录：至少每个季度检查一遍所有邮件认证的DNS记录。确认rua和ruf标签里引用的每个域名都在正常使用、都是安全的。

2. 用自己的域名收报告：把DMARC报告配置到你自己域名下的地址，或者你直接控制的域名。这样谁有权限访问，完全由你说了算。

3. 盯好域名到期日期：如果必须用外部域名收报告，那就建个日历记着这些域名什么时候到期，主动续费别忘了。

4. 监控报告投递情况：设置提醒或仪表盘，报告收不到的时候及时通知你。报告数量突然变少，可能就是报告域名出问题了。

5. 改成 p=quarantine 或 p=reject：虽然这不直接解决报告目标的问题，但摆脱p=none能大大降低域名被冒用的风险。别人就算拿到了你的报告，能挖到的有价值信息也少得多。

更重要的教训

伊甸公园这件事提醒我们一件事：邮件安全不是一次配置完就撒手不管的。支撑你邮件认证的DNS基础设施，和认证策略本身一样，都需要持续关注。

现如今邮件依然是商业被黑、钓鱼攻击的主要渠道。维护好邮件认证基础设施的完整性，不只是技术最佳实践，更是业务刚需。

现在花点时间检查一下你的DMARC记录，确认一下报告目标是安全的、没过期、在你控制之下。

毕竟，你最不想看到的就是——你的安全配置变成别人的情报来源。

NameOcean帮助企业从域名注册到DNS配置全面保障在线业务安全。我们的团队可以协助DMARC部署、DNS安全检查，确保你的邮件认证基础设施配置正确。