第八章：MX和SPF记录

第八章：MX和SPF记录MX 记录备份MTA测试MX记录SPF——发件人策略框架SPF机制SFP记录格式SPF长度高级SPF机制SPF和子域SPF DNS限制重定向查看SPF记录SPF对齐SPF和邮件列表正在验证 SPF没有电子邮件的域名Rspamd 和 SPF

域名系统（DNS）是世界上最成功的分布式数据库。电子邮件系统向其咨询有关哪些主机执行哪些角色以及支持其他安全和完整性检查的信息。正如第0章所说，您必须了解基本的DNS才能运行电子邮件。要使您的消息可交付，需要在DNS中放置大量数据。我们将从两个基本记录开始：MX和SPF。

MX记录声明哪些主机接收域的邮件。这是其他MTA查找您的MTA的方式。很有可能，你的域名的DNS入口点在你的网站上。如果有人打开浏览器并试图访问 https://solveamurder.org ，我希望将该请求转到我的网站。我在该域名的电子邮件托管在另一个主机 mail.solveamurder.org 上。我可以说我的电子邮件地址是 mwl@mail.solveamurder.org ，但大多数用户更喜欢更简单的 mwl@solveamurder.org .如果 solveamurder.org 的邮件服务器有一个完全无关的主机名，比如 mail.rebalalliance.galaxy ，该怎么办？MX记录引导世界走向正确的MTA。

SPF记录声明哪些主机可以为域发送邮件，并帮助系统评估邮件是否为垃圾邮件。Rspamd将为您验证SPF。

MX 记录

邮件交换器（ mail exchager —— MX）记录告诉世界哪个主机接收域的邮件。它始于1986年，格式非常简单：

Domain TTL IN MX Priority Host

domain 就是此记录所针对的域。

可选的 TTL 是递归服务器可以缓存此记录的时间，就像其他DNS记录一样。

可选的 IN 声明这是一条互联网记录。

MX 声明这是邮件交换器记录。

priority ——优先级，允许您建立备份MTA。今天，我们有地理负载平衡和虚拟服务器以及高可用性集群，可以让您在多个硬件和网络位置之间共享一个IP地址，但在1986年，我们没有地理负载分布或CDN，甚至没有VRRP或CARP。所有这些工具与SMTP的兼容性都很差，并且比SMTP内置的备份系统造成更多的可送达性问题。备份服务器需要不同的主机名和IP地址。优先级最低的主机是主MTA，而优先级较高的主机是不太可取的备份。

最后，域的MTA的主机名。这必须是A或AAAA记录的名称；它不能是CNAME（别名）。

这是我的一个域名的记录，没有任何常见的区域文件简写。

domain 是目标域。此纪录是 ratoperatedvehicle.com 。TTL是3600秒，即1小时。它是个Internet MX记录。priority是10，优先级为10，这是“主MTA”的常见选择。最后，我们有主机名mail.ratooperatedvehicle.com 。

当外部MTA将电子邮件发送到 ratoperatedvehicle.com 上的帐户时，它会检查MX记录。此记录指示它将该域的任何邮件发送到主机 mail.ratooperatedvehicle.com 。

MX记录不必指向其域中的主机。这是我的另一个域名：

发往域名 tiltedwindmillpress.com 的邮件会被定向到主机 mail.mwl.io 。

如果域没有MX记录，MTA将回退到检查与域名匹配的A或AAAA记录。这是一个古老的退路，不建议使用。

备份MTA

priority 设置提示每个人问：如何设置备份MTA？如今，我们有了集群和虚拟浮动IP，一切都变得模糊不清，配置一个完全不同的IP来处理电子邮件感觉很巴洛克。欢迎您使用所有这些现代高可用性技术，但备份MTA始于硬件无法恢复的时候，因此协议必须恢复。

备份MTA并不像大多数人想象的那样工作。考虑一个具有这些MX记录的域。

第一条优先级为10的记录声明 mail.ratooperatedvehicle.com 是域 ratoperatedvehcle.com 的主MTA。第二条优先级为20的记录声明 mail.solveamurder.org 是备份MTA。很简单。

该标准声明，MTA始终向优先级值最低的主机发送邮件，除非该主机无法连接或响应不正确。如果收件人MTA无法接受邮件，则发送MTA会将邮件发送到备份服务器。备份MTA将这些邮件排队，直到主MTA重新出现，然后它会将排队的邮件转储到主MTA上。

