Пример записи SPF: шаблоны для любой схемы отправки

Почти каждый найденный в интернете пример записи SPF либо чрезмерно упрощен, либо перегружен редкими исключениями. На практике нужны готовые шаблоны для трех вариантов инфраструктуры, охватывающих 95% доменов. Одна запись TXT начинается с v=spf1 и заканчивается -all. Ошибка может привести к тому, что получатели вроде Google и Microsoft отклонят письмо с неочевидным сообщением SMTP, например 550 5.7.26.

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

Шаблоны SPF для разных схем отправки

Хороший пример записи SPF должен соответствовать реальной инфраструктуре, а не гипотетической схеме с шестью SaaS-сервисами. Три сценария ниже охватывают домены с одним отправителем, гибридные схемы и сложные конфигурации с несколькими отправителями. Каждый шаблон готов к публикации как запись DNS TXT в корневом домене.

Сценарий 1: один отправитель (один поставщик обслуживает все)

Вся почта отправляется через одну платформу. Это наиболее простая схема, к которой разумно стремиться.

TrekMail (тариф Starter, Pro или Agency):

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

Google Workspace:

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

Microsoft 365:

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

Один include и один -all. Этого достаточно. Используется 1 из 10 разрешенных DNS-запросов.

Сценарий 2: гибридный отправитель (почтовый ящик + транзакционный сервис)

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

TrekMail Free + Amazon SES:

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp:

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

Два включения означают два запроса, не считая вложенных запросов поставщиков. Это все еще укладывается в лимит.

Сценарий 3: несколько отправителей (повышенный риск)

Этот пример охватывает корпоративную почту, CRM, службу поддержки и HR-платформу, авторизованные на одном домене. Именно здесь часто возникают проблемы.

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

Формально здесь четыре включения, но каждое include может содержать вложенные запросы. Только HubSpot способен добавить цепочку из 3-4 запросов. Если общая цепочка превышает 10, получатели возвращают PermError и считают письмо неаутентифицированным. При такой конфигурации обязательно прочитайте следующий раздел о лимите запросов.

Как устроен синтаксис SPF

SPF представляет собой белый список на основе DNS, определенный в RFC 7208. Он сообщает принимающим серверам, с каких IP-адресов разрешено отправлять почту от имени домена. В реальной записи SPF встречаются следующие компоненты:

Полная инструкция, включая средства проверки и риски выравнивания, доступна в нашем руководстве по настройке SPF.

Лимит в 10 запросов: где ломаются записи SPF

RFC 7208 ограничивает одну проверку SPF 10 DNS-запросами. Ограничение защищает от атак типа «отказ в обслуживании», но часто становится препятствием для растущей компании.

Каждый из этих механизмов расходует 1 запрос: include, a, mx, redirect, exists, ptr (устарел, не используйте).

Эти механизмы не расходуют запросы: ip4, ip6, all.

Важно учитывать рекурсивность. Добавление include:bluehost.com расходует 1 запрос. Если собственная запись SPF Bluehost содержит include:spf.protection.outlook.com, вложенный запрос также учитывается в вашем лимите. Цепочка из 3-4 поставщиков с вложенными включениями уже может превысить 10.

Лимит пустых запросов, о котором часто забывают

RFC 7208 §11.1 вводит дополнительный лимит: не более 2 DNS-запросов без результата, то есть NXDOMAIN или пустого ответа. Опечатка include:spf.trekmaill.net с лишней «l» дает 1 пустой запрос. Две опечатки приводят к ошибке всей записи.

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

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

Разделите отправителей по поддоменам

Не размещайте все инструменты на корневом домене. Каждый поддомен получает собственный лимит из 10 запросов.

• Корпоративная почта: @company.com: только основной поставщик, например TrekMail или Google
• Маркетинг: @news.company.com: Mailchimp, HubSpot
• Поддержка: @support.company.com: Zendesk, Freshdesk

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

