信誉良好的域或共享发送服务可能成为滥用消息路径的一部分。有用的问题不是基础设施是否普遍值得信赖。这是该特定消息是否被授权使用经过身份验证的身份。身份验证和业务授权回答不同的问题。
定义重用的权限
受感染的邮箱可能会通过其普通的经过身份验证的路由发送。过于广泛的网络授权可能会接纳非预期的来源。中继可能会在接受规则不够具体的情况下接受消息后对消息进行签名。这些机制有不同的所有者和补救措施。不要将它们归结为一项无法解释的声誉劫持指控。
最初的 BreakSPF 研究调查了宽容 SPF 配置和共享基础设施。其威胁模型使源网络访问成为核心条件。这是部署边界，而不是攻击者可以伪造任何内容的证据 DKIM签名. BreakSPF 纸，第三部分。将本文的测量视为历史研究，而不是当前脆弱服务的清单。
建立精确的威胁模型
分别写入受保护域、经过身份验证的标识符、允许的源集、攻击者能力和接收者决策。在此处的有界场景中，brand.test 为SPF授权192.0.2.0/24 。批准的应用程序使用192.0.2.10 ，而假设的非预期租户可以源自192.0.2.99 。这两个地址均位于已发布的范围内。实际服务中是否存在此类租户访问需要单独的证据。
SPF检查其评估身份的源授权。它无法识别共享 IP 背后的人。如果传递的SPF身份也与作者域一致，则该路径可以满足 DMARC 没有 DKIM. RFC 7208 和 RFC 9989。因此，成功的评估可以揭示授予了过多的权限，而不是接收者忽略了通过规则。
比较三个书面授权案例
假设来自alerts@brand.test可见，非空 邮件来自 bounce@brand.test ，无DKIM签名，以及其他合格的DMARC评估。比较假设 SPF记录 v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- 批准的源192.0.2.10 ：两个网络前缀都包含在内； SPF通过并与 Brand.test 保持一致，因此说明性消息在任何一种情况下都通过DMARC 。
- 非预期来源192.0.2.99 ：包含在 /24 中，但不包含在 /32 中； SPF仅在广泛记录下通过。如果没有DKIM签名，规定的DMARC结果在 /24 下通过，在 /32 下失败。
- 外部源198.51.100.10 ：不包含任何前缀； - 在任何一种情况下， -all产量SPF都会失败。如果没有DKIM签名，则规定的DMARC结果两者均失败。
这些被写成前缀成员资格和 结盟 扣除，而不是正在运行的SPF解析器、 DNS观察或 BreakSPF 的再现。源代码控制是假设的，没有演示。没有测试外部消息或实时服务。本文的跨协议技术不在本教学示例之内。
单次传递对齐机制可以满足消息的DMARC传递条件。这并不意味着仅 SPF 部署就足够了： RFC9989第 7.4 节需要有效的DKIM才能进行域发布 p=reject，第 8 节讨论了充分参与。这些是单独的部署职责，而不是额外的每条消息传递门。
确定责任边界
在缩小实际SPF记录范围之前，请清点每个合法发件人并遵循提供商支持的配置。仅当专用源实际上是独占的并得到维护时，它才有用。确认发送服务将客户与其允许的身份绑定；验证DKIM配置并通过更改控制删除过时的权限。
更改后监视特定于路由的故障，保留恢复计划并记录未知发件人。不要用本示例中猜测的 IP 列表替换广泛的记录。我们的教训是协调授权与实际服务所有权，而不是将演示DNS复制到生产中。