☰

为共享托管域名设置 SPF 是否有用

tag-icon • tag-icon spf
为共享托管域名设置 SPF 是否有用

我现在有点困惑：

据我所知，SPF 记录应该验证来自发送邮件服务器的 MAIL-FROM 和可能的 HELO。如果我在共享托管环境中，无法访问邮件服务器配置，为什么我应该将 SPF 记录添加到我的域 DNS？

例如在 1and1 doku 中我发现：https://help.1and1.com/domains-c36931/manage-domains-c79822/dns-c37586/explanation-of-an-spf-record-a792807.html这表明我应该补充

 include:_spf.kundenserver.de

到 SPF 记录。

但是当我查看 MAIL FROM 和 EHLO 信息时，当我从[电子邮件保护]它仅包含：

$receivingServer>> grep 'MAIL FROM' /var/log/mail.log
mout.kundenserver.de[212.227.126.133]: MAIL FROM:<[email protected]> SIZE=1534

$receivingServer>> grep 'EHLO' /var/log/mail.log
mout.kundenserver.de[212.227.126.133]: EHLO mout.kundenserver.de

$receivingServer>> grep 'exampledomain.com' /var/log/mail.log
[empty]

所以我的问题是：在这个环境中添加建议的 SPF-Record 真的有用吗？SPF-Validator 是否会查看电子邮件标头中的 FROM-Domain？

先感谢您。

答案1

EHLO/HELO 无关紧要，它只是标准推荐的，经常被忽略。使用 SPF，接收方会检查发送服务器（不一定与其主机名/地址完全相同）是否被允许向 MAIL FROM 地址的域发送电子邮件。

因此，如果有人收到一封来自（作为信封的发件人/返回路径）的邮件[email protected]，则可以检查发送服务器是否被允许这样做。如果发送服务器仅由您的提供商提供，请使用include:_spf.kundenserver.de -all。

如果您不以您的域名作为MAIL-FROM发送电子邮件，您可以将其设置为-all。

答案2

在这个特定的例子中，有些事情混淆了：你的消息是从共享主机网络空间发送的，当你的邮件发送脚本没有指定 MAIL FROM 地址时（使用“sendmail -f[电子邮件保护]“）。因此，在此示例中，您自己的域根本没有被使用。使用的域 (kundenserver.de) 确实有一个 SPF 记录，其中包括使用的邮件服务器 212.227.126.133，因此纯 SPF 检查对于示例消息确实有效 - 但这可能不是您想要使用的配置类型，因为您可能会遇到进一步的麻烦。

一般来说，SPF 记录对于任何类型的邮件发送域都很重要，无论它托管在何处或如何托管。

SPF 本身可以保护您的域名免受非法垃圾邮件（在 MAIL FROM 中使用您的域名）的侵扰。

向您的域添加 SPF 记录可指定哪些邮件服务器被允许代表您的域发送邮件。这可以（在一定程度上）保护您的域免受垃圾邮件发送者的滥用，但也可以（稍微）在发送邮件时为您提供优势。

简化：

  • 如果存在 SPF 记录，并且发送服务器位于该 SPF 记录的列表中，则该邮件将被视为来自您域的“真实”邮件。这并不能保证您的邮件被作为“非垃圾邮件”发送；但是，如果您的发送服务器不在 SPF 记录的列表中，则该邮件更有可能被拒绝或发送到收件人的“垃圾邮件”文件夹中。
  • 如果您的邮件/域没有 SPF 记录（也没有类似 DKIM 的记录），接收服务器将无法知道该邮件是否合法地从您的域发送。由于大多数合法邮件都是使用 SPF 和/或 DKIM 发送的，因此接收邮件服务器上的垃圾邮件过滤器更有可能将您的邮件作为“潜在垃圾邮件”路由到收件人的“垃圾邮件”文件夹中。
  • 如果 MAIL FROM 地址为空，则没有要发送错误消息/退回邮件的地址或域；通常，这仅用于发送退回邮件。在这种特殊情况下，将使用 HELO/EHLO 中使用的域的 SPF 记录。

除了 SPF，还需要提到 DKIM 和 DMARC。

SPF 是最古老的标准，但同时也是最薄弱的标准。SPF 不会验证邮件的发件人标头，因此无法防范某些网络钓鱼案件。众所周知，每当邮件被自动转发时，SPF 都会产生意想不到的结果（转发服务器不太可能列在您域的 SPF 记录中，因此转发可能会失败）。

在 SPF 中，关于如何使用默认策略存在一些困惑。SPF 检查可以在实际邮件被读取以进行投递之前在 SMTP 级别执行，因此“硬”SPF 策略 (-all) 可能会产生严重的副作用，并且可能在任何其他检查或垃圾邮件过滤器之前应用。因此，一般来说，建议对 SPF 使用中性 (?all) 或软故障 (~all) 默认策略。然后，SPF 会有效地成为有利于您合法发送邮件服务器的凭证。

DKIM 确实解决了 SPF 的一些问题，但实施起来不如 SPF 容易。DKIM 要求向您的邮件服务器添加加密私钥，并为您的域添加特殊的 TXT 记录（相应的公钥）。每当您的邮件服务器确实（合法地）使用您的域发送邮件并支持 DKIM 时，它都会在一系列其他邮件头（包括发件人头）上添加数字签名，以证明该邮件是合法使用您的域发送的。然后，接收服务器可以使用 DKIM 特定的 TXT 记录验证该签名（特殊头）。DKIM 没有默认策略：有效签名只是对该邮件有利的凭证，无效签名将被忽略（它们可能会在通过某些邮件列表服务转发时意外损坏）。

您的域名/邮件服务器支持 SPF、DKIM 或最好同时支持这两种标准非常重要。

DMARC 确实将 SPF 和 DKIM 与其自己的策略结合在一起：

  • MAIL FROM 中使用的域必须与邮件发件人标头中使用的域完全相同或为其子域 - 或为空（用于退回邮件）。默认添加的“cgi-mailer-bounces-${some_id}@kundenserver.de”很可能会破坏 DMARC），因此您应该在发送邮件时指定您的域。
  • 如果任何 DKIM 签名标头与邮件发件人标头中使用的域相符，则 DMARC 接受该邮件。
  • 如果存在 SPF 记录，并且 SPF 检查验证了邮件“发件人”标头中使用的域（而不是 MAIL FROM 域），则 DMARC 会接受该邮件。
  • DMARC 确实明确规定了如何处理 DMARC 违规行为：忽略（“监控模式”）、拒绝或路由到垃圾邮件文件夹。DMARC 还规定了是否以及如何报告此类违规行为。

业界对 DMARC 的支持正在日益增多。

这就是对你的问题的完整回答： - 当你使用 DMARC 时，接收邮件服务器会根据邮件的发件人标头评估你的 SPF 记录。 - 你至少应该在你的域中添加一个 SPF 记录，同时使用你的网络主机推荐的“include:_spf.kundenserver.de”和中性（“？全部”）或软失败（“~全部”）默认策略。 - 如果你的主机支持 DKIM，也请使用它（否则：要求他们支持它……）。 - SPF 和 DKIM 都会增加（或者：它们的缺失可能会降低）你成功传递邮件的机会。你应该至少支持其中一种。 - 你可能想要考虑使用 DMARC，因为它确实使用了 SPF 和 DKIM，同时解决了这两个标准的一些问题。除非你真的知道自己在做什么，否则不建议使用没有 DKIM 的 DMARC（因此仅依赖 SPF）。

相关内容