В Спецификация SPF говорит:
Опубликованная запись SPF для данного доменного имени ДОЛЖНА оставаться достаточно маленькой, чтобы результаты запроса для нее умещались в пределах 512 октетов. В противном случае существует вероятность превышения лимита протокола DNS.
…
Обратите внимание, что при вычислении размеров ответов на запросы формата TXT необходимо учитывать любые другие записи TXT, опубликованные в доменном имени.
Он также указывает на то, что более поздние спецификации DNS допускают более крупные ответы UDP (причина ограничения, поскольку спецификация SPF подразумевает, что вы не должны полагаться на работу DNS поверх TCP), но на самом деле это не отменяет «ДОЛЖНО» .
Проблема в том, что многим организациям требуются записи TXT в одном домене для целей проверки (например, facebook-domain-verification, google-site-verification, atlassian-domain-verification, adobe-sign-verificationи т. д.) и может быстро увеличить размер всего набора TXT RRset, превышающий 512 байт.
Похоже, что большинство крупных организаций соблюдают это, но есть несколько, которые переходят:
% dig +noall +stats netflix.com TXT | grep 'MSG SIZE'
;; MSG SIZE rcvd: 593
% dig +noall +stats linkedin.com TXT | grep 'MSG SIZE'
;; MSG SIZE rcvd: 632
% dig +noall +stats twitter.com TXT | grep 'MSG SIZE'
;; MSG SIZE rcvd: 642
% dig +noall +stats microsoft.com TXT | grep 'MSG SIZE'
;; MSG SIZE rcvd: 1459
(Вы можете увидеть возможное усечение, запустив что-то вроде dig +notcp +noedns +ignore microsoft.com TXT.)
Я был прямо напротив края в течение шести месяцев, и теперь мне нужно добавить еще одну проверочную запись для нового поставщика, которая подтолкнет меня к более чем 512 байтам. Я сделал все, что мог, для консолидации моей записи SPF и убедился, что не могу удалить существующие записи проверки.
Что мне здесь делать? У меня не может быть записей проверки, но я также не хочу игнорировать спецификацию SPF. Тем не менее, Microsoft, похоже, игнорирует это, и я не думаю, что их почта отклоняется.
После повторного прочтения спецификации SPF размер набора TXT RRset обеспокоен тем, что ответы DNS могут быть усечены, если клиент обе не поддерживает EDNS и клиент не поддерживает DNS через TCP. DNS через TCP всегда был необходимой частью DNS, и, похоже, предостережение связано с неработающим DNS. (Честно говоря, было много мест, где DNS поверх TCP был сломан, особенно в прошлом.)
Но я знаю, что мои DNS-серверы доступны через TCP, и меня гораздо меньше беспокоит активно взломанный DNS других людей, чем обеспечение поддержки (относительно) новой спецификации DNS.
Кажется, ответ таков: у меня «веские причины… игнорировать [этот] пункт, [и] все последствия [были] поняты и тщательно взвешены».