Замените DNS-запросы механизмами IP

Если почтовый сервер имеет статический адрес, укажите IP напрямую вместо механизма a.

Расходует 1 запрос:

v=spf1 a:mail.company.com -all

Расходует 0 запросов:

v=spf1 ip4:192.0.2.55 -all

Каждый подставленный механизм ip4 или ip6 освобождает запрос для SaaS-инструментов, которым требуется include.

Критические ошибки SPF, ухудшающие доставку

Ошибка 1: две записи SPF на одном домене

Это наиболее распространенная ошибка в примерах SPF. Нельзя публиковать на одном домене две записи TXT, начинающиеся с v=spf1. Обе завершатся ошибкой PermError.

Неверно:

TXT: v=spf1 include:_spf.google.com -all
TXT: v=spf1 include:spf.trekmail.net -all

Верно:

TXT: v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Объедините их. Всегда должна быть одна запись. Подробное объяснение и полный разбор примера приведены в статье о записи SPF для электронной почты. Наше руководство по настройке SPF описывает весь процесс с нуля.

Ошибка 2: использование +all

Никогда не используйте +all. Он разрешает все: вы сообщаете каждому почтовому серверу, что кто угодно может отправлять письма от имени вашего домена. Всегда используйте -all (HardFail).

Ошибка 3: расчет только на SPF при пересылке

SPF сверяет IP отправителя с доменом отправителя конверта. При пересылке IP меняется, а отправитель конверта остается прежним, поэтому проверка SPF завершается ошибкой.

Для этого существует DKIM: он подписывает содержимое сообщения, и подпись может сохраниться при пересылке. Если вы зависите от списков рассылки или пересылки почты, одного SPF недостаточно. Нужен DKIM и желательно политика DMARC, принимающая любой из этих вариантов. Еще одна часть решения для пересылки, Sender Rewriting Scheme (SRS), переписывает отправителя конверта, чтобы SPF проходил на следующем узле.

Как TrekMail упрощает управление SPF

Управлять DNS-записями одного домена утомительно. На 50 или 100 клиентских доменах ошибки быстро накапливаются.

Подход TrekMail зависит от тарифа:

• Free ($0/mo, банковская карта не требуется): собственный SMTP. Вы добавляете запись SPF своего поставщика. Полный контроль без расходов.
• Starter ($3.50/mo) и Pro ($10/mo): управляемый SMTP. Добавьте include:spf.trekmail.net, а TrekMail будет обслуживать базовую IP-инфраструктуру. При смене серверов ваш DNS остается без изменений.
• Agency (.25/mo): тот же управляемый SMTP, рассчитанный на несколько доменов. Стандартизированный шаблон SPF применяется ко всем клиентским доменам. Один include оставляет достаточный запас запросов для других инструментов клиентов.

Все платные тарифы включают бесплатный пробный период на 14 дней, для которого требуется карта. Встроенный мастер SPF/DKIM/DMARC пошагово проводит через настройку DNS и отмечает ошибки до ввода конфигурации в эксплуатацию.

Контрольный список SPF

Все примеры в этом руководстве следуют одним принципам. Хороший пример SPF несложен, если не добавлять лишнего. Последовательность проверки:

1. Посчитайте запросы. Выполните dig TXT yourdomain.com или воспользуйтесь онлайн-валидатором SPF. Если их больше 10, проверка уже завершается ошибкой.
2. Объедините дублирующиеся записи. Один домен, одна запись v=spf1.
3. Разделите требовательных отправителей. Перенесите инструменты маркетинга и поддержки на поддомены.
4. Замените механизмы a на ip4 для статических серверов.
5. Завершайте запись -all. Без исключений.

Если вы хотите полностью обойтись без редактирования DNS, бесплатный тариф TrekMail предоставляет рабочую почтовую систему без первоначальных расходов. На платных тарифах SPF-инфраструктура обслуживается за вас.