SPF-запись: настройка, примеры и проверка ошибок

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

С февраля 2024 года Google и Yahoo применяют усиленные требования к соответствующим категориям отправителей. Отсутствующая или неверная SPF-запись может при определенных правилах получателя вызвать SMTP 550, но не означает автоматического отказа для любого письма до окончания передачи.

Для основателя с одним доменом ошибка SPF может помешать инвестору получить презентацию. Для MSP с 500 клиентскими доменами она способна обернуться потоком понедельничных обращений «Почему я не могу написать в Gmail?». Аккуратная настройка и проверки снижают риск, но не делают любые проблемы полностью предотвратимыми.

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

Что делает SPF и чего он не делает

Sender Policy Framework (SPF) является протоколом авторизации на основе DNS, описанным в RFC 7208. Запись публикует разрешенные источники отправки для проверяемого домена. Получатель сопоставляет IP с этой политикой. Это не универсальная защита безопасности, а конкретная проверка источника.

Как проходит проверка

Получая письмо от alice@yourcompany.com, Gmail проверяет для SPF не просто видимый From. Обычно используется домен отправителя конверта MAIL FROM, который отражается в Return-Path и служит для обработки возвратов; в соответствующих случаях проверяется HELO. Получатель запрашивает SPF этого домена и сопоставляет адрес подключившегося сервера с разрешениями.

При совпадении разрешающего механизма SPF может пройти. Для прочих источников завершающее правило может дать SoftFail (~all) или Fail (-all). Эти результаты не предписывают всем получателям одинаковое принятие или отклонение.

Главное различие: From и Return-Path

Указанные в источнике 90% не являются подтвержденной общей статистикой новичков, но иллюстрируют распространенную путаницу. SPF не проверяет видимый From в Outlook или Apple Mail: проверяется соответствующий технический домен конверта.

Ловушка: Для рассылок Mailchimp может использовать свой Return-Path, например bounce-mc.us1.mailchimp.com, чтобы обрабатывать возвраты. Получатель тогда проверяет SPF Mailchimp, а не вашей видимой доменной части From. Собственная запись может быть правильной и при этом вообще не участвовать в данном пути отправки.

Вопрос выравнивания объясняет, почему нельзя ограничиваться одним SPF. Взаимодействие SPF, DKIM и DMARC разобрано в материале о порядке настройки аутентификации почты.

Почему SPF все же нужен

Даже при наличии DKIM и DMARC отсутствие SPF может нарушать применимые требования к отправителям. В соответствующих сценариях массовой отправки Microsoft может возвращать 550 5.7.515 Access Denied. Это не универсальное поведение всех получателей Microsoft. Не пропускайте проверку SPF и остальных требований.

Базовая схема с одним сервисом отправки

Если небольшой бизнес отправляет преимущественно через TrekMail, Google Workspace или Microsoft 365 и, возможно, еще один маркетинговый инструмент, нужна понятная единая SPF-политика для каждого проверяемого имени. Настройка обычно несложная, но типичная ошибка встречается часто.

Основное правило: по одному DNS-имени должна находиться ровно одна SPF-политика.

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

Из чего состоит запись

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

TrekMail для небольшого бизнеса

Источник сравнивает Google Workspace по $6-$18 на пользователя в месяц. Для десяти пользователей он приводит $720-$2,160 в год. Starter TrekMail указан как $3.50 в месяц с лимитом до 100 пользователей. Это исторические иллюстрации: цены и условия сверяйте с текущими тарифами. include:spf.trekmail.net может быть частью подходящей записи, но не заменяет учет всех источников, публикацию DNS и проверки аутентификации. Лицензирование и договорные условия сравнивайте по конкретным предложениям.

Несколько сервисов: задачи агентства

Клиенты MSP и агентств часто используют HubSpot для продаж, Zendesk для поддержки, Klaviyo для маркетинга и TrekMail для обычной корпоративной переписки. Не каждый инструмент обязательно нужно добавлять в SPF вашего домена: это зависит от фактического домена конверта и настройки сервиса.

Необходимые разрешения нужно объединить в одну политику, соблюдая существенное ограничение RFC: лимит 10 учитываемых DNS-элементов.

Лимит 10 учитываемых DNS-элементов

RFC 7208 §4.6.4 ограничивает число учитываемых механизмов и модификаторов, требующих DNS-поиска на выполняемом пути, включая вложенные, значением 10. Это не просто число DNS-пакетов. Ограничение снижает риск злоупотребления вычислением SPF и иногда затрагивает легитимные сложные схемы.

Что расходует бюджет: include:, a, mx, exists, redirect при выполнении на проверяемом пути. Устаревший механизм ptr тоже учитывается.

Что не расходует этот бюджет: ip4:, ip6:, all.

Вложенные include

