![SPF 记录——为什么我们在使用 `+mx` 的同时还要使用 `+a`?](https://linux22.com/image/761588/SPF%20%E8%AE%B0%E5%BD%95%E2%80%94%E2%80%94%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E4%BB%AC%E5%9C%A8%E4%BD%BF%E7%94%A8%20%60%2Bmx%60%20%E7%9A%84%E5%90%8C%E6%97%B6%E8%BF%98%E8%A6%81%E4%BD%BF%E7%94%A8%20%60%2Ba%60%EF%BC%9F.png)
为什么管理员在 SPF 记录中大多使用+a
along +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 请求会话。