我在 SPF 标准中看不到任何暗示 SPF 记录也涵盖所有子域的内容。鉴于子域有时由不同方管理（尤其是在像大学这样的大型组织中），隐含地覆盖子域也没有多大意义。标准在第 4.4 节中说：

4.4. 记录查找
根据记录的发布方式（参见上面的第 3 节），需要对 <domain> name 进行 DNS 查询，仅查询 TXT 类型。

“<domain> name”在这里是来自电子邮件的域，而不是上层域。

SPF 不会“汇总”到组织域（这是 DMARC 对您注册的事物的术语，紧接在 TLD/ public 后缀下）。当 SPF 提到“域”时，它表示完全限定的域名（FQDN，“主机”）。

您可以使用通配符 DNS 记录进行汇总，因此如果您example.com使用BIND进行控制：

*         IN  TXT     v=spf1 a 192.0.2.0/24 -all
@         IN  TXT     v=spf1 a mx 192.0.2.0/24 ~all

我选择让@（顶级）允许邮件交换，并且更宽容丢失可能的中继（他们会 SOFTFAIL），而任何其他主机将触发通配符并自己发送邮件（A记录，这也影响 IPv6 AAAA)，加上允许的网络 CIDR，对未通过的项目有更最终的 FAIL。如果没有 DMARC，这不是权威的，如果需要，也可以使用通配符进行设置。

正如 Adam 所提到的，当涉及到子域时，SPF 策略发现的工作方式与 DMARC 不同：如果在子域上没有找到 SPF 记录，则不会尝试使用组织域上的 SPF 记录；SPF 将返回none作为检查结果。

子域通常代表组织内的一个单独部门，例如，sales.company.com 代表销售部门，it.company.com 代表 IT 部门，support.company.com 代表客户支持等。

由于不同的部门有不同的功能，所以他们用于发送电子邮件的服务也不同。例如，销售可能使用 Outreach，支持可能使用 Zendesk 等。

因此，与 DMARC 不同，如果在子域上找不到 SPF 记录，则回退到使用根域的 SPF 记录可能不是一个好主意，因为子域应该使用非常不同的服务。

为了纠正这个问题，应该在每个发送出站电子邮件的子域上发布一个 SPF 记录。

在此处了解更多信息：https ://dmarcly.com/blog/how-spf-works-with-subdomains