这句话 DMARC 旁路可以描述非常不同的事件。来自过度授权来源的有效通行证、尽管结果失败但仍进行交付以及实施错误并不是相同的失败。从可证伪的主张开始：主张哪个身份、哪个证据可信以及哪个决定与预期规则不同？
重建观察到的决策
保留作者域、信封域、签名域、可信身份验证结果和接收者配置。记录政策和观察时间。正在传递的消息本身并不证明DMARC通过。接收方处理包括本地政策，域所有者请求的处理并不是通用的递送保证。 RFC 9989.
同样，复制的 Authentication-Results 字符串并不是接收系统决定的证明。建立可信认证服务和相关跃点。 RFC 8601。如果唯一的证据是显示“通过”的屏幕截图，则将声明保留为未解决，直到基础身份和信任上下文可用。
将过度授权与规则规避分开
BreakSPF 研究了如何宽容 SPF 对共享基础设施的授权和访问可以允许 欺骗。其威胁模型为攻击者提供了合格的源路径；然后接收者可以评估所发布的书面授权。 BreakSPF，第 III.A 节和图 3.
如果攻击者控制的源位于授权范围内并使用对齐的信封身份，则普通通过规则可以成功。弱点在于授予的权限或服务边界，而不是DMARC的新定义。相反，如果仅对不相关的身份进行身份验证并且作者域未对齐，则声明的通行证需要不同的解释。
对三个假设发现进行分类
假设来自alerts@brand.test的单个可见以及其他合格的DMARC评估。这些是书面假设，而不是观察到的事件。
- 授权案例：源192.0.2.99在规定的SPF ip4:192.0.2.0/24范围内； 邮件来自 bounce@brand.test通过SPF ；不 DKIM签名。对齐的SPF路径会生成消息级DMARC通行证。询问该来源是否确实可以由非预期发件人控制以及哪个所有者授予其权限。
- 处理案例：MAIL bounce@other.test通过SPF且 DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed 结盟 结果。
- 证据案例：复制的标头显示通过，但受信任的接收者来源、评估的身份和应用的策略未知。既没有建立违反协议的行为，也没有建立可信的通行证。索取原始记录和接收方记录。
授权的肯定发送者192.0.2.10和外部源198.51.100.10可以在调查第一个案例时提供建议的控制。假设的ip4:192.0.2.10/32 -all记录只承认前者；此前缀算术不会产生真正的生产变化。这里没有执行解析器、签名检查或利用。
RFC9989第 7.4 节需要有效的DKIM才能进行域发布 p=reject。传递对齐的SPF机制足以满足特定消息的传递条件，但不建议仅执行 SPF。
让发现具有可操作性
说出重现的情况和仍然缺失的证据。一个有用的发现表明，指定的来源由指定的授权所承认，并确定了负责任的所有者。这并不是说所有DMARC保护都已失效。检查真实服务是否限制租户身份、来源是否可控、接收方是否应用了所声明的结果。
在测试提议的缓解措施时，保留无害的授权积极控制。缩小范围或更改连接器可能会破坏合法发件人。要求特定路线的变更批准和变更后验证，并明确解决未在实验室中测试的提供商行为。这支持精确修复，而不会将教育模型夸大为生产漏洞。