Ошибка SPF permerror: too many DNS lookups означает, что проверка отправителя превысила лимит обращений, предусмотренный SPF. Начните с домена из SMTP MAIL FROM, раскройте вложенные include и уберите только подтверждённо ненужные источники отправки.
Считать лишь видимые include недостаточно: каждый из них может вести к новой цепочке. Не добавляйте вторую SPF-запись и не отключайте защиту почты — это не исправляет исходную конфигурацию.
Сначала подтвердите причину и домен
Владельцу сайта важно выяснить, какие письма пострадали: уведомления о заказах, рассылка или корпоративная переписка. Составьте список этих потоков и сервисов, которые их отправляют; для каждого понадобится отдельная проверка.
- Сохраните текст отказа доставки или результат
spf=permerrorиз заголовка Authentication-Results, добавленного доверенным сервером получателя. - Найдите проверяемый домен: обычно он указан в
smtp.mailfrom. Видимый адрес From может отличаться; менять DNS домена сайта без этой проверки преждевременно. - Запишите время ошибки, сервис отправки и исходящий IP из его технического журнала. Для передачи специалисту удалите адреса людей, тело письма и любые секреты.
SPF проверяет право исходящего сервера использовать домен SMTP-отправителя. Поэтому исправный сайт и успешная передача письма SMTP-сервису ещё не подтверждают прохождение SPF. Описание этой границы есть в документации Microsoft.
Само слово permerror не доказывает превышение лимита: причиной могут быть несколько SPF-записей или некорректная ссылка. Если сообщение не называет too many DNS lookups, сначала получите подробный результат проверки.
Найдите SPF и разверните дерево include
Для примера ниже используется зарезервированный домен: замените его проверяемым именем.
dig TXT example.com +noall +answerСреди ответов найдите запись, начинающуюся с v=spf1. Другие TXT-записи удалять не нужно. Несколько фрагментов в кавычках внутри одной TXT-записи могут составлять одно значение; две отдельные записи v=spf1 — другая ситуация.
Для каждого include:имя запросите TXT указанного имени и повторите разбор вложенных ссылок. Учитывайте также redirect=имя, когда до него доходит вычисление. Полезно вести рабочую таблицу: имя → механизм → вложенная ссылка → используемый сервис → подтверждение необходимости.
Что входит в лимит
Раздел 4.6.4 RFC 7208 ограничивает число вычисляемых DNS-зависимых элементов до десяти. В этот бюджет входят include, a, mx, ptr, exists и redirect, включая вложенные проверки. ip4, ip6 и all бюджет не расходуют.
Это не простой подсчёт сетевых пакетов или длины TXT. В SPF-проверяющем инструменте ищите раскрытое дерево и место превышения; одна зелёная отметка без пути вычисления мало помогает при разборе сложной цепочки.
Условный пример: внешний include плюс три вложенных include расходуют четыре элемента, если проверка дошла до всех них. Получатель идёт слева направо и останавливается при совпадении, поэтому ранний отправитель может пройти, а поздний — столкнуться с лимитом. Проверяйте каждый реальный поток, а не одно случайное письмо.
Сократите цепочку без потери отправителей
Перед изменением сохраните исходное значение SPF и TTL, назначьте ответственного за откат. Затем выбирайте подходящую меру:
- Убрать старый сервис. Сверьте каждый
includeс настройками CMS, рассылок и корпоративной почты. Отсутствие недавних писем не доказывает, что источник не нужен: он может использоваться для редких уведомлений. - Разделить почтовые потоки. Для рассылки можно настроить отдельный поддомен SMTP-отправителя со своей SPF-записью, если сервис поддерживает такую конфигурацию. Создать TXT у поддомена без изменения отправки недостаточно.
- Указать стабильные IP. Используйте
ip4/ip6только для документированного набора адресов, актуальность которого сможете поддерживать. IP веб-сервера нельзя подставлять вместо адресов почтового провайдера.
Эти варианты разбирает поддержка Postmark. Выбор зависит от того, кто управляет отправкой и как будут сопровождаться изменения.
Почему ручной flattening требует сопровождения
Flattening заменяет ссылки на полученный список IP. Он сокращает DNS-зависимую цепочку, но разовая копия устареет при смене адресов провайдера. До применения определите источник обновлений, ответственного и порядок повторной проверки.
Переставить проблемный include ближе к началу — не полноценное исправление для остальных отправителей. Замена -all на ~all также не уменьшает цепочку; разрешающее всем +all лишает запись защитного смысла.
Проверьте результат и оставьте контроль
После правки сверяйте опубликованный TXT с сохранённым вариантом и учитывайте TTL старого ответа. Повторите разбор дерева, затем отправьте контролируемые тестовые письма из каждого действующего сервиса в доступные вам тестовые ящики.
Критерий завершения: нужные отправители проходят SPF, превышение больше не воспроизводится, а удалённые разрешения действительно не используются. Отдельно проверьте доставку: SPF pass сам по себе не гарантирует попадание во входящие. Если письма всё ещё теряются, продолжите по общему порядку диагностики формы и почты.
Web-Puls помогает контролировать доступность сайта, но HTTP-проверка страницы не проверяет SPF и не подтверждает доставку уведомления о заказе. После смены почтового сервиса повторяйте почтовые тесты отдельно.
Если дерево SPF запутано или неизвестно, какие сервисы ещё отправляют письма, отправьте заявку на профессиональную поддержку. Укажите домен, текст ошибки, время и перечень отправителей без паролей и содержимого писем: специалист оценит задачу и предложит формат работ.