SPF 记录是遗留的吗?

Rom*_*nSt 37 email spf

我负责一个域,该域具有代表该域发送邮件的各种其他服务所推荐的 SPF 记录。

在设置 Mailchimp 时,我惊讶地发现没有关于 Mailchimp 推荐的 SPF 设置的文档。当我联系支持人员时,我被告知 Mailchimp 基本上考虑了 SPF 遗留问题,6 个月以上没有使用 SPF,并认为拥有记录无济于事。甚至建议我完全删除我们的 SPF 记录。

我不怀疑 Mailchimp 比我更了解电子邮件的可送达性。但我感到惊讶的是,Mailchimp 不会发布任何解释此决定的内容,尤其是考虑到代表我们发送电子邮件的所有其他提供商都继续推荐使用 SPF,包括 G-Suite。

那么到底是怎么回事,2020 年 SPF 没用了,我是否应该担心我们的 SPF 记录中没有 Mailchimp 的服务器,我是否应该考虑完全删除 SPF 记录?

Esa*_*nen 44

正如@jornane指出的那样,Mailchimp 使用他们自己的域作为信封发件人,使得客户域的 SPF 记录与其交付方案无关。这使得 DKIM 签名对于正确的 DMARC 对齐是必不可少的,因为不会有来自 SPF 方面的对齐。

然而,考虑到他们确实为自己的域设置了 SPF,说 SPF 是传统的说法是一种奇怪的说法mailchimp.com。尽管他们自己没有记录,但根据 DMARCLY 关于如何为 Mailchimp 设置 SPF 和 DKIM 的文章(2020 年 12 月 9 日更新),Mailchimp 的正确 SPF 包括:

include:servers.mcsv.net
Run Code Online (Sandbox Code Playgroud)

这个 SPF 记录仍然存在,并且据说有他们使用的 IP 地址:

"v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all"
Run Code Online (Sandbox Code Playgroud)

我认为这种说法可能来自电子邮件交付行业对 SPF、DKIM 和 DMARC 的偏见。在他们的言辞中,这些技术都是关于更好的声誉或优化的交付。他们只将它们视为将消息发送到收件箱的工具,而不是防止他人从您的域中欺骗邮件的硬币的另一面。当这样的公司试图解释这些技术的好处时,情况几乎总是如此。但这并不是真正的好处,也不是它们最初被发明的原因!

Mailchimp 可能只是进一步考虑了这个想法:“如果 SPF 不能帮助我们发送邮件,那么它一定是无用的”。在我看来,如果他们真的发表了这样的声明,他们是毫无头绪的。这种心态是有害的,因为它甚至可能会阻止他们的客户转向更严格的 DMARC 政策。 观察到 Mailchimp 使用他们自己的域作为信封发件人,可以更好地解释这一点。

  • 有趣的点,谢谢。顺便说一句,那篇文章的屏幕截图描述为_“同时包含 SPF 和 DKIM 设置的模式”_,但实际对话框显示的是两个 DKIM 条目。发布日期相当狡猾......它肯定早在[8月8日](http://web.archive.org/web/20200811191823/https://dmarcly.com/blog/how-to-set -up-spf-and-dkim-for-mailchimp)。 (2认同)

Aus*_*arn 21

由于 SPF 的历史,这有点复杂,但是:

  • MailChimp 关于SPF 记录本身在技​​术上是正确的(而不是提供TXT带有 SPF 策略的记录)。
  • 他们几乎肯定不会建议您完全停止使用 SPF。

SPF 的原始实现TXT在域本身上查找符合特定格式的DNS记录(从v=spf1有效 SPF 策略的其余部分开始并包含这些记录)。2005 年,IANA 为特定SPF记录分配了资源记录类型 99 以在理论上替换它以提供 SPF 策略(理论上的优势是您可以SPF专门查询记录,而不必查询所有TXT记录然后解析所有记录看看是否有有效的政策)。

但是,出于兼容性原因,专用SPF记录类型的实际使用率从来没有很高。网络运营商仍必须TXT使用 SPF 策略定义记录,以便 SPF 的旧实施仍然有效,并且实施者必须支持在TXT记录中查找 SPF 策略以保持与现有网络的兼容性,因此双方都没有任何真正的动机去专门切换到使用专用SPF记录类型,特别是因为大多数域没有大量TXT记录,因此从这些记录中解析策略通常非常快。

由于采用率低,SPF 工作组在 2014 年决定正式放弃对专用SPF记录类型的支持,因为它没有真正贡献任何东西,没有真正被使用,并且在某些情况下会造成混淆(例如混淆这里)。

因此,该SPF 记录确实已被弃用,但仍然强烈建议在记录中提供 SPF策略TXT,即使您的域实际上并不处理电子邮件(在这种情况下,您应该定义 策略v=spf1 -ALL)。

  • 不幸的是,我使用了不精确的术语。与我通信的人将其称为“SPF txt 记录”和“SPF txt 旧值”,因此我很确定他们始终指的是“TXT”记录,而不是现已停用的专用“SPF”记录类型。 (2认同)
  • 你的历史课是对的。但是,术语上没有这样的问题:SPF 记录被正式称为 SPF 记录,尽管它们存储为 TXT 记录。[RFC 7208, 3](https://tools.ietf.org/html/rfc7208#section-3) 以这种方式定义了 **SPF 记录**:“SPF 记录表示为在单个 DNS TXT 资源记录的 RDATA;同一所有者名称不允许有多个 SPF 记录。” (2认同)

joe*_*rty 10

这只是一个供应商的意见。

是的,他们在电子邮件可传递性方面拥有特定的专业知识,但许多其他继续推荐使用 SPF 记录的供应商也是如此。

拥有正确构建的 SPF 记录不会对您的电子邮件送达率产生负面影响。在您的 SPF 记录中包含 Mailchimp 不会对您的电子邮件可传递性产生负面影响......所以如果是我,我会继续维护正确构建的 SPF 记录。

  • 他们只拥有电子邮件可送达性方面的专业知识,而没有电子邮件安全和反欺骗方面的专业知识。 (10认同)

jor*_*ane 9

MailChimp 发送邮件的方式与 SPF 不兼容,因此他们弃用它是有道理的,他们以他们的方式代表您发送的情况下

MailChimp 想要为您处理退回邮件,这要求他们将 Envelope From 地址设置为他们自己的域,这意味着 SPF 应该根据他们的域进行检查,而不是您的域。因此,他们要求您在您的 SPF 政策中允许他们是没有意义的。这也是一些客户端在 From 字段中显示“via mailchimp”的原因。

SPF 没有被弃用,但它不适合邮件列表和类似情况。DKIM 在 From 标头上工作并由发件人进行加密签名,因此它对转发器具有更强的抵抗力,并且更容易委托给第三方。MailChimp 专注于这一点更有意义。

对于您自己的外发邮件服务器,您应该维护 SPF、DKIM 和 DMARC(通过正确执行前两个,您基本上可以免费获得第三个)