SPF flattening: как обойти лимит в 10 DNS-запросов

Что такое лимит в 10 DNS-запросов

Проверка SPF (Sender Policy Framework) завершается ошибкой permerror, когда принимающему почтовому серверу нужно выполнить больше 10 DNS-запросов, чтобы разобрать вашу SPF-запись. Причина — вложенные механизмы include: если ваша запись подключает провайдера, а тот подключает другой сервис, каждый шаг учитывается в лимите. Чтобы это исправить, используйте SPF flattening («уплощение» записи): рекурсивные запросы заменяются статическим списком IP-адресов.

Как инженер, отвечающий за доставляемость, я чаще всего вижу эту проблему при «разрастании поставщиков». Компания начинает с одного транзакционного провайдера, добавляет маркетинговый инструмент, затем CRM — и вдруг её SPF-запись превращается в карточный домик. Когда срабатывает 11-й запрос, принимающий сервер прекращает поиск и возвращает постоянную ошибку. Это значит, что письмо не просто помечается как спам — его могут полностью отклонить, потому что проверка аутентификации провалилась в принципе.

Как работает лимит запросов

Согласно RFC 7208, лимит нужен для защиты DNS-инфраструктуры от атак типа «отказ в обслуживании» (DoS). Без него злоумышленник мог бы создать циклическую ссылку или огромную цепочку include, вынуждающую принимающий сервер выполнять сотни запросов ради одного письма.

Что считается запросом?

Не все механизмы в SPF-записи бесплатны. DNS-запрос выполняют:

• include: самый частый виновник. Указывает серверу посмотреть SPF-запись другого домена.
• a: запрашивает A-запись домена.
• mx: запрашивает MX-записи домена.
• ptr: запрашивает обратную зону DNS (механизм устарел, его следует избегать).
• exists: запрашивает конкретный домен, чтобы проверить, существует ли он.

Механизмы ip4 и ip6 бесплатны, потому что IP-адрес явно указан в записи.

Анатомия цепочки запросов

Рассмотрим гипотетическую SPF-запись:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

На первый взгляд это 3 запроса. Но если _spf.google.com содержит ещё три механизма include, а spf.protection.outlook.com — четыре, вы уже на 10 запросах. Будь в записи SendHQ тоже include, вы упёрлись бы в лимит. Это и есть «цепочка include».

Как распознать permerror

Если вы не уверены, достигли ли лимита, проверьте записи с помощью Email DNS Checker от SendHQ. В исходном логе или в инструменте анализа заголовков вы увидите примерно такой результат:

spf=permerror (too many DNS lookups)

Это не то же самое, что softfail (~all) или fail (-all). permerror означает, что проверку SPF не удалось завершить. В этом случае получатель не может проверить, авторизован ли отправитель, и агрессивные фильтры часто отбрасывают письмо или помечают его.

Что такое SPF flattening?

SPF flattening — это преобразование всех механизмов include, a и mx в плоский список адресов ip4 и ip6.

Пример: до и после

До (рекурсивно):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Предположим, что _spf.example.com разрешается в 1.2.3.4, а _spf.vendor.com — в 5.6.7.8)

После (плоский список):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

После преобразования записи в список IP-адресов число запросов падает с 2 (или больше) до 0. Принимающий сервер сразу видит IP-адреса и проверяет отправителя без дополнительных DNS-запросов.

Компромиссы flattening

Flattening — мощное решение, но оно заметно усложняет поддержку.

1. Проблема устаревших IP-адресов

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

Если вы «уплощили» эти записи в собственном DNS, ответственность за IP-адреса теперь на вас. Если провайдер сменит IP, а вы не обновите плоский список, письма не пройдут аутентификацию SPF. Именно поэтому ручной flattening опасен для больших объёмов транзакционной почты.

2. Ограничения длины записи

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

Как исправить цепочки include

Если вы упираетесь в лимит в 10 запросов, двигайтесь по этой иерархии решений — от самых безопасных к самым радикальным.

Шаг 1: проверка и чистка

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

Шаг 2: поддомены для разных типов трафика

Это самое профессиональное архитектурное решение. Вместо того чтобы размещать все сервисы на корневом домене, разделите их по назначению:

• Корневой домен (example.com): корпоративная почта (Google Workspace/Outlook).
• Поддомен для транзакционных писем (mail.example.com): SendHQ или Amazon SES.
• Поддомен для маркетинга (news.example.com): Mailchimp или Klaviyo.

У каждого поддомена своя SPF-запись и свой лимит в 10 запросов. Это изолирует риски и не даёт сложной SPF-цепочке маркетингового инструмента сломать критически важные транзакционные письма.

Шаг 3: динамический SPF flattening

Динамический flattening — это сервис, который в реальном времени отслеживает цепочки include ваших провайдеров и автоматически обновляет вашу DNS-запись актуальными IP-адресами. Он решает проблему «устаревших IP», автоматизируя обновление через API.

SPF в контексте современной доставки

Важно понимать, что SPF — лишь одна часть головоломки аутентификации. Чтобы принимающий сервер принимал вашу почту, SPF нужно согласовать с DKIM и DMARC. Подробный разбор их взаимосвязи — в руководстве SendHQ по DKIM, SPF и DMARC.

Приём, доставка и попадание во «Входящие»

Как инженер, я различаю три этапа:

1. Приём: принимающий сервер принимает соединение и письмо. Из-за SPF permerror сервер может отклонить письмо на уровне SMTP, то есть оно так и не будет принято.
2. Доставка: письмо принято и помещено в почтовый ящик пользователя (или в папку).
3. Попадание во «Входящие»: письмо оказывается в основной папке «Входящие», а не в «Спаме».

SPF flattening решает проблему приёма. Он не гарантирует попадание во «Входящие». Оно зависит от репутации отправителя, содержимого и метрик вовлечённости.

Особенности для ИИ-агентов

С распространением ИИ-агентов, отправляющих письма через API, риск проблем с SPF растёт: агенты могут генерировать большие объёмы писем с разных доменов. Проектируя процессы с агентами, относитесь к отправке писем как к внешнему побочному эффекту.

Идемпотентность и подтверждение

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

Анализ стоимости провайдеров отправки

Выбирая провайдера для SPF-записи, учитывайте стоимость вашего объёма отправки. Цены на сентябрь 2026 года:

• Amazon SES: 0.10 USD за 1 000 писем при оплате a la carte (цены Amazon SES). За 50 000 писем — примерно 5 USD. Новые тарифы, введённые 21 июля 2026 года: Essentials (0.16 USD за 1 000), Pro (0.22 USD за 1 000 плюс 105 USD/месяц/регион) и Enterprise (0.23 USD за 1 000 плюс 500 USD/месяц).
• Postmark: 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.20 USD за 1 000 (цены Postmark). 50 000 писем на тарифах Postmark стоят около 66 USD.
• Resend: бесплатный тариф — 3 000 писем в месяц (не более 100/день). Pro — 20 USD в месяц за 50 000 писем, превышение — 0.90 USD за 1 000 (цены Resend).
• Mailgun: 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.10 USD за 1 000 (цены Mailgun).
• SendGrid: бесплатный тариф теперь — 60-дневный пробный период, Essentials — от 19.95 USD в месяц (цены SendGrid).

Чек-лист диагностики SPF

Если вы подозреваете проблему с лимитом запросов, пройдите по этому чек-листу:

• Выполните проверку DNS для корневого домена и всех поддоменов отправки.
• Подсчитайте общее число механизмов include, a, mx и exists.
• Проследите цепочки include каждого провайдера, чтобы увидеть, есть ли в них вложенные DNS-запросы.
• Определите и удалите неиспользуемых провайдеров.
• Оцените, можно ли перенести трафик на выделенный поддомен (например, notifications.example.com).
• Если лимит всё ещё превышен, реализуйте динамический SPF flattening.
• Убедитесь, что итоговая запись не превышает лимит в 255 символов на строку.

Сводная таблица: механизмы SPF

Механизм | DNS-запрос? | Риск | Рекомендация

ip4 / ip6 | Нет | Низкий | Использовать для статических IP

include | Да | Высокий | Использовать экономно, следить за цепочками

a | Да | Средний | По возможности избегать, использовать ip4

mx | Да | Средний | По возможности избегать

ptr | Да | Высокий | Не использовать (устарел)

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

Полный набор инструментов для управления аутентификацией домена — на https://sendhq.cc.