该标准并未反映人们的行为。具体情况取决于MTA软件和主MTA返回的错误。如果无法访问主MTA或在端口25上没有响应，则发送MTA会尝试备份MTA。这一切都很清楚。

但是，如果主MTA使用SMTP的任何部分进行响应，则不同的软件会有不同的行为。考虑400个错误，用于临时问题。如果您的主MTA返回400个错误，Sendmail和Postfix客户端会立即尝试备份MX。Gmail和Microsoft会将邮件排队，并在有空时重试。

邮件可能会排队好几天。较旧的系统最多允许五天。当服务器维修意味着“联系制造商，通过紧急货运将棺材大小的磁盘驱动器送到这里，并告诉停靠站的技术人员准备好叉车时，这是合理的。”今天，有一天似乎很常见。即使您的MTA硬件掉入熔岩中，并且您借此机会在一个带有不祥通风系统的花哨黑色机箱中完全重建它，大多数组织也可以在一天内安装一台新服务器。

备份MTA能给你什么？它对收到的邮件进行排队。当主MTA重新出现时，备份会将队列转发给它。仅此而已。

备份MTA可以减少发件人看到的错误消息。某些MTA配置为通知用户邮件尚未送达。这些邮件通常以“此邮件在过去四个小时内无法送达，因为收件人没有应答，但我们仍在尝试”开头。许多收到此邮件的用户会立即联系他们的支持人员，要求本地邮件管理员立即修复收件人的服务器。当备份MTA接受此邮件时，用户不会收到该通知。我更喜欢邮件系统通知人们我还没有收到他们的邮件，更不用说阅读了——尤其是如果他们通过允许五天送达的协议发送了紧急消息。

你应该有一个备份MTA吗？这是个人的决定。就我个人而言，我不介意。电子邮件可以像在我的系统中一样轻松地在发件人的系统中排队。其他系统管理员表示，他们希望始终接受邮件，甚至从不向外界暗示有问题。

备份邮件交换器的保护通常不如主邮件交换器好，因此最老练的垃圾邮件发送者完全跳过主邮件交换器，从备份发送所有内容。您必须在主MTA和备份MTA之间同步垃圾邮件保护和用户帐户信息，否则您的备份将成为直接通往用户收件箱的下水道，并从不存在的帐户生成数千封被退回的电子邮件。其他垃圾邮件发送者完全拒绝备份MX，如果主MX不可用，他们就会继续前进。垃圾邮件发送者必须在被抓到之前尽可能多地喷出污水。我怀疑，在垃圾邮件发送者出没的人渣和恶棍的悲惨巢穴中，关于哪种方法更有效的争论与我们关于如何阻止他们的争论一样激烈。

为什么不使用负载均衡器呢？SMTP不是HTTP。一两秒钟的延迟是没有意义的，特别是考虑到五天的窗口期。负载平衡器并不能提高可交付性，实际上会使某些可交付性问题变得更糟。SMTP协议规定连接到不同的IP，将多个MTA隐藏在负载均衡器后面只会混淆故障排除。

测试MX记录

一旦您为每个测试域创建了MX记录，其他MTA就可以向它们发送消息。以前，我测试过我的主机 mail.solveamuder.org 可以将帐户邮寄到 mwl@mail.ratoperatedvehicle.com 。有了 ratoperatedvehicle.com MX，我现在可以从任何邮件服务向 mwl@ratoperatedvehicle.com 发送邮件了。首先从其他测试主机发送邮件。如果这有效，您可以尝试从免费邮件提供商那里获得。这也是一个很好的测试，可以查看免费邮件提供商是否将以前未知的电子邮件地址泄露给垃圾邮件发送者。

不过，我可能无法从我的帐户回复来自外部提供商的邮件。您必须拥有SPF、DKIM和DMARC，才能在大多数大型提供商处获得可靠的交付能力。在我采取反垃圾邮件保护措施之前，我当然不应该告诉全世界我的新帐户。我们将从发件人策略框架(Sender Policy Framework —— SPF)开始。

SPF——发件人策略框架

发件人策略框架（Sender Policy Framework —— SPF）是域声明哪些主机或IP地址可以通过SMTP发送电子邮件的一种方式。它不处理使用IMAP或submission的客户端，只处理出站MTA。

SPF经常被吹捧为一种反垃圾邮件措施。不是的。它是垃圾邮件评估策略的一个组成部分。称职的垃圾邮件发送者是SPF记录最可靠的发布者之一，他们欣喜地宣称，任何主机都可以为他们的域名发送邮件。然而，来自没有SPF记录的域的电子邮件很可能被归类为垃圾邮件。

