SPF-我应该实施吗？

网络开发人员已请求我们的域DNS记录包含SPF TXT记录。我对此有不同的看法...

您提供的任何意见或见解将受到高度赞赏。我知道这本身并不是一个经验性的问题-但我还是要感谢您的主观产品...尤其是如果它们与我可以参考的参考资料一起出现，例如网络帖子或在线文档等。

是。我不会说这是主观的，因为已经有了明确的共识。使用SPF。

实施非常容易，对整个互联网来说都是一件好事。

您可能会看到过时的参考。根据我的服务器从使用SPF的服务器收到的有效电子邮件的百分比来看，共识是使用SPF。

我衷心建议您设置SPF。MX的设置记录，允许它发送电子邮件，以及您在电子邮件地址中使用的域的设置记录。对于不发送电子邮件的域，设置SPF可以表明这一点。

我发现与阻止发件人电子邮件地址相比，用于阻止垃圾邮件的电子邮件服务器的SPF记录更加有用和可靠。

如果您的服务器支持SPF记录，则除了TXT记录外，还要对其进行配置。如果更改配置，则保持记录同步可能会有些开销，但是许多系统可以配置其SPF，以便它自动调整为MX和地址更改。

您可能需要查看我的有关使用SPF保护电子邮件信誉的文章。我的SPF的第一个实现是阻止正在伪造我为其提供电子邮件服务的域的垃圾邮件发送者。尽管SPF的渗透率较低，但在关闭它们方面还是非常有效的。但是，我们仍然会向他们创建的伪造地址发送垃圾邮件。（这是验证垃圾邮件发送者的一种好方法，因为只有垃圾邮件发送者才会使用该地址。）

我相信SPF在接收方的渗透可能会比在发布方更大。

编辑：如果您确实使用SPF记录，请确保传递自动邮件的人员知道添加服务器的要求。（服务器应经过全面审查，因为自动化系统通常配置不佳，并且可能具有类似于spambot的配置文件。正确设置服务器并不难。）

绝对设置SPF-应该没有不利的一面（只要正确设置和测试它即可），但它将防止其他网站伪装成您并以您的名义发送垃圾邮件。这样做的好处是，您正在明确将可以为您的域发送电子邮件的某些服务器/ IP列入白名单。

我认为最好的证明就是看几项主要的电子邮件服务。只需在原始电子邮件中查找“ Received-SPF”标头即可查看是否已选中SPF。例如：

雅虎邮箱：

Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)

Gmail：

Received-SPF: pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) smtp.mail=user@example.com

Hotmail还会检查SPF（尽管我相信他们称其为“发件人ID”）。总体而言，这是一项简单的添加，可以为您的域名和整个互联网带来很多好处。

作为其他答复者（到目前为止），我建议实施SPF。

其他一些帖子提到，这会使其他人像您一样伪装（但这并不意味着SPF是不可否认的基础）。即使此类事件的直接影响很小，它也有助于减少反向散射。

但是，另一个非常重要的原因是，它提高了其提供商实施SPF的收件人的可传递性。

我当然很想知道SPF的缺点。目前，我所知道的是：

1. 用户必须通过指定的服务器路由外发邮件-尽管控制外发邮件有明显的好处，但是如果您有远程用户，这可能会增加一些复杂性-您需要设置SMTP身份验证或VPN

2. 某些转发问题-IME非常罕见

我看到的SPF的最大问题是中断转发。截止到今天，SPF的维基百科条目中仅对此进行了简短提及。这也是我未在邮件服务器上设置SPF的原因。

考虑带有地址的A a@a.org（谁的MX实现了SPF）向具有b@b.org该地址的B发送邮件，而B则将该地址设置为将邮件转发到b@reallyb.org。然后，MX for reallyb.org看到A的邮件来自b.orgMX，因此可以丢弃该消息。

因此，如果您希望继续向使用转发的人发送邮件，因为转发在SPF出现之前的几十年中一直有效，至少不要使用-all。

如果b.org使用过的SRS的MX或将reallyb.org白名单的MX的邮件来自，则可以解决此问题b.org。但是根据我对现实的看法，尽管大多数货运代理都不做这两个。而且，如果您考虑在服务器上实现SPF，就处于A的位置，这通常是您无法控制的。