Настройка SPF для email-рассылок

1. Что такое SPF запись и как она работает

SPF (Sender Policy Framework) это механизм аутентификации отправителя, описанный в RFC 7208. Владелец домена публикует в DNS TXT запись со списком разрешенных источников отправки. Когда почтовый сервер получателя принимает письмо, он запрашивает SPF запись домена из адреса Return-Path (MAIL FROM) и сверяет IP отправляющего сервера с этим списком.

Результат проверки принимает одно из значений: pass, fail, softfail, neutral, none, temperror, permerror. Они видны в заголовках письма в поле Authentication-Results или Received-SPF. Важно понимать: SPF проверяет не видимый адрес From:, который показывается получателю, а технический адрес Return-Path, используемый для возвратов. Для защиты видимого адреса нужна DMARC с выравниванием доменов.

Для рассылок SPF имеет практическое значение: Gmail, Mail.ru, Яндекс и Outlook учитывают результат SPF при фильтрации. Google требует от всех отправителей настроить SPF или DKIM, а от массовых отправителей (от 5000 писем в сутки на Gmail) - SPF и DKIM вместе, а также DMARC.

2. Синтаксис и правильная SPF запись для рассылки

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

Пример правильной SPF записи для домена, где корпоративная почта живет в Google Workspace, а рассылки отправляет внешний ESP:

v=spf1 include:_spf.google.com include:spf.esp-example.com -all

Ключевое правило: SPF запись на домен должна быть ровно одна. Если опубликовать две TXT записи, начинающиеся с v=spf1, проверка вернет permerror и SPF перестанет работать полностью.

3. Как настроить SPF запись: пошагово

Шаг 1. Составьте список всех источников отправки от имени домена: корпоративная почта, ESP для рассылок, транзакционный сервис, CRM, тикет-система, сайт с формами. Частый провал: настроили SPF под рассылки, забыли про транзакционные письма, и подтверждения заказов начали получать fail.

Шаг 2. Для каждого сервиса найдите в его официальной документации точное значение include или диапазоны IP. Не угадывайте адреса по памяти: у крупных провайдеров include меняется, и актуальным источником является только их справка.

Шаг 3. Сформируйте одну строку v=spf1 и опубликуйте ее как TXT запись для домена в панели DNS хостинга или регистратора. Имя записи: @ или имя домена, тип: TXT, значение: ваша строка.

Шаг 4. Дождитесь обновления DNS (зависит от TTL записи, обычно от нескольких минут до нескольких часов) и проверьте результат командами dig TXT example.com или nslookup -type=TXT example.com.

Шаг 5. Отправьте тестовое письмо с каждого источника и проверьте заголовки: в Authentication-Results должно быть spf=pass.

4. SPF include: как добавить несколько сервисов

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

Пример записи с несколькими сервисами: корпоративная почта в Google, рассылки через ESP, транзакционные письма через отдельный сервис с выделенным IP:

v=spf1 include:_spf.google.com include:spf.esp-example.com ip4:198.51.100.25 -all

Для Google Workspace официальная справка предписывает include:_spf.google.com. Адреса include для ESP берите только из документации конкретного сервиса: у одних это единый include на всех клиентов, у других персональный домен или диапазоны IP.

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

5. ~all и -all: в чем отличие и что выбрать

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

На практике: ~all применяют на этапе внедрения, пока не уверены, что все легитимные источники перечислены. -all дает более строгую политику и применяется, когда список отправителей стабилен. Важный нюанс: сам по себе выбор между fail и softfail редко решает судьбу письма, потому что окончательное решение принимает DMARC политика и фильтры получателя. Грубая ошибка это ?all или отсутствие all вовсе.

Не путайте квалификаторы с результатами проверки в заголовках: ~all при несовпадении даст spf=softfail, -all даст spf=fail. Разбор этих статусов и их влияния на доставку есть в статье про SPF fail и softfail.

6. SPF для поддомена и Return-Path

SPF записи не наследуются: запись на example.com не действует на mail.example.com. Если вы отправляете с поддомена (типичная схема: маркетинг с promo.example.com, транзакционные с noreply.example.com), каждому поддомену нужна своя TXT запись.

Отдельная история это Return-Path. Многие ESP отправляют письма, где Return-Path указывает на их собственный домен (например, bounce.esp-example.com). В этом случае SPF проверяется по домену ESP, а не по вашему, и ваша запись вообще не участвует в проверке. Для доставляемости это обычно нормально, но для DMARC выравнивания по SPF такого письма не будет: домен Return-Path не совпадает с доменом From:. Поэтому многие платформы предлагают настроить собственный Return-Path (custom return path) через CNAME на поддомене вашего домена.

Практический вывод: для массовых рассылок опорным механизмом аутентификации делайте DKIM подпись вашим доменом, а SPF настраивайте как дополнительный слой и как требование для приема у крупных провайдеров. Статистика Postmaster привязана к домену d= в DKIM подписи, поэтому именно подпись вашим доменом дает видимость репутации в кабинетах.

7. Типичные ошибки при настройке SPF

Дерево диагностики ниже помогает быстро найти проблему, когда spf=pass не появляется:

1. В DNS две TXT записи с v=spf1. Результат: permerror. Решение: объединить в одну строку.

2. Запись опубликована не на том домене. SPF проверяется для домена Return-Path, а запись добавили на основной домен, хотя письма идут с поддомена. Решение: опубликовать запись на нужном поддомене.

3. IP или include сервиса не добавлен. Типично после смены ESP или подключения нового сервиса. Результат: fail или softfail. Решение: дописать механизм в существующую запись.

4. Превышен лимит 10 DNS запросов. Результат: permerror. Проверяется подсчетом include, a, mx в цепочке. Решение: заменить часть include на ip4, убрать mx и a, где они не нужны.

5. Опечатка в синтаксисе: лишние пробелы в начале, кавычки, v=spf1 написан с ошибкой. Результат: запись игнорируется (none). Решение: скопировать проверенный шаблон.

6. DNS еще не обновился. Решение: проверить через dig с указанием публичного резолвера, например dig TXT example.com @8.8.8.8, и дождаться TTL.

8. Как проверить результат

Первый уровень проверки: DNS. Команда dig TXT example.com должна вернуть ровно одну запись, начинающуюся с v=spf1. Для поддомена проверяйте именно поддомен.

Второй уровень: реальное письмо. Отправьте письмо с каждого источника на адрес в Gmail и откройте оригинал письма (Show original). В блоке Authentication-Results должны быть spf=pass с правильным доменом, а также dkim=pass и dmarc=pass. Разобрать заголовки быстрее помогает бесплатный анализатор заголовков письма: вставьте полный текст заголовков, и разбор выполнится в браузере.

Третий уровень: мониторинг на постоянной основе. SPF ломается незаметно: сотрудник меняет DNS, сервис обновляет инфраструктуру, кто-то добавляет вторую запись. PostmastersTool проверяет DNS доменов (SPF, DKIM, DMARC, MX, черные списки), собирает долю прохождения SPF из Google Postmaster Tools и данные Mail.ru Postmaster, а при пересечении порогов присылает уведомление в Telegram или на почту. Это позволяет увидеть проблему в день появления, а не после жалоб на спам.