Вы добавили include:bluehost.com, что выглядит как 1 элемент. В историческом примере он может включать spf.protection.outlook.com и mail.bluehost.com, поэтому один внешний элемент приводит к трем учитываемым вычислениям. У spf.protection.outlook.com могут быть собственные вложения. Актуальные значения и реально выполняемый путь нужно проверить отдельно.

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

Как проверить бюджет

Не угадывайте. Используйте подходящий CLI-инструмент или понятный визуализатор. На Mac/Linux начать можно так:

dig +short txt yourdomain.com

Затем запрашивайте домены каждого include: рекурсивно, учитывая также другие механизмы, модификаторы и фактический путь. Сам dig лишь показывает TXT, а не вычисляет SPF. Подробнее о проверке и типичных превышениях читайте в материале о лимите SPF-поиска.

Flattening или разделение по поддоменам

Если возникает риск превышения бюджета 10, что возможно, но не неизбежно для агентств, можно рассмотреть, в частности, два подхода.

Вариант 1: flattening с риском устаревания

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

Недостаток: HubSpot, Klaviyo и другие ESP могут менять IP. Зафиксированный список устаревает: через несколько месяцев новый адрес может отсутствовать, а выведенный из использования остаться разрешенным. Ранее успешная проверка не обеспечивает дальнейшую правильность.

Нужны надежное наблюдение за исходными политиками, контролируемое обновление DNS и обработка ошибок. Автоматический скрипт может помогать, но сам по себе не делает flattening безопасным. Без сопровождения это серьезный технический долг.

Вариант 2: отдельные поддомены для отправки

Альтернатива состоит в том, чтобы не объединять все сервисы в корневом домене. SPF проверяет фактический домен конверта, отраженный в Return-Path, и он может быть поддоменом.

Обязательно ли маркетингу отправлять от team@company.com, или подойдет news@marketing.company.com? Изменение только видимого адреса не меняет SPF-проверку.

Корневой домен (company.com): оставьте понятные необходимые разрешения, например для корпоративной почты и важной инфраструктуры.

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

Маркетинговый поддомен (marketing.company.com): соответствующие инструменты можно настроить здесь.

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

Отдельная проверка может получить собственный бюджет 10, только если сервис реально использует эту доменную часть конверта. marketing.company.com не гарантирует защиты репутации основного домена или писем руководителя: получатели могут объединять оценки организационного домена и общих IP. Учитывайте relaxed или strict выравнивание DMARC и сверяйте текущие значения провайдеров, не внедряйте примеры вслепую.

Другие исходные схемы есть в шаблонах настройки SPF. Подробнее о нескольких отправителях читайте в руководстве по конфигурации нескольких сервисов.

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

Нажатие «Сохранить» в редакторе DNS не завершает настройку. Следующий порядок поможет проверить публикацию и фактическое использование политики.

1. Проверить доступность DNS и кеши

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

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 обращается к публичному DNS Google вместо кеша вашего ISP. Но у Google есть собственный кеш. Успешный ответ не доказывает, что все резолверы и получатели уже видят новый вариант.

2. Проверить синтаксис

SPF требует точного синтаксиса. Частые проблемы:

• Пробел перед v=spf1
• ip4: 192.1.1.1: пробел после двоеточия недопустим
• Несколько механизмов all: первый уже совпадает, последующие механизмы на этом пути не выполняются
• Повторные include:: не обязательно синтаксическая ошибка, но при выполнении они могут расходовать бюджет впустую

Проверяйте синтаксис перед завершением настройки. Доступный по текущим условиям DNS-мастер TrekMail может выдавать подсказки, но не заменяет полную проверку.

3. Проверить пустые ответы

RFC 7208 рекомендует еще одно ограничение: не более 2 DNS-поисков без результата, то есть NXDOMAIN или успешных ответов без нужных данных. Реализация может настраивать эту границу; учитывайте конкретный тип ошибки.

Опечатка include:spf.trekmaill.net с лишней «l» может дать 1 пустой поиск. При этом include без действительной SPF-политики способен сразу вызвать PermError независимо от общего числа пустых ответов. Две опечатки не означают превышения рекомендованной границы сами по себе.

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

4. Проверить заголовки реального письма

Отправьте письмо в контролируемый Gmail, откройте меню с тремя точками и «Показать оригинал». Найдите Authentication-Results, добавленный доверенным принимающим сервером. Пример результата:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral или spf=softfail следует оценить относительно ожидаемой политики; они не всегда означают ошибку. Сопоставьте IP, проверенный домен и разрешения. Материал проверка состояния DNS помогает проверить DNS; дополнительно анализируйте доверенные заголовки.

Типичные ошибки и последствия

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

1. SPF при пересылке

SPF проверяет IP подключившегося отправляющего сервера. Это одновременно ограничение его архитектуры.

Алиса пишет Бобу, а Боб пересылает Чарли. Сервер Чарли видит IP Боба вместо Алисы. Если сохранен исходный отправитель конверта и новый IP не разрешен его политикой, SPF может не пройти, хотя исходное письмо легитимно.

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

