SPF: ошибка too many DNS lookups и превышение лимита 10 запросов

1. Что означает лимит 10 DNS lookups

По RFC 7208 (раздел 4.6.4) при оценке SPF-записи проверяющая сторона не должна выполнять более 10 DNS-запросов, вызванных механизмами и модификаторами записи. Если лимит превышен, результат проверки: permerror (permanent error). Проверяющий сервер не обязан выяснять, на каком именно запросе сработал лимит, он просто прекращает оценку.

Важно понимать: считаются не символы в записи и не количество include на первом уровне, а все DNS-запросы по дереву. Если ваша запись содержит три include, а каждый из них внутри содержит еще по три include, суммарно это уже минимум 12 запросов, и лимит превышен, хотя ваша собственная запись выглядит короткой.

Типичный симптом: в заголовках письма вы видите строку вида spf=permerror (например, в Authentication-Results), а в валидаторах: сообщение "SPF record has too many DNS lookups" или "больше 10 DNS запросов SPF". При DMARC-политике p=quarantine или p=reject такие письма теряют шанс пройти аутентификацию по SPF, остается только DKIM.

2. Какие механизмы расходуют лимит

Не все элементы SPF-записи вызывают DNS-запросы. По RFC 7208 лимит расходуют только те, что требуют обращения к DNS:

Отдельный лимит в том же разделе RFC: количество "пустых" запросов (void lookups), то есть запросов, вернувших пустой ответ или NXDOMAIN, не должно превышать 2. Иначе результат тоже permerror. Это отдельная причина ошибки, не связанная напрямую с include: если домен в include не публикует SPF запись вообще (результат проверки none), include сразу превращает это в permerror, независимо от счетчика void lookups, - RFC 7208 требует именно такого поведения для вложенной проверки с результатом none.

3. Как посчитать DNS lookups вручную

Возьмем воспроизводимый пример. Запись домена:

v=spf1 include:spf.unisender.ru include:_spf.example-esp.com mx ~all

Считаем по шагам с помощью dig (в Windows аналогично через nslookup -type=TXT):

Шаг 1. dig TXT вашдомен.ru. Получаем саму запись. Этот запрос не входит в лимит: считаются только запросы, вызванные механизмами.

Шаг 2. dig TXT spf.unisender.ru. Смотрим содержимое: если там есть свои include или redirect, каждый из них добавляет запросы. Записываем: 1 lookup за этот include плюс вложенные.

Шаг 3. dig TXT _spf.example-esp.com. Допустим, внутри находим: v=spf1 include:_netblocks1.example-esp.com include:_netblocks2.example-esp.com ~all. Это еще 2 вложенных include. Итого за эту ветку: 3 lookup.

Шаг 4. Механизм mx: 1 lookup (запрос MX-записей домена).

Итог примера: 1 (первый include) + 3 (второй include с вложенностью) + 1 (mx) = 5 lookups. Лимит не превышен, запас 5 запросов. Но стоит ESP расширить свои записи новыми include с собственной вложенностью, и запас может исчезнуть без единого изменения на вашей стороне. Именно поэтому ошибка часто появляется "сама собой".

4. Дерево диагностики: permerror не всегда про лимит 10

Прежде чем переписывать запись, убедитесь, что причина именно в lookups. Диагностируйте по дереву:

1. Сколько TXT-записей с v=spf1 у домена? Если две и больше, это отдельная ошибка (permerror по другой причине). Разбор: /blog/spf-multiple-records.

2. Есть ли синтаксические ошибки: опечатка в "v=spf1", пробел перед механизмом, недопустимый символ. Ошибка синтаксиса тоже дает permerror.

3. Есть ли include на домен без SPF записи (в том числе несуществующий)? Такой include сразу дает permerror, это не связано со счетчиком void lookups. Проверка: dig TXT по каждому домену из include, отсутствие записи v=spf1 или NXDOMAIN означает проблему.

4. Запись длиннее 255 символов в одной строке? Длинные записи должны быть разбиты на несколько строк в TXT. Некоторые DNS-панели делают это автоматически, некоторые нет.

5. И только после этого считайте lookups по инструкции из раздела 3. Если сумма больше 10, переходите к сокращению.

Проверить текущий результат по реальному письму можно в заголовках: найдите строку Authentication-Results и посмотрите значение spf=. Разбор заголовков удобно сделать в бесплатном анализаторе: /tools/email-header-analyzer.

5. Как уменьшить число DNS lookups

Способ 1. Удалить лишние механизмы. Чаще всего это mx (если рассылки не отправляются с серверов входящей почты), a (если веб-сервер домена не отправляет почту) и ptr (удалять безусловно). Экономия: до 3 lookups без каких-либо рисков.

Способ 2. Убрать неиспользуемые include. Сверьте запись со списком реальных отправителей: ESP рассылок, CRM, тикет-система, корпоративная почта. Include сервисов, которыми вы не пользуетесь, удаляйте. Типовой случай: в записи висят include от двух-трех ESP, которыми компания пользовалась годами раньше.

Способ 3. Заменить include на ip4/ip6 (flattening). Вы раскрываете цепочку include до конкретных адресов и пишете их напрямую: ip4-адреса не расходуют лимит. Плюс: полный контроль и минимум запросов. Минус: если ESP изменит свои диапазоны, ваша запись устареет, и письма начнут получать spf=fail без какого-либо предупреждения.

Способ 4. Развести потоки по поддоменам. У каждого (под)домена своя SPF-запись и свой лимит 10. Перенесите рассылки на mail.вашдомен.ru, транзакционные письма на t.вашдомен.ru, и в каждой записи останется 1-2 include. Это самый устойчивый вариант для зрелых отправителей. Подробнее о схеме: /blog/poddomeny-i-potoki-email.

Способ 5. redirect вместо множества include на поддомене. Если для отдельного потока вы создаете запись целиком сами, redirect= позволяет держать ее в одном месте: он применяется только если ни один механизм записи не совпал, и сам расходует lookup. Важно: redirect игнорируется полностью, если в записи есть механизм all (он совпадает всегда), поэтому сочетать redirect с all бессмысленно.

6. Как проверить результат

После правки DNS дождитесь обновления кеша (ориентируйтесь на TTL записи, обычно от нескольких минут до часа) и выполните проверки в таком порядке:

1. dig TXT вашдомен.ru: убедитесь, что отдается новая версия записи и она одна.

2. Прогоните домен через проверку SPF: /tools/spf-check. Суммарное число lookups должно быть 10 или меньше, void lookups не больше 2.

3. Отправьте тестовое письмо на адрес в Gmail и посмотрите исходные заголовки ("Показать оригинал"): в Authentication-Results должно быть spf=pass. Заодно проверьте dkim=pass и dmarc=pass.

4. Если домен подключен к Google Postmaster Tools, в течение нескольких дней доля SPF в дашборде должна вернуться к рабочему уровню. В PostmastersTool эта метрика собирается по API и показывается в истории по дням, так что момент восстановления виден без ручных сверок.

Учитывайте: permerror не блокирует письма сам по себе, он лишает SPF-ветку аутентификации. Если DKIM настроен корректно и выровнен с доменом From, доставляемость может почти не пострадать. Но это не повод откладывать исправление: переадресация и смена маршрута обычно ломают именно SPF (конверт письма меняется), а DKIM ломается по другой причине - когда посредник меняет тело или подписанные заголовки письма (например, список рассылки добавляет футер) или когда теряется ключ старого селектора. Если оба механизма откажут одновременно, аутентификация письма не пройдет вовсе.