我可以缩小 Office365 下 Outlook 使用的 SPF 范围吗？
Can I narrow the SPF ranges used by Outlook under Office365?
假设
使用 Outlook Online 服务的域的 SPF 记录通常涉及 include:spf.protection.outlook.com 机制，该机制依次级联成大量可能由 Microsoft 的分布式托管使用的 IP 地址。
据推测，这意味着如果在世界其他地方使用这些服务的任何帐户遭到破坏，他们可以使用任何合法 Outlook Online 域的伪造发件人地址发送垃圾邮件或类似的邮件内容，并且仍然通过 SPF ?
问题
鉴于 Outlook Online / Office365 的广泛采用，这似乎是一个相当大的 IP 范围，可能会损害 SPF。有什么方法可以限制 IP 地址范围的哪些部分可以用于域通过 Outlook Online 发送，从而将域的 SPF 记录中的 IP 范围限制为较少公开的内容？
附录
除了@Synchro 的有用答案，我可以看到一起使用 DKIM 和 DMARC 将有助于减轻 SPF 太容易通过的事实，但 DKIM 并不是一件容易实现的事情，我需要在我的 SPF 中覆盖其他机制如果我使 DMARC 严格，DKIM 也是如此。我的问题仍然存在，是否有一种方法可以在 Office365 下使用一组更窄的传出主机，可能使用相应的子集 'include'，就像 include:spf.protection.outlook.com 是更广泛的 include:outlook.com 的子集一样] ?
是的，您的假设是正确的，但是，您创建其 IP 范围的子集并不安全，因为它们可能随时更改，以及您的消息使用的源 IP，即 O365的SPF记录是动态的。这是 for 在 SPF 中使用 include 机制的主要原因，因此您不必维持这样的范围。另请记住，即使是 O365 的大范围也只代表 非常 一小部分互联网，甚至更小的欺骗消息源子集。
正确的方法是用 DKIM 补充 SPF。结合强大的 DMARC 策略，SPF 和 DKIM 的组合将为您带来想要的结果，因为即使有人可以通过您的 SPF，他们也无法伪造您的 DKIM 签名。
可以让 O365 为您的域进行 DKIM 签名，尽管它是 a rather convoluted process。
简短的回答：不，你不应该那样。
基本上，您信任 Microsoft 来管理 IP 范围，并以这样一种方式验证域所有权，即您租户中的其他人无法代表您发送。大量的子网部分是为了能够有效地路由，并且能够 fail-over 在数据中心出现故障的情况下。
这与可以代表您发送电子邮件的其他服务没有什么不同，例如 Oracle Eloqua（9.344 个单独的 IPv4 地址）和 MailChimp（22.528 个单独的 IPv4 地址）和 Google（322.816 个单独的 IPv4 地址）所有这些都倾向于包括大而多的子网。 DMARCIAN 有一个很好的工具来检查 SPF 并查看它由什么组成。
如@Synchro 的回答所述，这些子网是动态的/灵活的，由服务所有者管理。
我不确定我是否理解您关于 DMARC 的附录和@Synchro 的回答。 DMARC 的工作方式：它会在 SPF 或 DKIM 上寻找 通行证，以考虑通过身份验证的电子邮件 。还有更多内容，例如域对齐，但这有点超出了我们这个问题的范围。因此，作为 SPF 的补充，只有当您完全删除 Office 365 的 SPF 包含并且完全依赖 DKIM 身份验证来满足 DMARC 时，它才会起作用。
就个人而言，我喜欢同时拥有两者的冗余，因为 SPF 和 DKIM 在某些情况下都可能被破坏，例如邮件列表或转发规则。在 Office 365 中按域设置 DKIM 实际上非常简单。 All you need to do is create 2 CNAME records per domain and enable it.
最后，SPF 不是 anti-spoofing 圣杯，为此您应该查看 DMARC。 SPF 是在 return-path header 上检查的，而不是在收件人看到的电子邮件地址上检查的。因此，您的域很容易被欺骗，同时仍然在 return-path 电子邮件地址中使用的域上传递 SPF，除非您使用限制性 DMARC 策略（并且接收服务器实际上遵守 DMARC 策略）。
假设
使用 Outlook Online 服务的域的 SPF 记录通常涉及 include:spf.protection.outlook.com 机制，该机制依次级联成大量可能由 Microsoft 的分布式托管使用的 IP 地址。
据推测，这意味着如果在世界其他地方使用这些服务的任何帐户遭到破坏，他们可以使用任何合法 Outlook Online 域的伪造发件人地址发送垃圾邮件或类似的邮件内容，并且仍然通过 SPF ?
问题
鉴于 Outlook Online / Office365 的广泛采用，这似乎是一个相当大的 IP 范围，可能会损害 SPF。有什么方法可以限制 IP 地址范围的哪些部分可以用于域通过 Outlook Online 发送，从而将域的 SPF 记录中的 IP 范围限制为较少公开的内容？
附录
除了@Synchro 的有用答案，我可以看到一起使用 DKIM 和 DMARC 将有助于减轻 SPF 太容易通过的事实，但 DKIM 并不是一件容易实现的事情，我需要在我的 SPF 中覆盖其他机制如果我使 DMARC 严格，DKIM 也是如此。我的问题仍然存在，是否有一种方法可以在 Office365 下使用一组更窄的传出主机，可能使用相应的子集 'include'，就像 include:spf.protection.outlook.com 是更广泛的 include:outlook.com 的子集一样] ?
是的，您的假设是正确的，但是，您创建其 IP 范围的子集并不安全，因为它们可能随时更改，以及您的消息使用的源 IP，即 O365的SPF记录是动态的。这是 for 在 SPF 中使用 include 机制的主要原因，因此您不必维持这样的范围。另请记住，即使是 O365 的大范围也只代表 非常 一小部分互联网，甚至更小的欺骗消息源子集。
正确的方法是用 DKIM 补充 SPF。结合强大的 DMARC 策略，SPF 和 DKIM 的组合将为您带来想要的结果，因为即使有人可以通过您的 SPF，他们也无法伪造您的 DKIM 签名。
可以让 O365 为您的域进行 DKIM 签名，尽管它是 a rather convoluted process。
简短的回答：不，你不应该那样。
基本上，您信任 Microsoft 来管理 IP 范围，并以这样一种方式验证域所有权，即您租户中的其他人无法代表您发送。大量的子网部分是为了能够有效地路由，并且能够 fail-over 在数据中心出现故障的情况下。
这与可以代表您发送电子邮件的其他服务没有什么不同，例如 Oracle Eloqua（9.344 个单独的 IPv4 地址）和 MailChimp（22.528 个单独的 IPv4 地址）和 Google（322.816 个单独的 IPv4 地址）所有这些都倾向于包括大而多的子网。 DMARCIAN 有一个很好的工具来检查 SPF 并查看它由什么组成。
如@Synchro 的回答所述，这些子网是动态的/灵活的，由服务所有者管理。
我不确定我是否理解您关于 DMARC 的附录和@Synchro 的回答。 DMARC 的工作方式：它会在 SPF 或 DKIM 上寻找 通行证，以考虑通过身份验证的电子邮件 。还有更多内容，例如域对齐，但这有点超出了我们这个问题的范围。因此，作为 SPF 的补充，只有当您完全删除 Office 365 的 SPF 包含并且完全依赖 DKIM 身份验证来满足 DMARC 时，它才会起作用。
就个人而言，我喜欢同时拥有两者的冗余，因为 SPF 和 DKIM 在某些情况下都可能被破坏，例如邮件列表或转发规则。在 Office 365 中按域设置 DKIM 实际上非常简单。 All you need to do is create 2 CNAME records per domain and enable it.
最后，SPF 不是 anti-spoofing 圣杯，为此您应该查看 DMARC。 SPF 是在 return-path header 上检查的，而不是在收件人看到的电子邮件地址上检查的。因此，您的域很容易被欺骗，同时仍然在 return-path 电子邮件地址中使用的域上传递 SPF，除非您使用限制性 DMARC 策略（并且接收服务器实际上遵守 DMARC 策略）。