Итак, у меня сложилось впечатление, что отдельные записи SPF должны умещаться в 255 символов или использовать оператор include
, чтобы связать вместе несколько записей, образующих цепочку. Однако RFC 4408 3.1.3. в частности, говорится, что несколько строк должны быть объединены перед вычислением - поэтому, IN TXT "v = spf1" "1.2.3.4 -all"
должен обрабатываться так же, как IN TXT "v = spf1 1.2. 3.4 -все »
. Примечательно, что это разрешает произвольно большие записи SPF, и include
становится инструментом для включения записи SPF, которую администрирует кто-то другой.
Это правильная интерпретация спецификации? Что еще более важно, будут ли текущие почтовые серверы уважать этот многострочный тип записи TXT?
Да, вы интерпретируете это правильно. Я недавно столкнулся с этим.
Эта статья была мне полезна:
Могу ли я иметь запись TXT или SPF длиной более 255 символов?
Ярким примером этой концепции на практике является запись SPF для cisco.com от 25.02.2016:
> ;; QUESTION SECTION: ;cisco.com. IN TXT
>
> ;; ANSWER SECTION: cisco.com. 12775 IN TXT
> "926723159-3188410" cisco.com. 12775 IN TXT
> "v=spf1 ip4:173.37.147.224/27 ip4:173.37.142.64/26
> ip4:173.38.212.128/27 ip4:173.38.203.0/24 ip4:64.100.0.0/14
> ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:144.254.0.0/16
> ip4:66.187.208.0/20 ip4:173.37.86.0/24" " ip4:64.104.206.0/24
> ip4:64.104.15.96/27 ip4:64.102.19.192/26 ip4:144.254.15.96/27
> ip4:173.36.137.128/26 ip4:173.36.130.0/24 mx:res.cisco.com
> mx:sco.cisco.com ~all" cisco.com. 12775 IN TXT
> "MS=ms65960035"
Просто убедитесь, что вы учли пробелы в записях, как вы уже указали.
Также имейте в виду, что вам нужно ограничить количество запросов DNS до 10 в ваших записях согласно SPF RFC :
реализации SPF ДОЛЖНЫ ограничивать количество механизмов и модификаторов. которые выполняют поиск в DNS до 10 запросов на проверку SPF, включая любые запросы вызвано использованием механизма "включения" или "перенаправления" модификатор. Если это число превышено во время проверки, ДОЛЖНА быть ошибка PermError. быть возвращенным.