☰

SPF 过多 DNS 查找问题

tag-icon • tag-icon amazon-web-services spf amazon-route53 ptr-record dns-lookup
SPF 过多 DNS 查找问题

在我们的场景中，我们在 route53 中遇到了 SPF 记录问题。由于我们使用了多个邮件服务，因此我们收到 SPF 过多 DNS 查找。有办法解决这个问题吗？我看到一个线程说要对域进行查找并通过 IP 包含它们，但这似乎不是一个稳定的解决方案。另一个线程告诉我们 PTR，但这似乎是相同的路径。您知道有没有更好的方法可以实现这一点吗？

"Error! 15 DNS lookups required to evaluate the SPF record. The maximum is 10."

v=spf1 ip4:52.209.21.221 include:spf1.abc.com include:spf2.abc.com ~all

我们有 7 个邮件平台，这导致过多的 DNS 查找。

spf1.abc.com    -
    
"v=spf1 include:_spf.salesforce.com include:spf.protection.outlook.com include:mail.zendesk.com ~all"

spf2.abc.com    -
    
"v=spf1 include:amazonses.com include:sendgrid.net include:abc-com.spf.smtp25.com include:_spf.google.com ~all"

这种修改是否有帮助

"v=spf1 ip4:52.209.21.221 include:spf1.abc.com -all"

我们是否需要采用 SPF 平整技术？我们怎样才能实现这一点？有人可以就此给我一些建议吗？

答案1

如您所知，查询次数最多为 10 次。每次看到单词时，都会计算一次查询include；因此假设您的 DNS TXT 记录如下：

DNS 记录 价值
示例.com v=spf1 ip4:123.123.123.123 包括：spf1.example.com 包括：spf2.example.com -all
spf1.example.com v=spf1 包括：mail.thidparty.com -all
spf2.example.com v=spf1 包括：mail.thidparty2.com 包括：mail.thidparty3.com -all
mail.thidparty.com v = spf1 ip4：1.2.3.4/23 ip4：2.3.4.5/23 ~全部
mail.thidparty2.com v = spf1 ip4：2.2.3.4/23 ip4：3.3.4.5/23 ~全部
mail.thidparty3.com v = spf1 ip4：3.2.3.4/23 ip4：4.3.4.5/23 ~全部

除根域之外，您的包含内容中还引用了其他 5 条 DNS 记录，因此 SPF 查找计数为 5（根域不包括在计数中）；因此您最多可以有 5 个。

您可以通过此工具清楚地查看您的 SPF 记录（递归）： https://www.dmarcanalyzer.com/spf/checker/（还有许多其他的）。

注意：此计数是总递归计数；不仅仅是任何一条记录或任何单个分支上的查找次数；而是整个树/图的查找次数。

压平

我们可以做一些显而易见的事情来减少查找的次数；例如，spf1.exmple.com并spf2.example.com没有真正增加任何价值；所以我们可以删除这些记录并进行更新example.com以直接引用第三方 SPF 记录；从而从我们的计数中删除 2。

DNS 记录 价值
示例.com v=spf1 ip4:123.123.123.123 包括：mail.thidparty.com 包括：mail.thidparty2.com 包括：mail.thidparty3.com -all
mail.thidparty.com v = spf1 ip4：1.2.3.4/23 ip4：2.3.4.5/23 ~全部
mail.thidparty2.com v = spf1 ip4：2.2.3.4/23 ip4：3.3.4.5/23 ~全部
mail.thidparty3.com v = spf1 ip4：3.2.3.4/23 ip4：4.3.4.5/23 ~全部

执行此操作时要注意一件事：首先考虑一下为什么创建这些，因为它们只会增加复杂性……也许它们被其他域引用。例如，我的公司拥有许多域，其中一些将共享相同的服务（例如，我们使用 Office/Exchange 365 发送邮件，使用 ZenDesk 提供支持；两者都配置为从国家/地区特定的域发送电子邮件）。因为我们有这种共享，所以我们在主域中有一个 SPF 记录，其中包含所有这些域共享的服务，因此我们可以在一个地方管理它们/通过单个记录更新所有引用域。

为了进一步扁平化，您可以获取第三方的记录并将其值放入您的记录中，而不是include动态引用它。这里的问题是，如果第三方更改此记录的值，您的实现将会中断，因为您将获得错误的值。您可以通过让脚本监视原始记录（并自动通过更新更正您的记录，或在检测到问题时提醒您）来缓解这种情况，或者一些公司在 DNS 上实施自己的管理层，这意味着您可以定义您的查找，他们会为您扁平化 DNS 记录。我没有这方面的经验，所以不会链接到任何人；但简单搜索DNS Management Service SPF Flattening应该会给你一些选择。

注意：DNS TXT 值的字符串最大长度为 255 个字符。但是，每个记录可以有多个字符串；因此只需创建额外的值（本质上，您可以拥有一个 <=255 个字符串的数组，您可以在其中保存您的值）。

替代方案

删除服务

通常需要多个 SPF 记录，因为公司内的不同团队购买了满足相同要求的不同解决方案（例如 SMTPaaS 解决方案）。如果您可以整合提供商，您将能够删除其中一些。也就是说，这通常需要更多高级管理层的支持，而他们通常不了解这种情况的影响。

每个服务的子域名

尽管您的example.com域只能有 10 次查找，但您可以对support.example.com或进行完全独立的 10 次查找sales.example.com，因此您可以按功能（甚至服务）划分您的查找；例如zendesk.example.com：

DNS 记录 价值 笔记
示例.com v=spf1 包括：spf.protection.outlook.com -all 用户邮箱
支持.example.com v=spf1 包括：mail.zendesk.com ~all 支持票
销售.example.com v=spf1 包括：spf.protection.outlook.com 包括：_spf.salesforce.com ~all 销售系统通知

然后处理特定于这些子域的地址（例如，[email protected]用于您的服务台）。如果这些地址需要与真实邮箱相关联，您outlook.com还需要在相关子域中包含您的值（如上例所示Sales），但您很少需要对任何域进行所有查找（例如，SalesForce 和 ZenDesk 和 Outlook）。

请注意，您还可以使用电子邮件别名为同一个邮箱提供多个地址，因此即使您确实有一个需要与多个系统关联的邮箱，也许您可​​以为该邮箱设置不同的发件人地址，但仍然可以将对其中任何一个地址的回复解析为同一个目标邮箱。

文档

这虽然不是当前问题的解决方案，但有助于解决未来的问题。每次将服务添加到 SPF 记录时，请记录添加这些条目的原因。通常，企业中的人们会在不了解含义的情况下请求这些，然后在一切正常后忘记它们。很多时候他们会为临时要求而设置，但是当该要求不再存在时，没有人会想到通知您。通过记录事情，您可以定期检查您的记录并找到联系人以检查要求是否仍然存在（或者至少知道在哪里查看 ServiceX 是否仍然具有任何相关性），帮助您删除过时的服务或知道如果您需要将服务移出它自己的子域/等，该联系谁。

相关内容