Настройка SPF-записи: собрать и добавить в DNS

SPF-запись не настроена: что это значит

Надпись «для домена не настроена SPF-запись» означает, что в DNS домена нет TXT-записи, начинающейся с v=spf1. Получатель, проверяя письмо, не находит списка серверов, которым разрешено отправлять от вашего имени, и оценивает отправителя по остальным признакам.

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

Чинится это одной записью в зоне домена. Тип TXT, имя @ или сам домен, значение начинается с v=spf1 и заканчивается механизмом all. Поддомены запись не наследуют: если рассылки уходят с mail.example.com, для него нужна своя.

Готовые записи для типовых случаев

Для домена, вся почта которого идёт через Яндекс 360, достаточно одной строки: v=spf1 redirect=_spf.yandex.net. Механизм redirect передаёт проверку целиком на сторону Яндекса, и добавлять к нему ничего не нужно.

Для Mail.ru для бизнеса запись выглядит как v=spf1 redirect=_spf.mail.ru. Логика та же.

Если почта уходит и через почтовый сервис, и через свой сервер, redirect не подойдёт, потому что он не сочетается с другими механизмами. Тогда собирают обычную запись: v=spf1 include:_spf.yandex.net ip4:203.0.113.10 ~all, где include подставляет чужой список серверов, а ip4 добавляет ваш собственный адрес.

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

Как собрать запись правильно

Главное правило: перечислить всех, кто отправляет письма от вашего имени. Забытый сервис — это письма, которые перестанут проходить проверку. Обычно вспоминают почту для домена и сервис рассылок, а забывают транзакционные письма из приложения, уведомления от CRM и службу поддержки, которая отвечает клиентам со своего адреса.

Второе правило: не оставлять лишнего. Каждый include, оставшийся от сервиса, которым вы больше не пользуетесь, тратит один DNS-запрос из десяти и сохраняет разрешение тому, у кого его быть не должно.

Про лимит в десять запросов

RFC 7208 разрешает не более десяти DNS-запросов на проверку одной записи. Тратят запрос механизмы include, a, mx, ptr, exists и модификатор redirect. Механизмы ip4 и ip6 бесплатны, они не требуют обращения к DNS.

При превышении лимита проверка возвращает permerror. Для получателя это равносильно провалу SPF, причём запись при этом выглядит совершенно нормально. Если счётчик показывает восемь или девять, запас исчерпан: подключение ещё одного сервиса сломает проверку.

Какую политику ставить

• -all — всё, что не перечислено, отклоняется. Рекомендуемое конечное состояние.
• ~all — помечается подозрительным, но доставляется. Разумный вариант на время настройки.
• ?all — не даёт получателю никакого сигнала, смысла в такой записи почти нет.
• +all — разрешает отправку кому угодно. Генератор такой вариант не предлагает намеренно: это хуже, чем отсутствие SPF.

Лимит в десять DNS-запросов

Главное ограничение SPF не в длине записи, а в количестве DNS-запросов при её раскрытии. Механизмы include, a, mx, ptr, exists и модификатор redirect тратят по одному, и считаются они рекурсивно: внутри чужого include может оказаться ещё три.

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

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

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

SPF проверяет адрес из конверта письма, то есть Return-Path, а не то, что видит получатель в поле From. Эти адреса могут различаться, и подделка видимого отправителя SPF не ловит: письмо с чужим From спокойно пройдёт проверку, если конверт принадлежит отправителю.

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

Одна запись на домен

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

Правильный способ состоит в том, чтобы объединить всё в одну строку: один v=spf1, все нужные include подряд, один завершающий механизм. Поддомены при этом наследуют не запись родителя, а собственную: news.example.com без своей SPF-записи считается доменом без SPF.

Что делать при переполнении лимита

• Убрать неиспользуемое. Сервисы, которыми перестали пользоваться, остаются в записи годами и тратят запросы.
• Развести отправку по поддоменам: транзакционные письма с одного, маркетинговые с другого. У каждого своя запись и свой лимит.
• Заменить include на явные ip4, если провайдер публикует стабильный список адресов. Это и есть SPF-flattening работает, но требует следить за изменениями на стороне провайдера.