В Запись 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"
Почему пустой блок, служит ли он какой-то цели или просто неправильно настроен?
Перво-наперво:
_spf.google.com - это перенаправление на 3 другие записи
В включают механизм не так же, как перенаправить. После оценки include:, обработка возвращается к включающей записи, тогда как redirect: заставляет весь процесс игнорировать все после перенаправления в исходной записи.
Как уже отмечал Фредерик, _netblocks3 может быть зарезервирован для использования в будущем.
При обработке проверки SPF для сообщений от законных отправителей он имеет нет эффект, поскольку SPF обрабатывается последовательно. Отправляющий MTA уже соответствовал бы ip4 или ip6 вход в один из первых блоков и выход из валидации.