Перейти к содержимому
Документация· Обновлено 15 окт. 2026 г.

SPF: больше 10 DNS-запросов (permerror) — как исправить

Почему SPF ломается после 10 lookup и как сократить include без потери отправителей.

Что не так

RFC 7208 ограничивает SPF 10 механизмами, требующими DNS-запроса: include, a, mx, ptr, exists, redirect. Вложенные include считаются тоже. На 11-м получатель возвращает permerror, и SPF для домена считается сломанным — письма уходят в спам или отклоняются по DMARC.

ip4, ip6 и all запросов не требуют и в лимит не входят.

Как проверить

Откройте Email DNS Checker — в блоке «Дерево зависимостей SPF» видно, какой include сколько запросов тянет.

Как исправить

  1. Уберите лишнее. Сервисы, через которые вы больше не отправляете (старый ESP, CRM, тестовый SMTP), — первые кандидаты.
  2. Не используйте ptr — он устарел и дорогой. a и mx замените на явные ip4:/ip6:, если адреса стабильны.
  3. Разнесите потоки по поддоменам. Маркетинг — news.example.com со своим SPF, транзакционная почта — mail.example.com. У каждого свой лимит в 10.
  4. Flattening — осторожно. Замена include на список IP работает, пока провайдер не сменит адреса. Если делаете — только с автоматическим обновлением.
; было: 12 lookup
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:spf.crm.example a mx ~all"
; стало: транзакционка на поддомене, лишнее убрано
example.com.      TXT "v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"
mail.example.com. TXT "v=spf1 include:sendgrid.net ~all"

После изменений проверьте домен ещё раз: в дереве должно быть ≤ 10 запросов.