Слишком много запросов SPF: устранение PermError

Слишком много DNS-запросов SPF сначала кажется небольшой ошибкой. Но когда письма перестают проходить проверку, последствия быстро становятся серьезными. При превышении лимита SPF получатель может вернуть PermError вместо успешного результата проверки. Это затрагивает счета, ответы, уведомления и письма приложений.

Если вы уже улучшаете доставляемость и настраиваете полноценную корпоративную почту, это часть той же работы. Статья TrekMail о корпоративной почте для малого бизнеса объясняет общую схему. Здесь же разбирается конкретная причина превышения лимита SPF и способы исправить ее, не исключив нужных отправителей.

Кратко: при проверке SPF допускается не более 10 элементов, обращающихся к DNS. Подсчет включает рекурсивно проверяемые ссылки. Учитываются ваши поставщики и их вложенные записи. Ошибочные и устаревшие include тоже могут участвовать. Превышение превращается в реальную проблему аутентификации, а не в предупреждение, которым можно пренебречь.

Что означает «слишком много DNS-запросов SPF»?

Это означает, что при проверке SPF принимающему серверу пришлось бы обработать больше 10 элементов, вызывающих обращения к DNS. По RFC 7208 результатом должен стать PermError. Проверка политики завершается ошибкой вместо ожидаемого результата аутентификации.

Правило ограничивает злоупотребления и чрезмерную рекурсию DNS. Оно обязательно: RFC 7208 требует вернуть PermError при превышении лимита. Документация Microsoft по SPF также предупреждает, что слишком много обращений приводит к ошибке SPF.

Поэтому проблема часто возникает у доменов, к которым годами добавляли инструменты: Google Workspace, Microsoft 365, CRM, систему заявок, платформу рассылок, иногда пересылку или релей. Каждый include отдельно выглядит безобидно. Проблема в цепочке.

«Всего три include» не гарантируют отсутствие ошибки. Один include может раскрыться в несколько дополнительных обращений. Важны полные пути проверки, а не только строка, вставленная в DNS.

Какие механизмы SPF учитываются в лимите?

Только часть механизмов SPF обращается к DNS. Это важно: часто быстрее всего сократить расход, заменив рекурсивную схему более простым разрешением для конкретных отправителей. Для правильной ревизии нужно понимать, что учитывается. Таблица показывает упрощенную оценку, а не число отдельных DNS-пакетов.

Механизм	Расход запросов	Примечания
`include:`	1	Частая причина превышения: рекурсия продолжается во вложенных записях.
`a`	1	Получает записи A или AAAA.
`mx`	1+	Разрешает MX; могут сработать дополнительные ограничения MX.
`ptr`	1+	Использование настоятельно не рекомендуется.
`exists`	1	Встречается в сложных конфигурациях и схемах с макросами.
`redirect=`	1	Передает проверку SPF другой записи.
`ip4` / `ip6`	0	Статические значения без обращения к DNS при проверке.
`all`	0	Только итоговое правило, без запроса.

Есть еще одна ловушка. RFC 7208 рекомендует ограничивать пустые запросы двумя: это ответы NXDOMAIN или ответы без данных. Поэтому поиск причины может усложниться: запись способна завершиться ошибкой, даже если вы считали, что остались ниже 10.

Пример: опечатка в include:spf.trekmaill.net может вызвать пустой запрос. Если в цепочке два неверных домена, проверьте, нет ли других пустых запросов. Превышение применяемого получателем ограничения может привести к PermError еще до того, как общий расход станет главной проблемой.

Как проверить превышение лимита SPF?

Начните с основной записи SPF, раскройте каждый include и посчитайте механизмы, обращающиеся к DNS, на фактических путях проверки. Не полагайтесь на догадки или старые снимки экрана. Запросите дерево записей и проверьте текущие данные DNS.

Начните с основной записи:

dig +short txt example.com

Затем раскройте каждый найденный include:

dig +short txt _spf.google.com

# or

dig +short txt spf.protection.outlook.com

dig +short txt spf.trekmail.net

При обходе учитывайте каждый проверяемый include, a, mx, exists и redirect, включая вложенные записи. Если поставщик недавно изменил свой SPF, прежняя рабочая запись может начать превышать лимит, хотя вы ничего не меняли.

Краткий список для ревизии:

Получите актуальную TXT-запись SPF домена.
Рекурсивно раскройте все включенные домены.
Посчитайте механизмы, обращающиеся к DNS, на полных путях проверки.
Проверьте опечатки, отключенных поставщиков и пустые ответы.
Удалите дублирующие сервисы, прежде чем применять сложные решения.

Если одновременно подключаете новый домен, руководство TrekMail по необходимым DNS-записям показывает базовую структуру, которую стоит сохранить.

Что обычно вызывает слишком много DNS-запросов SPF?

Чаще причина в накоплении поставщиков, а не в одной серьезной ошибке. Большинство проблемных записей росло по одному include в течение месяцев или лет. Без ответственного за всю политику она расширялась до нарушения проверки.

Типичные причины просты:

После миграции не удалили старых поставщиков. Маркетинговые инструменты подключили к основному домену корпоративной почты. Разные команды разрешали отправителей без общего реестра. Кто-то скопировал пример SPF поставщика, не проверив число вложенных include.

