Defaults.Exposed › Исправления › Guides

SPF PermError: как исправить "Too Many DNS Lookups", не сломав почту (2026)

Опубликовано 2026-07-08

Цифры по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы ставим оценки.

Как минимум 797 263 доменов превышают лимит SPF в 10 DNS-запросов, по данным переписи Defaults.Exposed, охватившей 261 086 232 доменов, — из 139 млн публикующих SPF. После десяти запросов получатель останавливается и возвращает PermError: ваш SPF недействителен, а DMARC засчитывает PermError как провал.

У исправления строгий порядок, и большинство руководств излагают его задом наперёд. Посчитайте свои реальные, разрешённые запросы; удалите мёртвые и неиспользуемые include — уже одно это исправляет большинство записей; перенесите массовые рассылки на поддомены с собственным бюджетом SPF; сглаживайте только в крайнем случае и только с автоматическим повторным сглаживанием, потому что статическое сглаживание гниёт и тихо ломает доставку.

Что означает “SPF PermError: too many DNS lookups”?

RFC 7208 §4.6.4 ограничивает каждую проверку SPF 10 DNS-запросами. После десяти получатель останавливается и возвращает PermError — сломанной считается вся запись целиком, а не только часть сверх бюджета. Тот же раздел добавляет менее известный второй потолок: не более 2 «пустых запросов» (запросов, возвращающих отсутствие ответа или NXDOMAIN), так что пара мёртвых записей include: для отменённых сервисов может обнулить ваш SPF сама по себе.

Последствия хуже, чем «нет SPF»: DMARC трактует PermError как провал SPF, поэтому домен, сломавший собственный SPF, остаётся неаутентифицированным по SPF-ветке в каждой проверке DMARC. Если DKIM не настроен или ломается в пути, такая почта теперь проваливает DMARC полностью.

Одна цифра переписи показывает, насколько жесток этот режим отказа: 112 215 доменов публикуют строгую запись -all, которая недействительна из-за переполнения запросов, — из 54 655 923 доменов, публикующих -all вообще. Их владельцы сделали трудную часть — выбрали строгое окончание, — и один лишний include выключил всю запись. Они выглядят строгими; они сломаны. Полная картина данных — в отчёте об SPF PermError.

Почему мой SPF сломался, хотя я ничего не менял?

Потому что бюджет по большей части расходуют чужие записи. Каждый include: разрешается рекурсивно, и каждый механизм с запросом внутри него засчитывается в вашу десятку. Одна строка в вашей DNS-панели может стоить четыре-пять запросов после разрешения. Провайдер вкладывает ещё один include — и ваш SPF умирает без единого изменения в вашей зоне.

Крупные платформы не проблема: Google и Microsoft сами сгладили свои SPF — _spf.google.com и spf.protection.outlook.com раскрываются в простые списки IP, стоящие ноль внутренних запросов (проверено по живому DNS, июль 2026). Реальные переполнения приходят из многослойных цепочек include хостинг-панелей и из честного нагромождения SaaS — почтовый ящик плюс рассылка плюс CRM плюс хелпдеск, каждый «всего один include». Никто не добавляет одиннадцатый запрос намеренно; он приходит как сумма разумных решений. Именно поэтому у обрыва так тесно: 2 119 539 доменов находятся ровно на 9–10 разрешаемых запросах — примерно 1 из 66 всех публикующих SPF, — сегодня всё в порядке, а в день, когда кто-то вставит ещё один include, запись станет недействительной. SPF-запись 99-го перцентиля уже разрешается в 9 запросов. Если ваш стек насыщен SaaS, руководство «SPF не проходит для SaaS-инструментов» разбирает всё по каждому поставщику.

Какие части SPF-записи считаются DNS-запросами?

Считайте разрешённый итог, а не видимые строки. Четыре include могут оказаться и четырьмя запросами, и четырнадцатью.

Как исправить “too many DNS lookups”, не сломав почту?

