没有通配符 SPF 记录的站点是否容易受到子域欺骗攻击？
Are sites without wildcard SPF records vulnerable to subdomain spoofing attacks?
我突然想到，如果 SPF 记录不是递归的，域名可能容易受到来自子域的电子邮件欺骗的攻击。我的研究显示 this:
The Demon Question: What about subdomains?
If I get mail from pielovers.demon.co.uk, and there's no SPF data for
pielovers, should I go back one level and test SPF for demon.co.uk?
No. Each subdomain at Demon is a different customer, and each customer
might have their own policy. It wouldn't make sense for Demon's policy
to apply to all its customers by default; if Demon wants to do that,
it can set up SPF records for each subdomain.
So the advice to SPF publishers is this: you should add an SPF record
for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF
record, of the form: * IN TXT "v=spf1 -all"
(Thanks to Stuart Cheshire.)
（强调我的）
Q1：如果子域没有A/MX记录，为什么不需要添加SPF记录？
举个例子，我调查了support.google.com:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
support.google.com. 21599 IN CNAME www3.l.google.com.
www3.l.google.com. IN TXT
所以...，没有 support.google.com.
的 SPF 记录
问题 2：Google（以及许多其他网站）为什么不遵循这个建议？
Q3（奖金）：如果这是一个问题，而且我不只是愚蠢，为什么没有更多的记录？
我能找到的唯一相关的 SE 问题是 this，但它并没有比上面的 openspf.org 常见问题解答更多。
这在 2015 年实际上并不是非常相关的建议，因为自 post 提出以来电子邮件格局已经发生了重大变化。
实际上 SPF 是一种身份验证协议，而不是一种策略执行机制。我的意思是，特定消息可以根据 EHLO 名称或 Return 路径域通过、失败或不检查 SPF。但是接收方应如何处理任何 SPF 结果取决于接收方。
电子邮件策略执行机制是 DMARC，它指定收件人应如何处理未通过 SPF 或 DKIM 身份验证的邮件。是否应该完全拒绝？隔离（通常意味着指向垃圾邮件文件夹）？或者视为'normal'?
DMARC 与 SPF 不同，它具有子域继承。因此，如果未在子域上定义显式 DMARC 策略，则会使用在组织域上定义的策略。因此，在您提到的特定情况下，政策将从 _dmarc.google.com 读取。即：
v=DMARC1; p=quarantine; rua=mailto:mailauth-reports@google.com
因此，即使没有在 support.google.com
上定义明确的 SPF 策略，您在 support.google.com 上发送的假设电子邮件也会被视为垃圾邮件
因此，如果您想确保您管理的域免受子域欺骗，请添加 DMARC 策略。
我突然想到，如果 SPF 记录不是递归的，域名可能容易受到来自子域的电子邮件欺骗的攻击。我的研究显示 this:
The Demon Question: What about subdomains?
If I get mail from pielovers.demon.co.uk, and there's no SPF data for pielovers, should I go back one level and test SPF for demon.co.uk? No. Each subdomain at Demon is a different customer, and each customer might have their own policy. It wouldn't make sense for Demon's policy to apply to all its customers by default; if Demon wants to do that, it can set up SPF records for each subdomain.
So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF record, of the form: * IN TXT "v=spf1 -all"
(Thanks to Stuart Cheshire.)
（强调我的）
Q1：如果子域没有A/MX记录，为什么不需要添加SPF记录？
举个例子，我调查了support.google.com:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
support.google.com. 21599 IN CNAME www3.l.google.com.
www3.l.google.com. IN TXT
所以...，没有 support.google.com.
问题 2：Google（以及许多其他网站）为什么不遵循这个建议？
Q3（奖金）：如果这是一个问题，而且我不只是愚蠢，为什么没有更多的记录？
我能找到的唯一相关的 SE 问题是 this，但它并没有比上面的 openspf.org 常见问题解答更多。
这在 2015 年实际上并不是非常相关的建议，因为自 post 提出以来电子邮件格局已经发生了重大变化。
实际上 SPF 是一种身份验证协议，而不是一种策略执行机制。我的意思是，特定消息可以根据 EHLO 名称或 Return 路径域通过、失败或不检查 SPF。但是接收方应如何处理任何 SPF 结果取决于接收方。
电子邮件策略执行机制是 DMARC，它指定收件人应如何处理未通过 SPF 或 DKIM 身份验证的邮件。是否应该完全拒绝？隔离（通常意味着指向垃圾邮件文件夹）？或者视为'normal'?
DMARC 与 SPF 不同，它具有子域继承。因此，如果未在子域上定义显式 DMARC 策略，则会使用在组织域上定义的策略。因此，在您提到的特定情况下，政策将从 _dmarc.google.com 读取。即：
v=DMARC1; p=quarantine; rua=mailto:mailauth-reports@google.com
因此，即使没有在 support.google.com
support.google.com 上发送的假设电子邮件也会被视为垃圾邮件
因此，如果您想确保您管理的域免受子域欺骗，请添加 DMARC 策略。