Запись 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
в одном из первых блоков и завершить проверку.