1. Запустите бесплатную проверку, прежде чем трогать DNS. Она разрешает всю вашу цепочку include и показывает реальное число запросов, так что вы исправляете действительную проблему — а не запись в том виде, как она выглядит в панели. (Если проверка говорит, что SPF у вас вообще нет, это другой сбой — см. «SPF record not found».)
2. Сначала удалите мёртвые и неиспользуемые include. Инструмент, от которого вы отказались в 2023-м, include старого хостера, переживший миграцию, дубликаты, любой механизм ptr. Мёртвые include токсичны вдвойне: они сжигают бюджет запросов и являются обычным источником пустых запросов. Большинство записей с превышением бюджета возвращаются под 10 уже на этом шаге. Если в вашей записи всё ещё есть механизмы прежнего провайдера, следуйте руководству по уборке после миграции.
3. Проверьте, что каждый оставшийся include что-то делает. Получатели проверяют SPF по домену Return-Path (RFC5321.MailFrom), а не по заголовку From — а многие SaaS-инструменты ставят в Return-Path свой собственный bounce-домен, так что их include в вашей записи не делает ничего, кроме расходования бюджета. Оставляйте include только для сервисов, использующих ваш домен как Return-Path; для остальных вместо этого включите DKIM поставщика для собственного домена.
4. Перенесите массовые рассылки на поддомены. Рассылки — с news.yourdomain.com, транзакционные письма — с mail.yourdomain.com. Каждый поддомен получает собственную SPF-запись со свежим бюджетом в 10 запросов, и проблема в одном потоке перестаёт перетекать в остальные.
5. Только после этого рассматривайте сглаживание — и только автоматизированное. См. ниже.
6. Пересканируйте, чтобы подтвердить, что вы с запасом ниже 10 — стремитесь к запасу, а не ровно к 10, иначе вы только что вернулись к 2,1 млн доменов у края обрыва. Затем разберите всё остальное, что отметит проверка, на странице исправить SPF.

Стоит ли сглаживать SPF-запись?

Сглаживание заменяет include лежащими под ними блоками ip4:/ip6:, которые стоят ноль запросов. Оно работает — а сделанное вручную, это отложенная авария доставки.

Провайдеры регулярно меняют отправляющие IP и никому об этом не объявляют. Статический список IP верен в день, когда вы его вставили, и незаметно неверен через несколько месяцев — а поскольку сбой проявляется в том, что другие люди не получают вашу почту, вы узнаёте об этом поздно. Если прореживание и поддомены вывели вас под лимит, на этом остановитесь; никогда не копируйте вручную IP-блоки третьей стороны в свою запись как постоянное решение.

Часто задаваемые вопросы

Означает ли SPF PermError, что моя почта перестаёт доставляться? Не мгновенно — именно этим он и опасен. DMARC засчитывает PermError как провал SPF, так что доставка целиком опирается на DKIM; если DKIM отсутствует или ломается в пути, вы проваливаете DMARC. Из 139 млн публикующих SPF в нашей переписи (по состоянию на 2026-06-29) как минимум 797 263 находятся в этом состоянии — большинство не подозревая об этом.

В моей записи всего четыре include — как она может превышать 10 запросов? Include считаются рекурсивно: всё внутри каждого include (и внутри его include) списывается с вашего бюджета, так что четыре видимые строки могут разрешаться в четырнадцать запросов. Считайте разрешающим инструментом, а не на глаз — именно разрешение цепочек позволило нашему отчёту о PermError найти примерно в 100 раз больше сломанных доменов, чем показывают поверхностные подсчёты.

Моя запись заканчивается на -all — я же наверняка защищён? Только если запись вычисляется. Наша перепись (по состоянию на 2026-06-29) нашла 112 215 доменов, чьи строгие записи -all недействительны из-за переполнения запросов. Строгий квалификатор на записи с PermError не защищает ничего.

Лимит в 10 запросов — на каждый include или на всю запись? На всю проверку: RFC 7208 §4.6.4 ограничивает полную проверку десятью запросами плюс не более 2 пустых. У каждого поддомена своя запись и свой бюджет — поэтому шаг 4 и работает.

Считаются ли записи ip4 и ip6 в лимит? Нет — IP-механизмы ничего не стоят, и именно поэтому сглаживание снижает счёт.

Отправьте владельцу отчёт

Если вы исправляете это для клиента или работодателя, завершите работу свидетельством. Перезапустите бесплатную проверку после изменений и перешлите отчёт с оценкой владельцу бизнеса: простой язык, дата, PermError исчез. Это тот документ, который понадобится ему для продления киберстраховки и следующей клиентской анкеты по безопасности, — разница между «я поменял какие-то DNS-записи» и задокументированным «до и после».

Проверьте свой домен бесплатно

Посмотрите своё реальное, разрешённое число запросов — и всё остальное по SPF, DKIM и DMARC — приватно и только для владельца.

Проверить свой домен → · Исправить SPF → · SPF не проходит для SaaS-инструментов → · Настроить SPF на GoDaddy → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.