Bar*_*row 6 email authentication dns spf
我想到,如果SPF记录不是递归的,那么域名可能容易受到来自子域的电子邮件欺骗的攻击.我的研究揭示了这个:
恶魔问题:子域名怎么样?
如果我收到来自pielovers.demon.co.uk的邮件,并且没有针对馅饼的SPF数据,我应该回到一个级别并测试SPF for demon.co.uk吗?不可以.Demon的每个子域都是不同的客户,每个客户可能都有自己的策略.恶魔的政策默认适用于所有客户是没有意义的; 如果Demon想要这样做,它可以为每个子域设置SPF记录.
因此,向SPF发布者提供的建议是:您应为每个具有A或MX记录的子域或主机名添加SPF记录.
具有通配符A或MX记录的站点还应具有通配符SPF记录,格式为:*IN TXT"v = spf1 -all"
(感谢Stuart Cheshire.)
(强调我的)
问题1:如果子域没有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"
Run Code Online (Sandbox Code Playgroud)
support.google.com. 21599 IN CNAME www3.l.google.com.
Run Code Online (Sandbox Code Playgroud)
www3.l.google.com. IN TXT
Run Code Online (Sandbox Code Playgroud)
所以...,没有SPF记录support.google.com.
Q2:Wy不会谷歌(以及许多其他网站)遵循这个建议吗?
Q3(奖金):如果这是一个问题,我不仅仅是愚蠢,为什么这不是更多的记录?
我能找到的唯一相关的SE问题就是这个问题,但它并没有比openspf.org上面的常见问题解答多得多.
这在2015年实际上并不是非常相关的建议,因为自该帖子发布以来,电子邮件领域已经发生了很大变化.
实际上,SPF是一种身份验证协议,而不是一种策略实施机制.我的意思是,特定消息可以根据EHLO名称或返回路径域传递,失败或不检查SPF.但是接收器应如何处理任何SPF结果取决于接收器.
电子邮件策略实施机制是DMARC,它指定接收方应如何处理未通过SPF或DKIM身份验证的消息.应该完全拒绝吗?隔离(通常意味着针对垃圾邮件文件夹)?还是被视为"正常"?
与SPF不同,DMARC确实具有子域继承.因此,如果未在子域上定义明确的DMARC策略,则使用在组织域上定义的策略.因此,在您提及的具体案例中,将从中读取该政策_dmarc.google.com.这是:
v=DMARC1; p=quarantine; rua=mailto:mailauth-reports@google.com
Run Code Online (Sandbox Code Playgroud)
因此support.google.com,即使未定义明确的SPF策略,您发送的假设电子邮件也将被视为垃圾邮件support.google.com
因此,如果您希望确保针对您管理的域的子域欺骗,请添加DMARC策略.