在最纯粹的形式中，SPF检查仅适用于信封中的MAIL FROM声明。验证器在MAIL FROM中检查域的SPF记录。如果消息来自允许为该域发送邮件的IP，则消息具有有效的SPF。如果地址不匹配，SPF无效。

一些组织还检查发送MTA的SPF记录。无论您的主电子邮件帐户使用什么虚拟域，您的MTA域名和完全限定域名都应该有自己的SPF记录。

似乎有一个允许发送邮件的IP地址列表是减少垃圾邮件的可靠方法，但SPF是几十年来电子邮件实践的一部分。反弹转发的消息可能违反SPF。许多邮件列表，尤其是旧邮件列表，会重新发送用户的邮件，并违反严格的SPF检查。较新的邮件列表通常会将发件人的地址重写为邮件列表地址，将原始发件人的地址放在不同的标题中，以保持SPF的完整性。SPF是DMARC的先决条件（第11章），所以我们将从它开始。

如果MTA将自己标识为域内的主机，则该主机名必须有自己的SPF记录。IP为203.0.113.66的主机 mail.solveamuder.org 可能会列在 solveamurder.org 的SPF记录中。如果 main.cf 中的 myhostname 设置为完整主机名，并且您是从命令行发送的，则消息将显示为来自以下发件人：root@mail.solveamurder.org 。如果该邮件将发送到网络外的收件人，则需要 mail.solveamurder.org 的SPF记录。来自同一主机上的虚拟域的邮件将使用配置的域名，并属于该域的SPF记录范围。

SPF机制

SPF机制(mechanism)是一种识别可以或不能发送电子邮件的主机的方法。最简单的机制是IP地址列表，标记为ip4或ip6。稍后我们将研究更复杂的机制；目前，只需知道IP地址只是识别允许发件人的一种方式。

default mechanism (默认机制)告诉接收MTA如何处理与前面列出的所有内容都不匹配的主机。这是 all 这个词，有一个限定词来说明如何处理来自前面未列出的IP的电子邮件。前导减号（ -all ）表示此列表是确定的，不符合此机制的消息应始终被拒绝。前导波浪号（ ~all ）意味着与此不匹配的电子邮件应该受到怀疑，但如果需要，可以接受。加号（ +all ）表示任何主机都可以为该域发送电子邮件，这对普通系统管理员来说是不明智的，但对垃圾邮件发送者来说是完美的。问号（ ?all ）表示不应根据SPF拒绝或批准匹配的主机。如果你在现有域上部署SPF，你可以使用 ?all ，直到你确定你已经抓住了所有的发件人。

从技术上讲，限定符可以添加到其他机制中，但这种情况很少见。SPF从左到右进行处理，第一个匹配获胜，因此您可以使用限定符从以后的机制中排除。如果你愿意，可以这样做，但要记住，复杂性会导致中断。

SFP记录格式

SPF记录是一个精心格式化的TXT记录。（您可能会看到对 SPF DNS记录类型的引用，但它早就被弃用了。不要使用它。）SPF记录必须全部小写。记录使用以下格式：

domain. TXT "v=spf1 mechanisms default-mechanism"

前导 v=spf1 表示此TXT记录的版本为SPF1。没有更新的版本，但协议修订是不可避免的。

这 mechanisms 包括识别可以直接向互联网发送邮件的所有主机的机制。向外部世界发送状态报告(status reports)、收据(receipts)或警报(alarms)的服务器应通过少数正确配置的MTA中继出站邮件。仅在SPF中列出公共地址；如果您的MTA位于NAT设备之后，请不要列出私有地址。

最后，指定默认机制。

下面是 ratoperatedvehicle.com 的SPF记录内容：

这是一个文本（TXT）记录。引号让我们以单个字符串的形式返回结果。v=spf1 声明这是一个SPF记录。此记录有两种机制，一种IPv4，一种IPv6。最后，~all 声明不在此列表中的地址不应发送邮件，但不要强行拒绝此类邮件。软禁令意味着发送到邮件列表的消息可能会通过。

大型网络可能有多个出站MTA。如果每个网络上都有多个出站MTA，并且它们的地址足够接近，则可以按网络掩码列出它们，而不是单独列出：

