Отчёт об SPF PermError: в 100× больше доменов превышают лимит в 10 запросов, чем показывает подсчёт по видимым записям (2026)

Q: Как мне сократить число запросов SPF?

Удалите неиспользуемые include и ptr, уплощите собственную инфраструктуру до ip4:/ip6:, перенесите массовых отправителей на поддомены и пересчитывайте после каждого нового инструмента. Руководство по исправлению проведёт вас через это.

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

Данные по состоянию на 2026-06-29 · методология v7, плюс проход по оценке стоимости цепочек, выполненный 2026-07-03. Из переписи 261 миллионов оценённых доменов мы разрешили каждую цель SPF include:, на которую ссылаются 100 и более раз — 10 842 целей, покрывающих 95,2% всех ссылок include — и оценили стоимость сохранённой цепочки каждого домена по этой карте. Неразрешённые концевые цели считались нулём, а содержимое цепочек отражает день разрешения, поэтому заголовок — консервативное, смещённое к нижней границе приближение: мы говорим «как минимум». Только агрегированные данные; никогда не запись отдельного бизнеса. См. как мы выставляем оценки.

Сколько доменов превышают лимит SPF в 10 запросов?

Как минимум 797 263 — потому что в SPF встроен механизм самоуничтожения прямо в стандарте, и его спусковой крючок прячется там, где владельцы его не видят. RFC 7208 §4.6.4 ограничивает проверку SPF десятью DNS-запросами; после десяти получатель останавливается и возвращает PermError, а запись с PermError не защищает ничего. Считайте только те запросы, что видны в самой записи — как делает большинство инструментов, и как делала наша собственная перепись до этого отчёта — и вы найдёте около 8000 нарушителей (точнее, 7 958). Оцените стоимость цепочек include:, которые эти записи на самом деле подтягивают, и число достигает 797 263: примерно в 100 раза больше.

Почему владельцы не видят это заранее?

Потому что бюджет расходуют чужие записи. include:onetool.example.com читается как одна строка в вашей панели DNS — но получатель должен извлечь и эту запись тоже, и посчитать каждый механизм запроса, который она содержит, рекурсивно. Запись с тремя include может обойтись в одиннадцать. В вашей собственной зоне ничего не менялось в тот день, когда вы вышли за лимит; провайдер вложил ещё один include, и ваш SPF погиб без предупреждения.

Хуже того, DMARC трактует PermError как провал по ветви SPF — так что домен, который сломал свой SPF таким образом, теперь проваливает половину собственной аутентификации.

Что выявила оценка стоимости цепочек

Показатель	Домены
Превысили лимит в 10 запросов, цепочки оценены	797 263
Превысили лимит при подсчёте только видимых механизмов	7 958
Превысили лимит, при этом заканчиваясь строгим `-all`	112 215
Ровно на 9–10 запросах — у самого края обрыва	2 119 539

Две истории в этой таблице — третья, край обрыва, получает собственный раздел ниже:

Подсчёт по видимым записям упускает ~99% поломок. Подсчёт по видимым механизмам находит 7 958; оценка стоимости цепочек находит 797 263. Почти весь ущерб унаследован от того, что подтягивают сами include.
112 215 из сломанных записей заканчиваются на -all. Их владельцы сделали всё правильно — взобрались на стену, выбрали строгое окончание — и один лишний include аннулировал всё. Строгий на вид и сломанный — самый суровый режим отказа в безопасности электронной почты.

2,1 миллиона доменов в одном инструменте от обрыва

Число, которое должно обеспокоить читателей, у которых сейчас всё в порядке: 2 119 539 доменов разрешаются ровно в 9 или 10 запросов — сегодня под лимитом, мертвы в тот день, когда кто-то подключит ещё одну платформу. Это примерно 1 из 66 всех издателей SPF, и это совпадает с формой распределения: запись SPF 99-го процентиля уже находится на 9 запросах. Подпишитесь ещё на один маркетинговый инструмент, вставьте его строку «просто добавьте этот include» — и запись, которая была под лимитом за завтраком, аннулирована к обеду.

Чья это вина? Всё чаще — самого стека

Крупнейшие провайдеры тихо уплостили свой SPF — _spf.google.com от Google и spf.protection.outlook.com от Microsoft теперь разворачиваются в простые списки IP, стоящие ноль внутренних запросов (мы проверили оба по живому DNS во время этого анализа). Взрывы приходят из другого места: цепочки хостинг-панелей, вложенные на три уровня в глубину, региональные провайдеры, чей include стоит 7–10 запросов сам по себе, и честное накопление SaaS — почтовый ящик плюс рассылка плюс CRM плюс служба поддержки, каждый «всего один include». Почти никто не добавляет одиннадцатый запрос намеренно. Он приходит как сумма разумных решений.

Как проверить и исправить свой — бесплатно

Посчитайте свой реальный итог — наша бесплатная проверка разрешает вашу цепочку, или используйте любой счётчик запросов SPF.
Уберите мёртвый груз: инструменты, которыми вы перестали пользоваться, дублирующиеся include и устаревший механизм ptr.
Уплощайте только то, что контролируете сами. Замена глубокого include на его IP-блоки работает для вашей собственной инфраструктуры; сторонние IP меняются без уведомления.
Выделите массовым отправителям поддомен. Рассылки с news.yourdomain.com получают собственную запись и собственный бюджет в 10 запросов.

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

Что такое лимит SPF в 10 DNS-запросов? RFC 7208 §4.6.4 допускает не более 10 DNS-запросов для оценки одной записи SPF — считая запросы внутри каждого include: рекурсивно. Превышение возвращает PermError: запись считается недействительной и не обеспечивает защиты.

Что означает SPF PermError? Постоянная ошибка оценки — получатель не смог обработать вашу запись (слишком много запросов, несколько записей или сломанный синтаксис) и трактует ваш домен как не имеющий пригодного SPF. DMARC засчитывает это как провал по ветви SPF.

Сколько доменов превышают лимит запросов SPF? Как минимум 797 263 из 139 миллионов издателей SPF, согласно нашему проходу по оценке стоимости цепочек — примерно в 100× больше, чем 7 958, видимые без разрешения цепочек. Ещё 2 119 539 находятся на 9–10 запросах, в одном include от лимита.

Останавливает ли PermError доставку моей почты? Обычно нет — получатели продолжают без SPF, и ваша почта опирается на DKIM и репутацию. Что перестаёт работать — это защита: подделыватели больше не отклоняются, и каждая проверка DMARC вашей почты теряет свою ветвь SPF. Это невидимо, пока не станет дорого.

Как мне сократить число запросов SPF? Удалите неиспользуемые include и ptr, уплощите собственную инфраструктуру до ip4:/ip6:, перенесите массовых отправителей на поддомены и пересчитывайте после каждого нового инструмента. Руководство по исправлению проведёт вас через это.

Узнайте своё реальное число

Механизмы, которые вы видите, — это не ваше число запросов: разрешённое число — это то, что вычисляют получатели, и это проверка на 30 секунд.

Проверить свой домен → · Исправить SPF → · Модель зрелости SPF → · Две записи SPF = ни одной → · Ловушка ptr → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.