Лимит запросов SPF: подсчет и устранение ошибок

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

С этим сталкиваются многие команды. Сначала подключают Google Workspace, затем Microsoft 365, Mailchimp, CRM и службу поддержки. Каждый поставщик предлагает «просто добавить наш include». Через несколько месяцев запись SPF остается синтаксически корректной, но при проверке возникают ошибки. Письма попадают в спам, некоторые отклоняются. Причину трудно заметить: сама запись на первый взгляд выглядит нормально.

Хорошая новость: обычно достаточно обычной ревизии. Удалите ненужные записи. Не используйте `mx`, если он действительно не нужен. Перенесите маркетинговую рассылку на поддомен. Не перегружайте основной домен.

Что такое лимит запросов SPF?

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

Правило задает RFC 7208. Ограничение не позволяет SPF порождать чрезмерный поток запросов и использоваться для усиления DNS-трафика. Это не необязательная рекомендация, а ограничение протокола.

Часто упускают, что лимит DNS-запросов SPF общий. Вам не выделяется 10 запросов для основной записи и еще 10 для каждого include. Один бюджет действует на весь путь проверки.

Механизм SPF	Расход запросов	Практический вывод
`include:`	1	Распространен, но вложенные include быстро расходуют бюджет
`a`	1	Подходит для небольших конфигураций, часто не нужен
`mx`	1+	Обычно не лучший способ разрешить исходящую отправку
`ptr`	1+	Избегайте: RFC 7208 настоятельно не рекомендует его
`exists`	1	Редко применяется, легко настроить неправильно
`redirect=`	1	Полезен в отдельных схемах, но тоже учитывается
`ip4` / `ip6`	0	Не обращается к DNS при проверке SPF
`all`	0	Задает итоговое правило без DNS-запроса

Почему лимит запросов SPF мешает «рабочим» записям

Лимит DNS-запросов SPF может нарушить проверку даже аккуратной записи. SPF учитывает не внешний вид основного TXT, а элементы include, redirect, `a` и `mx`, обращающиеся к DNS на фактическом пути проверки. Таблица дает упрощенную оценку, а не количество отдельных DNS-пакетов.

Пример:

Вы публикуете `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` и рассчитываете на три запроса. Но записи Google и Microsoft могут раскрыться в дополнительные обращения к DNS. Видимая запись короткая, а полный путь проверки может быть гораздо длиннее.

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

Есть и другая ловушка: пустые запросы, или void lookups. RFC 7208 рекомендует реализациям ограничивать их двумя. Это DNS-запрос, который возвращает пустой ответ или `NXDOMAIN`. Одна опечатка в include не обязательно нарушит проверку, но две неверные ссылки уже могут создать проблему. Тогда наряду с лимитом DNS-запросов SPF появляется риск `permerror`, даже если общее число еще меньше 10.

Требования Google к отправителям также показывают последствия: отсутствие или ошибки аутентификации у массовых отправителей могут привести к попаданию в спам или отклонению. В документации Google для таких отправителей указаны SPF, DKIM и DMARC; письма, не соответствующие требованиям, могут отклоняться или попадать в спам. См. ответы Google на вопросы о требованиях к отправителям.

Как рассчитать расход DNS-запросов SPF

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

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

dig +short txt example.com

Пример вывода:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Затем проверьте каждый указанный домен:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

Продолжайте разбирать цепочки, пока не останутся только `ip4`, `ip6` или завершающие элементы политики.

Считайте по следующим правилам:

Учитывайте каждый фактически проверяемый include, a, mx, ptr, exists и redirect.
Учитывайте фактически проверяемые вложенные элементы включенных записей.
Не учитывайте ip4, ip6 и all.
Отмечайте цели include, не возвращающие данных. Они могут вызвать проблему с пустыми запросами.

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

Типичные ошибки при работе с лимитом запросов SPF

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

Основные ошибки:

Ошибка	Чем мешает	Что лучше сделать
Оставлять старых поставщиков	Расходует бюджет запросов и расширяет риски	Удалить всех, через кого больше не отправляете
Разрешать отправку через `mx`	Серверы входящей почты часто не являются отправителями	Явно разрешить фактические отправляющие системы
Использовать `ptr`	Медленный, ненадежный и не рекомендуемый механизм	Удалить его
Отправлять все с одного домена	Маркетинговая и транзакционная почта делят бюджет SPF	Разделить потоки по поддоменам
Выполнять flattening вручную	Может нарушить проверку при смене IP поставщика	Автоматизировать обновления или отказаться от flattening

Команды также путают видимую и фактическую сложность. Один include поставщика после раскрытия может расходовать несколько запросов. Поэтому подход «добавим еще одного отправителя» плохо сочетается с лимитом DNS-запросов SPF.

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

Как устранить превышение лимита SPF без лишнего риска для почты

Наиболее осторожный подход к лимиту DNS-запросов SPF состоит в упрощении политики, а не в новых обходных решениях. Сначала удалите ненужных отправителей. Затем перенесите системы с большим объемом отправки на поддомены. Используйте flattening только при наличии автоматического обновления.

1. Удалите лишнее.

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

2. Разделите отправку по поддоменам.

Для растущей команды это часто наиболее удобный вариант.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

У каждого поддомена своя политика и свой бюджет SPF. Это помогает разгрузить основной домен и упрощает соблюдение лимита DNS-запросов SPF.

3. Используйте flattening лишь в крайнем случае.

Flattening заменяет include непосредственными диапазонами IP:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

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

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

Старый и новый подход: управление лимитом SPF с TrekMail

Старый подход к лимиту DNS-запросов SPF состоит в накоплении почтовых провайдеров, маркетинговых платформ и релеев на одном основном домене, пока DNS-конфигурация не становится трудноразбираемой. Новый подход сокращает зависимости и сразу разделяет роли отправителей.

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

Новый подход: простая схема почтового хостинга, массовая отправка на отдельных поддоменах и короткая политика SPF основного домена с запасом запросов.

Здесь может помочь TrekMail. Для управляемой отправки в платных тарифах описанная настройка предусматривает добавление `include:spf.trekmail.net` в SPF. Сам include учитывается как один запрос; возможные вложенные ссылки следует проверить отдельно. В описании предложение начинается от $3.50 в месяц и включает собственные домены, IMAP-ящики, catch-all, пересылку, встроенный инструмент миграции и API. Для платных тарифов указана 14-дневная пробная версия с обязательной банковской картой. Nano описан как постоянно бесплатный тариф без пробного периода с BYO SMTP. Перед подключением уточните актуальные условия.

В тарифе Nano TrekMail может хранить почту, а отправку можно оставить SES, Mailgun или другому релею. Аккуратно разделяйте потоки по поддоменам, чтобы основная политика не превышала лимит DNS-запросов SPF. Практические настройки изложены в документации TrekMail о собственном SMTP (BYO), управляемом SMTP TrekMail и запуске миграции из панели управления.

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

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

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

Лимит DNS-запросов SPF не теоретический крайний случай из RFC, а жесткое эксплуатационное ограничение. Накопление поставщиков затрудняет его соблюдение. Делайте запись короткой и определяйте ответственных за DNS. Иначе пять поставщиков на одном пути аутентификации могут заставить вас разбирать заголовки писем в 2 часа ночи.

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