☰

SPF 记录——为什么我们在使用 `+mx` 的同时还要使用 `+a`？

tag-icon • tag-icon spf
SPF 记录——为什么我们在使用 `+mx` 的同时还要使用 `+a`？

为什么管理员在 SPF 记录中大多使用+aalong +mx？这是示例：

@              10800 IN TXT     "v=spf1 +a +mx -all"

仅使用参数还不够吗？+mx例如：

@              10800 IN TXT     "v=spf1 +mx -all"

我以为 MX 记录的任务是发送电子邮件，而不是 A 记录。有人能解释一下为什么有人会使用 MX 记录吗+a？

答案1

坦白说，这是因为他们从一些教程或示例配置中复制了配置，而不知道 SPF 的基本原理。有时需要例如 Web 服务器a和传入邮件往来 mx也用于发送邮件，但并非总是如此。

最好采用较少额外 DNS 查询的机制：ip4/ip6一遍a又a一遍mx(RFC 7208, 10.1.1) 即使为了便于管理（10.1.2)，a选择机制，并不总是a mx或a，而是例如a:relay.example.com。

答案2

记录中列出的主持人的任务MX是收到电子邮件，不一定是递送电子邮件。
采用不对称设置是完全有效的（而且很常见，特别是对于较大的操作而言），其中处理入站和出站电子邮件的主机是不一样的。

也就是说，无法保证SPF 中的mx(aka +mx) 或a(aka +a) 与指定哪些主机需要递送电子邮件。
例如，如果您没有运行自己的邮件服务器，那么类似这样的内容可能v=spf1 include:spf.majoremailserviceprovider.example -all更有意义。

为了直接回答为什么这种a mx组合在 SPF 记录中出现得过多的问题，我猜测这种情况归结为太多管理员在添加 SPF 记录时，对 SPF 概念的理解不够充分，无法判断应该将什么内容放入他们的策略中，而是只是复制粘贴一些任意构造的示例。

答案3

我同意其他答案，这+a +mx可能是一种货物崇拜的反习语。

关于何时使用+a，RFC 文档在10.1.2节：

发布单个主机的 SPF 记录也是最佳实践。主机名通常是 5321.HELO/.EHLO 命令中使用的标识。对于带有空 5321.MailFrom 的邮件，除了用于基于 5321.HELO/.EHLO 的 SPF 检查外，它还用作 5321.MailFrom SPF 检查的域。参与邮件处理的单个主机的标准 SPF 记录是：

relay.example.com.   IN TXT  "v=spf1 a -all"

例如，我为我的邮件服务器发布了这样的记录mail.mydomain.org，以方便首先验证 HELO 身份的验证者。（当然，我也在v=spf1 mx -all邮件域mydomain.org本身发布了习惯记录。）

答案4

长度可能是一个优势——尽管这不太可能是真正的动机。

考虑到 TXT 记录的大小可能会过大，以至于单个 UDP 数据包太小。因此，请求将再次以 TCP 发送，而回复是多个 TCP 数据包和相关的握手建立时间。

通过谨慎使用 A 和 MX 请求，可以获得两个约 1500 字节的 SPF 记录 UDP 回复，一个用于 A，一个用于 MX，以及所有 TXT 记录的剩余约 1400 字节。

这假设您的 SPF 记录中有足够的授权“内容”超过 3000 字节。Include 也可以绕过长度限制，但我不清楚它们是否都是单独的 UDP 请求或单个 TCP 请求会话。

相关内容