DNS与邮件安全：理解SPF、DMARC和CAA发现

更改DNS前先列出所有合法发件方

包括员工邮件、客服、交易通知、账单、营销及仍运行的旧服务。记录可见From域名、信封发件人、DKIM签名域名和负责人。向每个提供商索取当前DNS要求，不要从其他公司的配置猜测include值。

工单保留查询名称、结果和时间。DNS超时不同于权威服务器明确返回记录不存在。异常结果应与DNS提供商核对，并考虑缓存。MX描述接收邮件，域名也可以不发布MX而发送。因此，没有MX时未出现相关警告，并不能证明发信安全。

适度理解策略风险

策略弱点不是伪造邮件已经进入收件箱的证据。记录存在也不是投递保证。优先处理登录链接、账单和客服使用的域名，因为冒用会直接损害信任。

修复SPF时不要丢失合法发件方

SPF根据信封域名策略评估连接的发送方，而非直接认证可见From地址。为域名发布一个一致的策略，只包含真正代发邮件的提供商。避免+all，在验证合法来源后决定最终策略。

协议把评估期间会触发DNS查询的项限制为十个，包括嵌套include和redirect带来的工作。Sitelemetry的文本直接计数只是提前预警，并非递归评估。请结合提供商指引核对整条链。先移除停用的发送方和多余机制；盲目把提供商include替换成固定IP，会在其基础设施改变时带来维护问题。

逐步把DMARC从观察推进到强制

DMARC将可见From域名与对齐的SPF或DKIM认证关联。通过其中一种对齐机制即可满足相应条件，并非总要两者同时通过。DKIM选择器因提供商而异，公开扫描无法可靠猜测所有签名密钥。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

这是监控策略示例。请改为你控制并能处理报告的邮箱；外部报告目的地可能需要DNS授权。分析报告，测试包括转发影响在内的全部正常邮件流。先修正对齐，再推进到quarantine或reject。不要在发送方清单不全时强制拒绝，导致密码重置或账单丢失。

RFC 9990：DMARC汇总报告

分清CAA与MTA-STS的职责

CAA说明哪些证书机构可为域名签发证书。限制必须匹配实际提供商，包括CDN托管证书和通配符需求。草率限制可能破坏续期。缺少CAA是加固机会，不是攻击者已经持有证书的证明。

MTA-STS允许支持它的发送方对入站邮件投递应用已发布的TLS策略。发现TXT只是其中一环，HTTPS策略文件、MX匹配规则和邮件服务器证书必须一致。强制之前应测试整个配置。这不同于网站HTTPS，没有该TXT也不能证明所有邮件都未加密。

同时验证记录和真实投递

1. 保存当前DNS值，并记录每个发送服务的负责人。
2. 通过权威DNS提供商发布审核后的变更，确认查询主机名。
3. 等待相关缓存有效期后复查记录，并重跑相同范围的审计。
4. 从每个合法服务向自己控制的测试账户发送受控邮件。
5. 查看收件方认证结果和DMARC报告，确认密码重置、账单及客服回复能收到。

把策略检查与投递监控分开。即使认证成功，信誉、收件方过滤和内容仍可能影响投递。记录DNS错误、未评估的选择器和未测试服务，不要让绿色摘要隐藏这些缺口。