这SPF 条目对于 gmail.com 来说，重定向到 _spf.google.com：
$ dig gmail.com txt @8.8.8.8 +short
"v=spf1 redirect=_spf.google.com"
_spf.google.com 重定向至其他 3 个条目
$ dig _spf.google.com txt @8.8.8.8 +short
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
_netblocks.google.com 包含 ipv4 列表：
$ dig _netblocks.google.com txt @8.8.8.8 +short
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.208.0/20 ip4:216.239.32.0/19 ~all"
_netblocks2.google.com 包含 ipv6 列表：
$ dig _netblocks2.google.com txt @8.8.8.8 +short
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
_netblocks3.google.com 是一条空记录：
$ dig _netblocks3.google.com txt @8.8.8.8 +short
"v=spf1 ~all"
为什么是空块，它有什么用途还是只是配置错误？
答案1
首先要说的是：
_spf.google.com 重定向至其他 3 个条目
这包括机制是不是和重定向。评估后include:，处理返回到包含记录，而redirect:导致整个过程忽略原始记录中重定向后的所有内容。
正如 Frederik 已经指出的那样，_netblocks3可能会保留以备将来使用。
在处理来自合法发件人的邮件的 SPF 验证时，它具有不效果，因为 SPF 是按顺序处理的。发送 MTA 可能已经匹配了第一个块中的一个ip4或条目，并退出验证。ip6