Как SPF влияет на результат кампании
Почтовые провайдеры — Яндекс, Mail.ru, Google — проверяют SPF одной из первых. Нет записи или IP отправителя в ней не значится — письмо получает минус к репутации до чтения текста. На холодном объёме это критично: фильтр и так относится к незнакомому отправителю настороженно, а сломанная авторизация превращает настороженность в отказ.
По нашим кампаниям: при настроенных SPF, DKIM и DMARC и валидной базе 97,7% адресов приняли письмо, отскок — 2,3%. Это потолок того, что даёт техническая настройка: она не делает рассылку хорошей, она убирает причины, по которым хорошую рассылку не доставят. Дальше результат решают база, оффер и доставляемость как сумма факторов.
Проверка SPF происходит на уровне сервера, получатель её не видит. Но видит последствия: письмо во «Входящих» или письмо в «Спаме». Поэтому настройку DNS ведём первым шагом, ещё до регистрации ящиков — регламент описан в услуге доставляемости.
Как выглядит запись и что проверить
SPF публикуется одной TXT-записью в DNS домена. Типовой вид: v=spf1 include:_spf.yandex.net ~all. Начало v=spf1 — версия протокола. Середина — механизмы: ip4 для конкретных адресов, include для подключения списка провайдера почты. Финал — правило для всех, кто не совпал: ~all (мягкий отказ, письмо пометят) или -all (жёсткий отказ, письмо отклонят).
Два жёстких ограничения стандарта. Первое: запись на домен должна быть одна — две TXT с v=spf1 дают ошибку PermError, и проверка считается не пройденной. Второе: суммарно не более 10 DNS-запросов на проверку — каждый include тянет за собой вложенные запросы, и при переполнении проверка обрывается с той же ошибкой.
- Определите все сервисы, которые шлют почту от имени домена: корпоративная почта, система учёта клиентов, рассыльщик, счёт на оплату из биллинга.
- Соберите их механизмы в одну запись: ip4 для своих серверов, include для сервисов.
- Выберите финал: ~all на время отладки, -all когда уверены, что всех отправителей перечислили.
- Проверьте запись после публикации — опечатка в синтаксисе ломает её целиком. Пошаговый регламент — в гайде настройка SPF, DKIM и DMARC, быстрая сверка — в инструменте проверки DNS домена.
Типовые ошибки при настройке
- Две записи вместо одной. Добавили рассыльщик, не тронув старую TXT. Оба сервиса формально прописаны, фактически проверка не проходит вообще.
- Жёсткий -all с неполным списком. Про биллинг или форму на сайте вспомнили, когда клиенты перестали получать счета.
- Лавина include. Каждый сервис просит свой include, у каждого внутри свои вложенные. Лимит в 10 запросов исчерпан, запись не работает.
- Рассылка с основного домена. Холодный объём с корпоративного домена подставляет под фильтры всю рабочую почту компании. Под кампании делегируют отдельные домены — это база прогрева доменов и ящиков.
- Запись настроена и забыта. Сменили почтового провайдера, старый include остался, новый не добавили.
Когда одной SPF мало
SPF — один из трёх механизмов авторизации, а не вся система. DKIM подписывает письмо криптографическим ключом и подтверждает, что текст не меняли в пути. DMARC связывает обе проверки и говорит серверу получателя, что делать с письмом, которое их не прошло. Провайдеры смотрят на связку: одна SPF без подписи и политики выглядит наполовину собранной схемой.
Есть и честные пределы. При пересылке письма дальше (форвардинг внутри компании получателя) SPF ломается технически: пересылающий сервер в записи не значится — выручает DKIM, подпись пересылку переживает. И никакая запись не компенсирует репутацию: молодой домен без истории, объём с первого дня, жалобы на спам — и корректный SPF не удержит письма во «Входящих». Репутацию нарабатывают прогревом и дисциплиной объёмов, следствие смотрите по метрике отказа доставки.