Лимит DNS-поиска SPF: как проверить и исправить

Лимит DNS-поиска SPF относится к тем проблемам DNS, которые кажутся безобидными до появления сбоев. Вы добавляете еще один сервис отправки, CRM или службу поддержки. Затем получатель может пометить, задержать или отклонить обычное письмо, поскольку проверка SPF превысила установленную протоколом границу.

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

В этом руководстве разбираем сам лимит, учитываемые элементы, недостатки ручного flattening и варианты более устойчивой конфигурации, которую можно сопровождать после дальнейшего роста.

Что такое лимит DNS-поиска SPF?

Лимит DNS-поиска SPF ограничивает число учитываемых механизмов и модификаторов, требующих DNS-поиска при проверке SPF. По RFC 7208 предел равен 10. Его превышение дает permerror, а не успешный результат.

Иными словами, у SPF есть бюджет. Если проверка задействует больше 10 элементов, требующих DNS-поиска, реализация должна остановиться с постоянной ошибкой. Это не особенность Gmail, а требование стандарта SPF.

RFC 7208 прямо указывает расходующие бюджет элементы: include, a, mx, ptr, exists и redirect. Элементы ip4, ip6 и all при собственной проверке таких запросов не требуют.

Это различие важно: часто оценивают длину записи вместо стоимости проверки. Короткая запись может дать ошибку, а длинная пройти. Значение имеет нагрузка фактически выполняемого пути проверки.

Что учитывается в лимите SPF?

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

Бюджет расходуют следующие элементы:

include: проверяет SPF другого домена; его результат pass может обеспечить совпадение механизма include.
a: разрешает имя узла в IP-адреса и сопоставляет их с адресом подключения.
mx: получает MX-записи, затем адреса соответствующих серверов.
ptr: использует обратное разрешение имен; его применение не рекомендуется.
exists: проверяет наличие результата предусмотренного DNS-запроса записи A.
redirect: передает проверку другой политике SPF, если ни один механизм не совпал.

Следующие элементы сами не расходуют бюджет DNS-поиска:

ip4
ip6
all

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

Вы считаете, что добавили 6 отправителей. После рекурсии получателю может потребоваться проверить 11 или 12 учитываемых элементов. Так лимит SPF превышают команды, уверенные, что остались ниже 10.

Почему растущие команды превышают лимит

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

Вначале запись проста. Следующие значения поставщиков приведены для иллюстрации: проверьте актуальную документацию перед применением:

v=spf1 include:_spf.google.com ~all

Затем набор сервисов растет:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

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

Поэтому поведение лимита SPF кажется случайным. Утром вы ничего не меняли в DNS, но поставщик ночью изменил внутреннюю структуру SPF. Вчерашний успешный результат сегодня может превратиться в permerror.

Если проблема шире SPF, дополнительно изучите инструкцию TrekMail почему письма попадают в спам. Ошибки аутентификации и проблемы репутации могут проявляться одновременно.

Что происходит при превышении лимита SPF?

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

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

Состояние	Что видит получатель	Возможное последствие
Меньше 10 учитываемых элементов	Бюджет соблюден, если нет других ошибок	SPF может пройти при совпадении подходящего механизма
Больше 10 учитываемых элементов	Permerror	Письмо могут отфильтровать, задержать или отклонить
SPF permerror и DKIM fail	Нет успешного выровненного метода, если отсутствуют другие действительные подписи	DMARC может не пройти; решение зависит от получателя
SPF permerror и DKIM pass	Разные результаты методов	Действительный выровненный DKIM все еще может обеспечить успех DMARC

Требования Google к отправителям учитывают аутентификацию и выравнивание. При значительных объемах в Gmail следите за SPF и DKIM согласно применимым условиям, не считая SPF необязательной деталью. Успех проверки не гарантирует входящие. Смотрите правила Google для отправителей.

Есть еще два связанных ограничения:

Пустые результаты, или void lookups. RFC 7208 рекомендует ограничивать их двумя. Ошибка в include или исчезнувший домен поставщика может привести к permerror при ответе об отсутствии имени или нужного результата.
Размер ответа DNS. Большие ответы могут усекаться и требовать перехода на другой транспорт. В проблемной сети возможны временные ошибки и тайм-ауты.

Почему flattening SPF не всегда подходит