您有时会看到带有大网络掩码的SPF记录，如 203.0.113.0/24 或 2001:db8:bad:code::/64。通常，这些记录的存在是因为发送组织有一个完整的MTA集群。有时它们存在是因为组织有一个“他们的服务器”网络，邮件管理员想设置一次SPF并解决问题。

无效的CIDR网络语句导致SPF记录无效。说你的主机的IP地址为 203.0.113.9/24 是有效的——这是你在本地网络上的配置。声明你的主机的 network 为 203.0.113.9/24 是无效的。外部MTA不关心您的服务器的物理布局、子网或主机所在的网络大小。如果您有一个具有单个IP地址的MTA，请列出该IP地址而不加网络掩码。否则，您是说整个网络上的任何主机都可以为您的域发送邮件。Spambots喜欢这些记录。

如果您以前从未以这种方式使用过网络掩码，请记住，对于SPF来说，网络掩码是几个相邻IP地址的简写，允许在多个位置拥有多个服务器的站点遵守255个字符的限制。使用比必要更大的网络掩码意味着，如果入侵者渗透到您的非MTA系统之一并将其转化为垃圾邮件的死星，则该垃圾邮件将通过SPF检查。这正是你不想要的。

SPF长度

SPF记录不能超过255个字符。您可以创建更长的记录，但所有针对它的SPF检查都将失败。这么长的记录似乎不太可能，但如果你列出了单个IPv6地址，你可以很容易地对其进行检查。你可以用shell命令轻松检查记录的长度。

如果你的SPF记录超过255个字符，你能做什么？

首先，检查是否有多余的条目。许多小型组织认为SPF记录只写，从不验证旧条目是否仍然必要。您可以通过IPv6主机的网络而不是完整的地址来引用它们，例如 2001:db8:5c01:fcf/64 ，而不是更具体的 2001:db8:30c01:fcf:5400:1ff:fe4b:e2df 。最坏的情况是，看看谷歌或微软等大型邮件提供商，看看他们目前是如何管理SPF记录的。他们复杂的SPF设置使用了更先进的机制。

高级SPF机制

如果可能的话，您应该使用 ip6 和 ip4 机制，但大型组织可能会使用自动服务器配置，这意味着其服务的IP地址会随着需求而变化。他们可能会将部分服务外包。他们可能从收购的公司那里继承了可怕的架构。他们可能会决定保持低调(be—ick—clever)。SPF有几个合理的机制来支持他们：a 、 mx 和 include 。它也有像 ptr 和 exists 这样不太合理的机制，但它们不太合理。

a 机制告诉MTA在发件人声称的域上进行地址查找。如果DNS条目与电子邮件发件人的IP地址匹配，则检查通过。

mx 机制告诉接收MTA查找发送方域的MX记录。如果其中一条MX记录与发件人的IP地址匹配，则SPF检查通过。

假设我的域名 solveamurder.org 和许多小实体一样，对入站和出站邮件使用相同的MTA服务器。域的 A 记录点所在的web服务器也可以直接向互联网发送邮件。我可以这样定义SPF记录：

每当我重新编号我的网站或MTA时，这种更改都会传播到我的SPF记录。这似乎很酷，只是DNS需要时间来传播。过时但未过期的缓存会中断电子邮件的传递。这是常见的DNS难题，也适用于通常挑剔的迁移解决方案。

如果你的域完全或部分外包了邮件，你可以使用 include 机制来拉取不同域的SPF记录。提供者需要向您提供条目的内容。在这里，我的域名通过外部提供商发送所有内容。这些记录通常以下划线开头，将其标记为基础设施。

你可以组合机制：

您还可能会遇到使用 ptr 或 exists 机制的SPF记录。ptr 机制允许组织依赖PTR记录，这些记录很容易被控制其反向DNS的任何人欺骗。一些MTA甚至忽略了包含PTR条目的SPF记录。exists 机制允许您检查发件人的域是否存在 A 记录，这仅在非常特定的情况下有用。这两者都需要DNS查找。

SPF和子域

SPF记录不包括子域。我的域名 ratoperatedvehicle.com 有SPF记录，但如果我想开始以 mwl@test.ratoperatedvehicle.com 发送邮件，我必须为新子域创建一个新的SPF记录。您需要一个新的TXT记录，列出该子域的出站MTA：

即使子域使用与父域相同的出站MTA，该子域也需要SPF记录。

SPF DNS限制

