假设
使用Outlook Online服务的域的SPF记录通常涉及include:spf.protection.outlook.com机制，该机制反过来又级联为可能由Microsoft的分布式主机使用的大量IP地址。
大概这意味着，如果在世界其他地方使用这些服务的任何帐户遭到破坏，它们可以使用任何合法Outlook Online域的伪造发件人地址发送SPAM或类似的邮件内容，并且仍然可以通过SPF吗？
问题
考虑到Outlook Online / Office365的广泛使用，这似乎是一个很大的IP范围，可能会损害SPF。是否有任何方法可以限制域可用于通过Outlook Online发送的IP地址范围的哪些部分，从而将域的SPF记录中的IP范围限制为不那么暴露？
附录
除了@Synchro的有用答案外，我可以看到将DKIM和DMARC一起使用将有助于减轻SPF传递过于容易的事实，但是DKIM并非容易实现的事情，我需要在SPF中涵盖其他机制如果我使DMARC严格，也请使用DKIM。我的问题仍然存在，是否有一种方法可以像使用include:spf.protection.outlook.com是更广泛的include:outlook.com的子集一样，在Office365下使用较窄的传出主机集（可能带有对应的子集“ include”）？
答案 0 :(得分：2)
简短的回答：不，您不想要那样的话。
基本上，您是信任Microsoft来管理IP范围，以及以一种方式来验证域所有权的方式，即除了您自己的租户外，租户中的某人无法代表您发送邮件。大型子网的一部分是为了能够高效路由，并且在数据中心发生故障时能够进行故障转移。
这与可以代表您发送电子邮件的其他服务没有什么不同，例如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并不是反欺骗的圣杯，您应该为此考虑DMARC。在返回路径标头上而不是在收件人可以看到的电子邮件地址上检查SPF。因此，除非您使用限制性DMARC策略（并且接收服务器实际上遵守DMARC策略），否则您的域仍很容易被欺骗，同时仍在返回路径电子邮件地址中使用的域上传递SPF。
答案 1 :(得分：1)
是的，您的假设是正确的，但是，您无法安全地创建其IP范围的子集，因为它们可能随时更改，以及消息所使用的源IP，即 O365的SPF记录为动态。这是在SPF中使用include机制的 的主要原因，因此您不必维护此类范围。还请记住，即使O365的范围很大，也仅占Internet的非常比例很小，并且欺骗邮件源的子集甚至更小。
正确的方法是用DKIM补充SPF。将SPF和DKIM结合使用，再加上强大的DMARC策略，将为您带来理想的结果，因为即使有人能够通过您的SPF，他们也无法伪造您的DKIM签名。
尽管它是a rather convoluted process，但仍可以让O365为您的域进行DKIM签名。