Еще одна частая причина: собственный SMTP. Несколько исходящих сервисов на одном основном домене повышают вероятность превышения. Управляемый SMTP TrekMail может упростить конфигурацию, объединив отправку за одним include, но вложенные ссылки все равно нужно проверять. При BYO SMTP расход SPF каждого провайдера вы контролируете сами.

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

Практичный способ исправления: разделить почту по поддоменам

Один из наиболее понятных способов устранить превышение: перенести разные почтовые потоки на разные поддомены. У каждого будет собственная запись SPF и свой бюджет запросов. Основной домен останется проще, а массовые отправители будут настроены отдельно.

Пример:

# Root domain for staff and transactional mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"

# Marketing subdomain for bulk mail
news.example.com. TXT "v=spf1 include:servers.mcsv.net include:spf.mailvendor.com -all"

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

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

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

Стоит ли выполнять flattening SPF?

Flattening может устранить превышение, заменив цепочки include прямыми элементами ip4 и ip6. Статические IP-механизмы не обращаются к DNS при проверке SPF. Компромисс заключается в обслуживании: при смене инфраструктуры поставщика значения могут устареть.

До flattening:

v=spf1 include:spf.example-vendor.com -all

После flattening:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.12 -all

Flattening может быть полезен, если:

Поставщик публикует стабильные диапазоны IP.
Есть автоматизация обновления записи.
Нужно временно устранить аварийную ситуацию с отправкой.

Flattening рискован, если:

Поставщик часто меняет IP.
Вы вручную управляете большим числом доменов.
Нет мониторинга, который обнаружит расхождения.

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

Старый и новый подход к превышению лимита SPF

Многие команды реагируют новыми правками DNS в надежде, что ничего не сломается. Лучше сократить зависимости: меньше отправителей, четкие границы доменов, единая платформа для обычной корпоративной почты. Это звучит не так эффектно, как «продвинутая оптимизация SPF», зато часто проще в эксплуатации.

Старый подход	Новый подход
Добавлять новые include сторонних сервисов в основной домен	Упростить основной домен и перенести массовую отправку на поддомены
Использовать отдельную почтовую платформу для каждого процесса	Объединить повседневную корпоративную почту на одной платформе
Вручную выполнять flattening и забывать об обновлении	По возможности использовать управляемую отправку, а flattening поддерживать автоматизацией
Искать ошибку SPF после ухудшения доставки	Проверять расход запросов при каждой смене поставщиков

Здесь может подойти TrekMail. Для типичных компаний и агентств один include проще поддерживать, чем набор старых провайдеров, если проверять и его вложенную структуру. Описанное предложение включает собственные домены, IMAP-ящики, catch-all, пересылку, инструмент миграции, API и BYO SMTP либо SMTP в платных тарифах. Starter указан от $3.50 в месяц при ежегодной оплате; для платных тарифов описан 14-дневный пробный период с обязательной банковской картой. Nano предлагается как бесплатный тариф без требования карты. Уточните актуальные функции и условия перед подключением.

Если хотите перенести существующую почту, а не бесконечно поддерживать старую запутанную систему, обратитесь к обзору IMAP-миграции TrekMail.

Что делать сейчас, если превышение SPF уже мешает почте

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

Составьте реестр всех активных отправителей домена.
Удалите include отмененных или дублирующих сервисов.
По возможности перенесите массовую и прикладную почту на поддомен.
Оставьте основную запись короткой и понятной.
Проверяйте результат после каждой правки. Не объединяйте изменения вслепую.

Пример простой основной записи для управляемой отправки TrekMail:

v=spf1 include:spf.trekmail.net -all

Совместная запись с другим отправителем может выглядеть так:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Не забывайте: на домен должна приходиться только одна TXT-запись SPF. Две отдельные записи SPF создадут другую ошибку.

После очистки несколько дней наблюдайте за DMARC и результатами аутентификации. Превышение лимита SPF часто связано с более широкими проблемами ведения DNS, поэтому не останавливайтесь после первой зеленой отметки.

Итог: как снизить риск повторного превышения SPF

Долгосрочное решение заключается в простой архитектуре, а не в усложнении DNS. Не перегружайте основной домен, используйте поддомены для массовой отправки и объединяйте отправителей, когда это разумно. Flattening применяйте только при возможности поддерживать его. Проверяйте все дерево include при добавлении поставщика.

Это основа работы. Ошибка часто возникает, когда никто не ведет карту отправителей. Актуальный реестр делает исправление гораздо понятнее.

Для более простого начала TrekMail описывает хостинг нескольких почтовых доменов с небольшим объемом DNS-настроек, общим хранилищем, встроенной IMAP-миграцией и без оплаты за каждого пользователя. Можно рассмотреть бесплатный план или сравнить актуальные платные предложения на странице тарифов TrekMail. Для смежной работы пригодится руководство настройка пересылки почты и устранение ошибок.

Превышение лимита SPF исправимо. Но это не косметическое предупреждение: относитесь к нему как к ошибке аутентификации.

Источники: RFC 7208 и руководство Microsoft по SPF.