有趣的情况，我不确定这是我的错还是谷歌的错。
我有一个域名，示例.com，它有 2 个子域名：main.example.com， 和spf.example.com。 为了main.example.com域，我的 TXT 记录曾经定义为：v=spf1 重定向=example.com包含相关 TXT示例.com已定义。
出于各种原因，我决定创建“主要”TXT SPFspf.example.com，并重定向到那里。请注意，SOA 和 NS 仅适用于示例.com。 我变了main.example.comTXT阅读v=spf1 重定向=spf.example.com并且 Google（根据 DMARC 报告）不再看到 SPF 记录。Yahoo 和 Microsoft 可以。
因此我进行了第二次测试：备份.example.com，发了几封电子邮件没有TXT SPF 已定义，雅虎、微软和谷歌的 DMARC 报告均表明不存在 TXT SPF。TXT 定义为v=spf1 重定向=spf.example.com很快，微软和雅虎就注意到了这一点，而谷歌却还没有。
除了“Google 邮件软件很烂”之外还有其他解释吗？
答案1
据我了解，重定向记录中的值如下所示：
v=spf1 redirect=spf.example.com -
我立即注意到两个问题：
- 有一个
-没有任何机制的限定符（），即该记录在语法上似乎不正确。 redirect已被使用，但它不是记录中的最后一条条目。
这两个都是有问题的，因为规范试图确保在采取行动之前应该真正理解记录：
来自SPF 规范的记录评估部分（强调添加）：
check_host() 函数解析并解释 SPF 记录以找到当前测试的结果。 首先验证记录的语法，如果记录中的任何位置存在任何语法错误，check_host() 将立即返回结果“permerror”，而无需进一步解释或评估。
来自SPF 规范的重定向部分（强调添加）：
为了清楚起见，任何“重定向”修饰符都应作为记录中的最后一个词出现. 如果记录中的任何地方存在“全部”机制，则必须忽略任何“重定向”修饰符。