除 ip4 和 ip6 之外的每种机制都需要单独的DNS查找。 include 语句可能需要进一步查找其记录中列出的任何内容。很容易想象，一个复杂的SPF记录需要数十次DNS查找。递归地解决所有这些问题可能需要几分钟的时间。一旦你想象到这一点，就很容易想象一个自动生成的无底SPF记录会永远占用MTA的部分资源。其中几百个，你就遭受了拒绝服务攻击。为了避免这种明显的错误，一次SPF检查将执行不超过十次DNS查找。一些旧系统拒绝进行四次以上的查找。

大多数组织都试图尽可能减少查找次数，尤其是在引用外部实体时。随着组织的发展，您将积累需要与您一起发送电子邮件的外部供应商。在签署涉及外部邮件服务的合同之前，请检查供应商的SPF配置，并验证其是否符合您的十次查找限制。

您可能会看到SPF扁平化(SPF flattening)的参考，这是一组减少SPF中DNS查找的技巧。如今，扁平化被认为是一种糟糕的做法。

重定向

也许你有一大堆共享电子邮件系统的域，你不想每次更改任何内容时都编辑区域文件。您可以使用SPF重定向告诉客户端在其他地方查找此域的SPF记录：

IN TXT "v=spf1 redirect=spf-zone"

我有很多域名。我可以决定将他们的SPF记录保存在 _spf.solveamuder.org 的TXT记录中。使用该配置的域将使用此重定向：

当我重新寻址MTA时，编辑单个区域文件会影响我的所有域。

查看SPF记录

仅使用 ip4 和 ip6 机制为测试域设置SPF记录。不要使用花哨的包含或重定向。一旦它们存在，请验证您是否可以通过 dig 调用它们：

如果响应看起来正确，请使用外部实体进行测试。许多人已经在网络上安装了SPF检查器。我喜欢 mxtoolbox.com ，但搜索引擎会给你更多。您需要一个SPF检查程序来测试有效性并告诉记录需要多少DNS查找。你最喜欢的搜索引擎可以提供许多候选人。

SPF对齐

从技术上讲，SPF对齐(alignment)是一个DMARC概念，但我们会在SPF在你大脑中新鲜时深入研究它。对齐考虑了消息中的其他标头与SPF验证的 MAIL FROM 的比较。如果 MAIL FROM 中的内容与 FROM 标头中的内容相同，则称该消息处于SPF对齐状态(SPF alignment)。记住， MAIL FROM 地址通常记录在 Return-Path 标头中。对齐对DMARC至关重要，因此最好从一开始就实现对齐。

对齐可以是严格的，也可以是宽松的。严格对齐意味着 MAIL FROM （或 Return-Path ）中的域与用户可见的 FROM 标头中的域完全匹配。考虑这些标题片段：

Return-Path 中的电子邮件地址与 From 中可见的用户不匹配。然而，域名确实匹配。如果此消息通过了SPF验证，则表示它处于严格的SPF对齐状态(strict SPF alignment)。如果它不通过，就没有对齐。

宽松(Relaxed)对齐意味着 MAIL FROM 中的域来自 FROM 标头中域的子级。看看这些标题片段：

如果你看过网站消息的标题，你可能会看到这样的东西。发送邮件的主机在域中，但它不是主MTA。它看起来像是来自销售部门。不过， www.tiltedwindmilpress.com 属于 tiltedwingmilpress.com 。如果此消息通过SPF，则表示它处于宽松的SPF对齐状态。我经常在来自自动化流程或命令行的邮件中看到轻松的对齐。我可以在此主机上设置MTA以将其标识为主域，但这可能会导致其他问题。

使用批量邮件服务，您可能会看到这样的标题。

也许这条消息传递给了SPF。但是， Return-Path 和 From 中的域之间没有关系，因此此消息未对齐。

SPF和邮件列表

邮件被重新发送。您在工作地址收到一条个人信息，并希望在人力资源部介入之前将其发送到您的个人帐户。你拿到一场演出的演唱会门票，并将其转发到你手机上的一个帐户。当然，欧文叔叔会把他得到的每一个愚蠢的阴谋论和蹩脚的笑话都转发给你。

邮件列表接收邮件，添加几个标题，再更改几个标题，然后继续发送。原始邮件列表通常会重新发送 Return-Path 的邮件。这破坏了SPF验证。这当然打破了SPF的一致性。一些邮件列表已经更新了他们的软件来应对SPF。以下是“mailop”邮件列表中的一些标题。

