Office365 SPF记录的查找过多

出于某些极其荒谬的管理原因，我们在Office365上使用一个邮箱拆分了一个域，这要求我们将其添加include:outlook.com到SPF记录中。问题在于，仅该规则就需要9次 DNS查询，最多10次。

说真的，这太可怕了。看看吧：

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

既然我们有我们自己的大十岁上下的邮件系统，我们需要有规则a，mx，include:_spf1.mydomain.com，和include:_spf2.mydomain.com这使我们在13 DNS查找其原因PERMERRORs的严格SPF验证，并与非严格/妥善执行验证完全不可靠/不可预测的验证。

是否有可能include:从ated肿的Outlook.com记录中删除其中3条规则，但仍涵盖O365使用的服务器？

编辑：

评论员提到我们应该只使用较短的spf.protection.outlook.com记录。虽然这是新闻对我来说，这是更短，这只是一个记录短：

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

编辑²

我想我们可以从技术上简化为：

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

但是我看到的潜在问题是：

我们需要及时了解对父项spf.protection.outlook.com和spf.messaging.microsoft.com记录的任何更改。如果有任何更改或添加[上帝禁止]，我们将必须手动更新以反映这一点。
使用我们的实际域名，记录的长度为260个字符，这将需要2个字符串用于TXT记录，老实说，我不相信所有DNS客户端和SPF解析器都会正确接受长度超过255个字节的TXT记录。

email spf microsoft-office-365

— 萨米奇
source

您不仅可以为所有Office365添加spf.protection.outlook.com吗？technet.microsoft.com/zh-CN/library/hh852557.aspx

— Cold T

为什么O365的SPF记录不是当前的简单记录？include:spf.protection.outlook.com （老实说，很好奇，从没看过您的设置...门户网站告诉您了所有这些设置吗？）

— TheCleaner 2013年

我发现所有使用的文档都在使用include:outlook.com，spf.protection.outlook.com对我来说也是新闻。但是问题仍然存在，因为该记录仍然需要8次查询，而我需要将其降低到6次或更低。

— Sammitch 2013年

不要忘记在“ spfa.frontbridge.com”下计算两个PTR查找。根据RFC 7208，它们也计入10个查询的限制。:(

— Martijn Heemels，2014年

Answers:

从最近的某个日期开始，Microsoft通过摆脱所有子记录并改用2或3个“ ptr”记录来“解决”此问题：

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

这就是问题所在：虽然这将帮助Office 365客户端避免停留在“查找过多” PermError以下...但这是通过强制世界上的每个邮件服务器对与其连接的每个IP地址进行（昂贵的）PTR查找来实现的。

根据SPF规范：

如果可能的话，应该避免在SPF记录中使用此机制，因为这将导致大量昂贵的DNS查找。

— 约翰·哈特
source

@ChrisS-我也考虑过，但是SPF规范确实指出“ ptr：”机制必须同时验证双向DNS-接收邮件服务器应首先在IP上进行PTR，然后在A上进行A结果主机名和IP必须在A记录中列出。因此，我认为这不是安全漏洞，至少不是为了使SPF实施符合标准。

— 约翰·哈特

啊，很好找到。我不知道警告。

— 克里斯S

我们也发现了这个问题。微软“鼓励”您仅将Office 365用于电子邮件，因为现在没有空间添加新项目。

我们解决问题的方式是双重的。

首先，我们可以通过添加其他条目作为显式IPv4条目来减少DNS查找。这使我们可以在添加一些显式IP之前include:outlook.com

其次，我们在主域下为Office 365设置了一个单独的子域。这样，电子邮件@ foo.company.com将获得Office 365 SPF，电子邮件@ comapny.com将获得我们的常规SPF。它不是完美的，但是幸运的是，我们使用Office 365的地方都能够使用子域而不是基本域中的电子邮件地址。

— 史蒂夫·希普韦
source