Возможности DKIM и SRS разобраны в материале пересылка доменной почты и доставляемость. Они не гарантируют успех для всех вариантов пересылки.

2. Механизм ptr

В начале 2000-х механизм SPF ptr для обратного DNS был распространен:

v=spf1 ptr -all

Не используйте его в новых настройках. RFC не рекомендует ptr из-за нагрузки и ненадежности. Это не означает универсального штрафа Gmail или игнорирования всей записи. Заменяйте унаследованный ptr подходящими разрешениями после учета источников и тестов. Требования к PTR отправляющего IP для почтового транспорта остаются отдельной задачей.

3. Опасность +all

Встречается и такая проблемная запись:

v=spf1 include:spf.google.com +all

Значение квалификаторов:

• -all = Fail для источников, не совпавших с предыдущими правилами; обработка зависит от получателя
• ~all = SoftFail для оставшихся источников, а не обязательное принятие с меткой
• +all = Pass для любого оставшегося источника

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

4. Неподходящий Return-Path внешнего сервиса

Без собственного Return-Path маркетинговые инструменты часто используют домен возвратов провайдера. Tracking-домен не обязательно является тем же самым. SPF вашего домена в таком конверте не вычисляется. SPF провайдера может пройти, но не быть выровнен с видимым From. Однако DMARC способен пройти через другую действительную выровненную подпись DKIM.

Если ESP поддерживает собственный поддомен возвратов вроде bounce.yourcompany.com, настройте его по документации. Relaxed может допускать общий организационный домен, strict требует точного совпадения. Подробнее: выравнивание DMARC и репутация домена.

Как оценивать генераторы

Генераторы SPF очень разные. Одни делают проверку понятнее, другие могут выдать неподходящий результат.

Полезные инструменты

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

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

Результаты, требующие осторожности

Мастера настройки иногда предлагают ?all, то есть Neutral. Это не положительное разрешение оставшихся источников, но не автоматически неправильная политика. После учета отправителей выбирайте подходящее завершение, например -all либо временно ~all, а не переносите предложенный вариант без проверки.

Генераторы разделенных записей: отдельная строка TXT имеет лимит 255 байт. Длинный SPF можно разделить на несколько строк в кавычках внутри одной записи, но не на две самостоятельные SPF TXT-записи:

• Предполагаемая схема: "v=spf1 include:a..." "include:b... -all" показывает две строки одной записи; в реальном содержимом нужен пробел на границе
• Неверно: две отдельные SPF TXT-записи приводят к PermError при проверке

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

Критерии выбора и порядок настройки есть в руководстве по SPF-генераторам.

Стандартизация с TrekMail

Большие офисные пакеты не являются плохими продуктами сами по себе. Но набор функций и лицензия на пользователя подходят не каждому клиенту. Сравнивайте реально нужные возможности и условия договора.

Для подходящих потоков TrekMail можно рассматривать такую иллюстративную запись. Перед внедрением сверяйте значения и другие источники отправки:

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

Она полна только тогда, когда правильно разрешает все нужные источники проверяемого домена. Управляемый SMTP может сопровождать IP, PTR и доступные процессы обратной связи, а BYO SMTP имеет другие границы ответственности. Учет отправителей, допустимые объемы, база и наблюдение все равно нужны. Авторизация не гарантирует доставку.

Для MSP с 50 одинаково настроенными доменами 50 одинаковых SPF-записей могут упрощать работу. Тарифы и конфигурации клиентов все равно проверяют. Для нового домена может подойти строка, использованная сотню раз, если его настоящие источники совпадают. Стандартизация не отменяет индивидуальной проверки.

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

Надежный подход к SPF

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

Краткий план действий:

1. Проверьте сейчас. Выполните dig +short txt yourdomain.com и посчитайте SPF-политики по имени, а не все TXT. Более одной SPF-политики дает PermError при SPF-проверке.
2. Объедините разрешения. Нужна одна SPF TXT-запись с необходимыми источниками; несколько строк внутри нее допустимы.
3. Посчитайте бюджет. Используйте подходящий анализатор. При более чем 10 учитываемых элементах реальные домены конверта на поддоменах могут быть альтернативой сложному flattening.
4. Выбирайте -all осознанно. Переход с ~all требует учета отправителей, тестов и решения о политике. +all нужно оперативно исследовать и исправлять.
5. Проверьте Return-Path. Собственный домен возвратов Mailchimp или HubSpot может обеспечить SPF-выравнивание. Для DMARC альтернативно достаточно действительного выровненного DKIM.
6. Не ограничивайтесь SPF. Пересылка может нарушать SPF и изменять DKIM. Используйте и проверяйте все три метода: SPF, DKIM и DMARC.

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

Управляйте DNS последовательно. Попробуйте TrekMail бесплатно: сверяйте актуальные условия, фиксированные тарифы и поддержку SPF, DKIM и DMARC для ваших доменов.