此邮件列表接受来自订阅者的邮件，但将 Return-Path 设置为列表地址。From 标头保留原始发件人的姓名，但用列表地址替换电子邮件地址。它添加了 Reply-To 标头，告诉人们原始发件人的地址。此消息使用 mailop.org 的SPF记录。可见的 From 标头用户与Return-Path 位于同一域中，因此它具有严格的SPF对齐。

将此与我发送给FreeBSD开发人员邮件列表的消息标题进行比较。

Return-Path 使用邮件列表地址，因此初始SPF测试将通过。但是，From 地址是我的，因此没有SPF对齐。

我不知道有任何邮件列表仍然以不变的返回路径转发邮件，但如果知道它们仍然存在，我不会感到惊讶。部署DMARC会告诉您是否使用了任何DMARC。

正在验证 SPF

当您的MTA收到来自外部发件人的邮件时，它应该尝试验证发送域的SPF记录。这到底是什么意思？

SMTP交换最多在三个位置标识其来源。EHLO 命令给出了源MTA标识自己的名称。有一个 MAIL FROM ，可以识别发件人。有 From ，用户可见的名称。SPF可以验证EHLO和MAIL FROM地址，尽管并非所有组织都执行这两项检查。

SPF验证将测试的地址与域SPF记录中的策略进行比较。SPF记录表示一个策略，因此结果可能比简单的是或否更复杂。验证尝试可能会导致通过，这意味着消息的SPF肯定是有效的，或者它可能会给出几个无效结果之一。您可以调整系统对SPF故障的反应方式。

中立( neutral )的结果意味着您的验证器检索到了域的SPF记录，但该记录明确声明它不会声明源地址是否被授权。此域的SPF记录为此特定源地址分配了一个问号。

无( none )结果意味着您的DNS服务器无法检索此域的SPF记录。也许域没有SPF记录，或者DNS解析失败。

softfail 结果意味着此消息可能未通过。SPF记录可能以 ~all 结尾。软失败的消息应被视为可疑。

fail 或 hardfail 意味着此消息的SPF无效。该电子邮件来自政策明确禁止发送该电子邮件的IP地址。SPF记录可能以 -all 结束。

您的日志还可能显示临时SPF错误 temperror 。它们通常与DNS有关。当您的验证器收到临时错误时，它应该指示您的MTA向发件人返回400错误，告诉它稍后重试。

如果发送者真的搞砸了，你会看到 permerror ，一个永久性的错误。SPF记录本身无效。也许发送域有多个SPF记录，或者需要十多次DNS查找才能解析。也许有人在退出 vi(1) 时搞砸了，记录有 :wq! 。人类失败的多样性是巨大的和无限的，软件无法应对。

您可以根据您的策略配置SPF验证器以接受或拒绝每个结果。

没有电子邮件的域名

有些域不接受传入邮件，也不应该发送邮件。垃圾邮件发送者使用任何看起来方便的域名伪造电子邮件。通过提供“此域从不发送邮件”的SPF记录，您可以通知其他MTA，来自这些域的任何邮件都是伪造的，应该被拒绝。

这是一个SPF记录，上面写着“拒绝来自此域的所有邮件”：

注意 all 前面的减号，而不是波浪号。这是一次艰难的失败。提供这些记录既可以帮助其他人拒绝垃圾邮件，也可以减少向您投诉“来自”您域名的垃圾邮件的人数。本书稍后，我们还将介绍DKIM和DMARC的免邮件域名。

要告诉全世界一个域不接受邮件，请使用一个空的MX记录。将MX记录的优先级设置为零，并列出一个点作为主机名：

您也可以在不存在时使用零优先级，如第15章所述。

Rspamd 和 SPF

许多人编写了SPF验证器，但rspamd包含一个，并且默认启用。在标头中记录SPF验证没有标准，因此rspamd将其作为 X-Spamd-Result 中的符号列出。每个结果都有自己的符号和权重值。

R_SPF_ALLOW 符号表示消息来自SPF记录中列出的IP，权重为 -2 。 R_SPF_FAIL 表示消息未通过SPF检查，权重为 1 。其他类型的故障权重均为 0。我们将在第14章中看到如何更改这些内容。

其他验证器通常将SPF结果放在 Authentication-Results 标头中。如果您需要排除可能的SPF问题，请仔细查找标题，直到找到SPF。

有了MX和SPF记录，你就可以开始告诉外界你的域名了。一旦你这样做，垃圾邮件发送者就会蜂拥而至。让我们运行基本的反垃圾邮件保护。