Лимит DNS-поиска SPF подталкивает к flattening: includes заменяют прямыми IP-адресами, которые не расходуют соответствующий бюджет. Но решение создает новую обязанность по сопровождению.

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

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Для проверки SPF это дешево. Но SaaS-поставщики меняют инфраструктуру, добавляют диапазоны и переходят к другим провайдерам. Устаревшая запись может перестать разрешать настоящие письма, а удаленные диапазоны, наоборот, могут слишком долго оставаться авторизованными.

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

Более структурированный вариант: разделять функции отправки между подходящими поддоменами, ограничивать политики и использовать выровненный DKIM. Для SPF нужны действительно разные домены конверта, а не только видимые адреса From. Это упрощает поиск ответственного источника, но не гарантирует изоляцию репутации.

В TrekMail такой архитектурой может быть удобнее управлять в зависимости от тарифа. По текущей документации доступны собственные домены, IMAP-ящики, catch-all, миграция, пересылка и BYO SMTP или управляемый SMTP. Наличие BYO SMTP в бесплатном плане и управляемого SMTP в платных нужно сверять с актуальными условиями. Возможности и оплата зависят от плана. Настройку DNS описывают обязательные записи DNS, отправку материал собственный SMTP (BYO).

Устойчивое решение для лимита SPF

Полезная долгосрочная стратегия для лимита DNS-поиска SPF заключается в сегментации. Деловая переписка, маркетинг, поддержка и транзакционные письма могут использовать отдельные домены конверта, чтобы их проверки SPF имели собственные бюджеты. Проверьте выравнивание DMARC: relaxed допускает соответствующие организационные домены, strict требует точного совпадения. Репутационные эффекты все равно требуют наблюдения.

Возможная схема:

Основной домен для личной деловой переписки, например alice@company.com.
Маркетинговый поддомен, например newsletter.company.com.
Поддомен поддержки, например support.company.com.
Транзакционный поддомен, например updates.company.com.

Примеры записей:

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

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

Разделение также помогает анализировать репутацию. Неудачная маркетинговая практика все же может затронуть другие потоки через общие IP или оценку организационного домена. Автоматического репутационного барьера не возникает.

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

Как проверить бюджет DNS-поиска SPF

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

Начните с dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Затем посчитайте все учитываемые элементы, требующие DNS-поиска на выполняемом пути, включая вложенные. Проверка может завершиться на совпадении, поэтому учитывайте фактические IP отправки.

Практический порядок:

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

Также ищите несколько SPF-записей для одного имени. TrekMail рекомендует объединять разрешенные источники в одной SPF TXT-записи, а не публиковать отдельные записи SPF для одного узла. При этом одна TXT-запись технически может содержать несколько строковых фрагментов. Дополнительно полезны создание почты на домене, хостинг почты нескольких доменов и imapsync.

Роль TrekMail в более понятной конфигурации

TrekMail не отменяет лимит DNS-поиска SPF. Хостинг не может убрать границу протокола. Но его функции могут помогать строить архитектуру, учитывающую эту границу.

Это важно для двух групп.

Небольшие команды и основатели могут оставить деловую переписку на простой политике основного домена и выбирать BYO SMTP или управляемый SMTP по задаче. Агентства и MSP могут разделять клиентские потоки и централизованно подключать домены. Экономия и сложность сопровождения зависят от использования и тарифа.

Прежний и структурированный подход:

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

Структурированный: платформа нескольких доменов объединяет IMAP-ящики, но реальные поддомены конверта разделяют отправку, а SPF регулярно проверяют после изменений поставщиков.

По приведенным условиям Starter начинается с $3.50 в месяц. Бесплатный план описан как $0 с 10 доменами, 5GB общего хранилища и BYO SMTP. Платные планы могут добавлять управляемый SMTP, более высокие лимиты и автоматизацию. Проверьте актуальные условия и рассчитайте архитектуру на странице тарифов TrekMail.

Вывод: учитывайте лимит SPF при проектировании

Лимит DNS-поиска SPF не редкая случайность, а установленное протоколом ограничение. При росте набора сервисов регулярно проверяйте стоимость вычисления, не дожидаясь превышения.

Не ждите permerror. Ведите учет отправителей, убирайте ненужные includes и разделяйте подходящие потоки реальными поддоменами конверта. Сохраняйте основной домен простым. Это уменьшает риски для важной почты, но не гарантирует доставку.

Для такой архитектуры с одним или множеством доменов TrekMail предлагает по текущим планам собственные домены, IMAP-ящики, общее хранилище, миграцию и разные SMTP-варианты. Цена и ограничения зависят от тарифа. Изучите бесплатный старт на trekmail.net или сравните планы на trekmail.net/pricing.