SPF-проверка допускает ограниченное число DNS-механизмов. Когда цепочка include, redirect, mx и a превышает лимит, получатель получает PermError и может отклонить письмо, даже если все отправители перечислены логически верно.

Считайте не только include в основной записи, но и все вложенные запросы подключенных сервисов. Сначала составьте дерево SPF и найдите неиспользуемые или особенно дорогие ветви.

Что сделать в первую очередь

  • Сохраните текущую TXT-запись и результаты проверки нескольких резолверов.
  • Составьте список всех систем, которые действительно отправляют почту от домена.
  • Разверните каждый include и redirect в дерево зависимостей.
  • Проверьте, нет ли нескольких SPF-записей для одного имени.

Почему возникает проблема

Симптом обычно появляется не из-за одной настройки. Сначала разделите путь данных на этапы и найдите место, где фактическое поведение расходится с ожидаемым.

  • Старые сервисы остались в SPF после отключения.
  • Один include содержит множество вложенных include.
  • Механизмы mx и a добавляют дополнительные DNS-разрешения.
  • Для разных потоков используется один перегруженный корневой домен.

Пошаговая диагностика

  • Подсчитайте механизмы include, a, mx, ptr, exists и redirect по всему дереву.
  • Отдельно отметьте void lookups и циклические зависимости.
  • Сопоставьте каждый разрешенный диапазон с реальным сервисом.
  • Проверьте SPF для поддоменов Return-Path, используемых провайдерами.
  • Отправьте тесты в несколько крупных почтовых систем и изучите Authentication-Results.

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

Исправляйте подтвержденную первопричину и сохраняйте возможность отката. После каждого изменения повторяйте один и тот же контрольный сценарий, чтобы не спутать результат нескольких правок.

  • Удалите устаревшие include после подтверждения отсутствия отправки.
  • Разделите сервисы по поддоменам и отдельным Return-Path, где это поддерживается.
  • Заменяйте mx или a явными ip4 и ip6 только при стабильной управляемой инфраструктуре.
  • Используйте безопасный SPF flattening лишь с автоматическим обновлением и контролем изменений.
  • Оставьте один валидный SPF record и публикуйте изменения с подходящим TTL.

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

  • Проверка укладывается в лимит DNS lookup без void и циклов.
  • Все реальные источники проходят SPF, а посторонние не получают pass.
  • Authentication-Results не содержит PermError или multiple records.

Как не допустить повторения

  • Ведите реестр почтовых сервисов, владельцев и дат отключения.
  • Проверяйте SPF после подключения каждого нового поставщика.
  • Мониторьте DMARC-отчеты на неизвестные источники и ошибки SPF.

Частые вопросы

Можно ли просто удалить несколько include?

Только после подтверждения, что эти сервисы больше не отправляют. Иначе их письма перестанут проходить SPF.

Поможет ли увеличение TTL?

Нет. TTL влияет на кеширование, но не увеличивает допустимое число DNS-механизмов.

Когда стоит обратиться за помощью

Для аудита нужен список легитимных отправителей и публичные DNS-записи. Пароли от почты или панели рассылок обычно не требуются.

Итог

Корректный SPF отражает реальную схему отправки и укладывается в лимиты проверки. Я могу разобрать дерево include, убрать лишнее и проверить SPF вместе с DKIM и DMARC.