С одним отправителем настройка SPF работает без проблем. Затем вы подключаете Google Workspace, Mailchimp, Zendesk и API для транзакционных писем, а Microsoft начинает возвращать 550 5.7.515. Аккуратная при запуске запись превысила лимит 10 DNS-запросов, и исходящие сообщения больше не проходят аутентификацию надёжно.
В этом и заключается ловушка. В протоколе SPF есть жёсткий потолок, которого многие команды достигают уже после подключения третьего или четвёртого почтового сервиса. Обычное решение, вставить ещё один include:, перестаёт работать именно тогда, когда особенно нужно. Основы синтаксиса приведены в руководстве по SPF-записи для почты. Здесь речь об архитектуре: как поддержать несколько отправителей, переживать смену сервисов и не переписывать запись каждый квартал.
Почему SPF ломается при нескольких отправителях
Согласно RFC 7208, проверка одной SPF-записи может потребовать не более 10 DNS-запросов. Каждый механизм include, a, mx, exists и redirect учитывается рекурсивно. Если include поставщика содержит ещё три include, они тоже расходуют бюджет. При 11 запросах получатель может вернуть PermError и отклонить письмо.
Сценарий обычно одинаков. Сначала есть два include и большой запас. Маркетинг добавляет HubSpot, поддержка Freshdesk, разработчики SendGrid для уведомлений. Цепочки оказываются глубже документации. В результате получается 12 запросов, а Google отвечает 550 5.7.26 на каждое сообщение.
| Механизм | Требует запрос? | Примечание |
|---|---|---|
include: | Да, включая вложенные | Стандартно для поставщиков, глубину трудно предсказать |
ip4: / ip6: | Нет | Используйте для контролируемых статических отправителей |
mx | Да | Часто лишний, по возможности замените на ip4 |
a | Да | Неэффективен для SPF, предпочтительнее ip4 |
ptr | Да | Устарел, не используйте |
redirect | Да | Переносит проверку на запись другого домена |
-all / ~all | Нет | Завершает политику, всегда нужен один |
Арифметика проста, но остаётся невидимой до сбоя. Поэтому настройку нескольких отправителей следует начинать с архитектуры, а не с копирования строк.
Проверьте SPF до добавления новых записей
Сначала удалите то, чего там быть не должно. Во многих доменах остаются include давно отключённых сервисов, и каждый расходует бюджет запросов. Сначала очистка, затем расширение.
Проверьте опубликованные данные:
dig txt yourdomain.com +shortЗатем проследите глубину каждого include:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortСопоставьте результат со сводными отчётами DMARC. Если с IP-адресов поставщика действительно не поступает трафик, его include является лишним и после проверки может быть удалён.
Три быстрых улучшения во время аудита:
- Замените
mxфактическим IP черезip4:, это экономит один запрос. - Удалите include сервисов, которыми больше не пользуетесь.
- Найдите дубли SPF. Две TXT-записи, начинающиеся с
v=spf1на одном домене, сразу вызывают PermError.
Этого часто достаточно, чтобы освободить 2-3 запроса. Подробности есть в руководстве по настройке SPF.
Разделение по поддоменам: масштабируемая архитектура SPF
Надёжный способ обслуживать несколько отправителей без превышения 10 запросов заключается в разделении по поддоменам. SPF проверяет домен Return-Path, а не видимый заголовок From. Перенесите некорпоративные потоки на поддомены, и каждый получит собственный бюджет из 10 запросов.
Схема выглядит так:
Корневой домен, только личная рабочая переписка
Оставьте корневой домен простым. Здесь должен быть только основной почтовый провайдер.
v=spf1 include:spf.trekmail.net -allОдин include, один запрос. Новый маркетинговый инструмент не сломает почту руководителя.
Маркетинговый поддомен, кампании и рассылки
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot и Mailchimp расходуют бюджет news.example.com, а не корневого домена. При ограничении этого поддомена корпоративная почта может продолжить работу, хотя связь репутации зависит от получателя.
Поддомен поддержки, системы заявок
; help.example.com
v=spf1 include:mail.zendesk.com -allТранзакционный поддомен, уведомления и квитанции
; alerts.example.com
v=spf1 include:amazonses.com -allКогда Zendesk отправляет от имени support@help.example.com, получатель проверяет DNS домена help.example.com. SPF корневого домена при этой проверке не используется. В этом смысл разделения.
| Старый подход | Новый подход |
|---|---|
| Все отправители в одной корневой SPF-записи | В корне только основной почтовый провайдер |
| Изменение одного сервиса может нарушить всю отправку | Сбой ограничен затронутым поддоменом |
| Общий бюджет запросов для всех | У каждого поддомена свой бюджет из 10 запросов |
| Перезапись SPF при каждом новом инструменте | Архитектура лучше переносит смену поставщиков |
Уплощение SPF как последнее средство
Если все письма обязательно должны исходить с голого домена и поддомены запрещены, остаётся уплощение SPF. Include поставщиков раскрываются в обычные IP-адреса и перечисляются как механизмы ip4:, не требующие запросов. Метод работает, но создаёт проблему обслуживания.
Главный риск заключается в устаревании. SaaS-провайдеры регулярно меняют IP. Если SendGrid завтра добавит новый диапазон, а уплощённая запись содержит вчерашние адреса, SPF начнёт давать сбой. Не делайте это вручную, если не готовы проверять ежедневно. Используйте надёжный динамический SPF-сервис, который отслеживает IP поставщиков и контролируемо обновляет TXT.
Уплощение является обходным решением, а не хорошей архитектурой. Сначала используйте разделение по поддоменам и прибегайте к нему только при отсутствии альтернатив.
Проверьте работу SPF
После каждого изменения проверяйте фактический ответ публичного DNS. Не полагайтесь только на панели регистратора, кэшированные страницы или зелёные отметки поставщика. Запрашивайте домен напрямую и убеждайтесь, что для каждого имени есть ровно одна действительная SPF-запись.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortНа каждом имени нужна одна TXT-запись с v=spf1. Не две и не актуальная запись вместе с остатком миграции двухлетней давности.
Затем отправьте тестовое письмо в Gmail, откройте меню с тремя точками, выберите просмотр оригинала и найдите:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSFAIL или SOFTFAIL указывает на проблему, которую нужно исправить до большой отправки. При этом SPF не гарантирует доставку во входящие. Более широкая картина описана в материале о сигналах репутации отправителя.
Как TrekMail упрощает SPF для нескольких доменов
Настраивать один домен неудобно, а 50 клиентских доменов с разными поставщиками, DNS-сервисами и накопленными ошибками требует гораздо больше времени. TrekMail сохраняет собственный SPF-компонент небольшим и предсказуемым, оставляя место другим отправителям.
Основной include имеет вид include:spf.trekmail.net. Это один запрос без вложенных redirect и непредсказуемых цепочек по текущей архитектуре. Microsoft 365 может использовать 2-3 запроса через внутренние перенаправления, а Google Workspace может различаться по регионам. Фактический результат следует проверять напрямую.
Для основателя это означает простую схему даже после добавления маркетингового сервиса, для команды меньше ошибок DNS при подключении. Агентство получает повторяемый шаблон: добавить TrekMail include, разнести остальных поставщиков по поддоменам и значительно снизить риск превышения. Регулярный аудит всё равно нужен. Общая архитектура описана в статье о мультидоменном почтовом хостинге.
Проверка статуса DNS в TrekMail также отмечает конфликты SPF в панели, помогая увидеть проблему до производственного сбоя. Полная настройка приведена в документации об обязательных DNS-записях.
Заключение: один раз правильно спроектируйте SPF
Хорошая настройка SPF начинается с архитектуры, а не синтаксиса. Удалите неактуальные include. Разделите отправителей по поддоменам, чтобы каждый поток получил бюджет из 10 запросов. Сохраните корневой домен простым: один почтовый провайдер, один include и один -all. Проверяйте через dig, а не только по панели.
Для одного или ста доменов TrekMail, согласно текущему предложению, предоставляет мультидоменный хостинг по фиксированной цене, одну понятную SPF-вставку, общий пул хранилища и проверку DNS. Nano поддерживает 10 доменов с собственным SMTP, без карты и бесплатно. Платные тарифы начинаются со Starter за $3.50/mo с управляемым SMTP и 14-дневным пробным периодом, карта обязательна. Цены и условия меняются; актуальные сведения смотрите на trekmail.net/pricing.
