Создание записи SPF: отправители, поддомены и лимит запросов

Если вам нужно создать SPF-запись для домена, задача проста: разрешить нужным отправителям отправку, не превращая DNS в клубок настроек, который сломается через полгода. Обычно все начинается одинаково. Подключили один сервис, затем другой. Потом Microsoft возвращает 550 5.7.515, Google возвращает 550 5.7.26, и в 11 вечера вы разбираетесь с TXT-записями.

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

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

Почему SPF-записи часто перестают работать

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

RFC 7208 определяет это однозначно. DNS-запросы вызывают элементы include, a, mx, ptr, exists и redirect. Получатели обязаны ограничить их число при вычислении, включая рекурсивные проверки, значением 10. Превышение дает постоянную ошибку, а не предупреждение. Несколько SPF-записей для одного имени также вызывают PermError. Другие TXT-записи, не относящиеся к SPF, разрешены.

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

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

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

Главное ограничение: лимит в 10 элементов с DNS-обращениями

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

В лимит входят:

• include
• a
• mx
• ptr (не используйте)
• exists
• redirect

В лимит не входят:

• ip4
• ip6
• all

Важны и пустые DNS-ответы, называемые void lookup. RFC 7208 рекомендует ограничивать такие обращения двумя. Опечатка в адресе include может израсходовать часть этого запаса. Ошибочные ссылки способны вызвать еще один PermError при превышении рекомендованного предела; само достижение предела не означает его превышения.

Если домен отправляет почту через четыре или пять сервисов, лимит стоит проверить заранее. Причина не в хрупкости SPF как такового, а в том, что рекурсивные цепочки поставщиков могут перегрузить вашу схему.

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

Устойчивая схема отделяет личную переписку от массовых рассылок и писем приложений. Основной почтовый провайдер остается на основном домене, маркетинг, поддержка и приложения используют поддомены. Но отдельный лимит SPF появляется только тогда, когда соответствующий поддомен действительно используется в MAIL FROM или Return-Path. Изменить лишь видимый адрес From недостаточно. Для DMARC по-прежнему требуется согласованная аутентификация SPF или DKIM; строгий и ослабленный режимы согласования различаются.

Схема выглядит так:

1. Основной домен @ используется для личной деловой переписки.
2. Поддомены с правильно настроенным доменом конверта используются для рассылок, поддержки, транзакционных уведомлений и специализированных отправителей.
3. Для каждого имени публикуется одна SPF-запись. Уберите дубли SPF и устаревшие записи; независимые TXT-записи можно оставить.

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

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

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

Пример для маркетингового поддомена:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Это пример значений поставщиков, а не универсальный рецепт. Сверьтесь с актуальными официальными инструкциями Mailchimp и HubSpot, включая поддержку собственного MAIL FROM. Только если SPF действительно проверяет marketing.example.com, его лимит отделен от лимита корпоративной почты на example.com.

TrekMail может вписаться в такую структуру. В документации по настройке домена базовый include указан как include:spf.trekmail.net, а проверка DNS помогает обнаруживать конфликты. Она не заменяет полной проверки отправителей. Если вы еще настраиваете ящики и DNS, обратитесь к материалам Добавление домена в TrekMail и Проверка состояния DNS, учитывая актуальные инструкции сервиса.

Пошаговая настройка SPF без догадок

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

Порядок действий:

1. Перечислите все сервисы, отправляющие почту от имени вашего домена.
2. Отнесите каждый к корпоративной почте, транзакциям, поддержке или маркетингу.
3. Определите имя домена и фактически используемый MAIL FROM для каждого отправителя.
4. Используйте минимальную корректную политику SPF для этого домена.
5. Опубликуйте одну SPF-запись типа TXT для каждого имени; другие TXT-записи остаются независимыми.

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

Пример управляемого SMTP TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Комбинированный пример TrekMail и собственного SMTP для Nano или гибридной схемы, только если оба маршрута действительно требуют разрешения:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

При использовании собственного SMTP разрешайте реального провайдера отправки для соответствующего домена конверта. Не добавляйте автоматически TrekMail, Amazon SES или чужие include. Для SES особенно важно сверить актуальные требования к собственному MAIL FROM. В описанной модели Nano исходящая почта требует вашего SMTP-провайдера. В приведенном предложении платные тарифы начинаются от $3.50 в месяц и включают управляемый SMTP, а Nano обозначен как постоянно бесплатный. Для платных тарифов указана бесплатный пробный период на 14 дней с обязательной кредитной картой. Все эти сведения зависят от действующих условий. Настройка описана в разделах Собственный SMTP (BYO) и Управляемый SMTP TrekMail.

Публикация и проверка записи

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

Mac или Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Должен быть один SPF-параметр, начинающийся с v=spf1. Не несколько SPF-записей и не действующая запись рядом с забытой после миграции три года назад. Другие TXT-записи сами по себе конфликт SPF не создают.

Быстрая проверка:

• Начинается с v=spf1
• Заканчивается на -all, когда завершены тестирование и полная инвентаризация отправителей
• Содержит только действительно нужных отправителей
• Существует как SPF-запись в единственном экземпляре для каждого имени

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

Распространенные ошибки SPF и быстрые меры

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

Два практических правила избавляют от лишних проблем:

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

Документация Google верно формулирует цель: аутентификация вместе с согласованием доменов, а не SPF в отрыве от остального. SPF может пройти, но письмо все равно не соответствовать политике, если аутентифицированный домен не согласован с видимым From. DMARC принимает согласованный SPF или DKIM в зависимости от настроенного строгого либо ослабленного режима. Для диагностики массовой доставки полезен FAQ Google по требованиям к отправителям электронной почты.

Когда TrekMail может упростить задачу

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

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

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

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

Итог: создайте продуманную SPF-схему и реже переделывайте ее

Для долговечной настройки SPF думайте не об огромном списке разрешений на основном домене, а об архитектуре. Основной домен для личной переписки, подходящие поддомены конверта для специализированных потоков, минимум include, явный -all после полной проверки отправителей и проверка DNS после публикации.

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