Итак, у меня создалось впечатление, что отдельные записи 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 -all". Примечательно, что это допускает произвольно большие записи 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.