Проверка SPF-записи домена

Что делает SPF-запись

SPF — это список серверов, которым вы разрешили отправлять почту от имени своего домена. Список публикуется TXT-записью в DNS. Когда письмо приходит на почтовый сервер получателя, тот смотрит, с какого IP-адреса оно пришло, читает вашу SPF-запись и решает, есть ли этот адрес в списке.

Проверять запись стоит не только при первой настройке. Она ломается со временем. Подключили новый сервис рассылок и добавили ещё один include, превысив лимит; провайдер сменил диапазон адресов; кто-то создал вторую TXT-запись, не заметив первую. Во всех этих случаях в панели DNS всё выглядит нормально, а проверка на стороне получателя не проходит.

Что показывает чекер

Кроме самой записи вы увидите раскрытую цепочку, ведь за каждым include стоит SPF-запись другого домена, внутри неё могут быть свои include, и всё это считается в общий лимит. Счётчик DNS-запросов показывает, сколько из десяти разрешённых вы уже израсходовали. Именно этот показатель чаще всего оказывается причиной необъяснимых проблем с доставкой.

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

Типовые ошибки

• Две записи v=spf1. Появляются, когда SPF добавляют второй раз, не удалив первую. На выходе permerror, и SPF не работает.
• Больше десяти DNS-запросов. Обычно набегает после подключения третьего-четвёртого сервиса рассылок.
• Механизм ptr. Устарел, работает медленно, часть получателей его игнорирует.
• Отсутствие all. Без завершающего механизма запись трактуется как нейтральная и почти ничего не даёт.
• include сервиса, которым вы больше не пользуетесь. Тратит лимит и оставляет разрешение тому, кто им уже не должен обладать.

Как выглядит правильная запись

Для домена, который отправляет почту только через собственный сервер:

v=spf1 mx -all

Для Google Workspace вместе с сервисом рассылок:

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

Запись публикуется TXT-записью на корне домена (имя @). Поддомены наследуют её не автоматически. Если рассылки уходят с mail.example.com, для него нужна отдельная запись.

Что показывает раскрытая цепочка

Запись вида v=spf1 include:_spf.google.com ~all выглядит короткой, но за одним include может стоять ещё несколько уровней. Чекер разворачивает всю цепочку и показывает, сколько запросов ушло на каждую ветку и какие сети в итоге получили право отправлять от вашего имени.

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

Что означает финальный механизм

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

Где чаще всего ломается

Три поломки покрывают почти все случаи. Две записи v=spf1 на домене дают permerror, при котором проверка не проходит ни для кого. Переполненный лимит DNS-запросов приводит туда же, но само собой, когда чужой сервис дописывает include в свою запись. И include, ведущий на домен, у которого SPF-записи нет вовсе, и такой механизм ломает разбор целиком.

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

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

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

Отправитель не прошёл проверку SPF: что это значит

Формулировку «не прошёл проверку SPF» отдают почтовые сервисы, когда IP-адрес, с которого пришло письмо, не перечислен в SPF-записи домена отправителя. Получатель сделал ровно то, что ему велели: сверил адрес со списком и не нашёл совпадения.

Причин, по которым это происходит с легитимной почтой, три.

Первая и самая частая. Подключили новый сервис рассылок, CRM или биллинг, а в SPF-запись его не внесли. Сервис отправляет со своих серверов, домен их не авторизовал, проверка падает.

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

Третья. Письмо переслали. Пересылка ломает SPF по устройству протокола: конверт остаётся вашим, а отправляет уже чужой сервер. Здесь ничего не сломано, и чинить нечего.

Отличить их можно за минуту. Вставьте домен в форму выше: она раскроет цепочку include, посчитает запросы и покажет, какие сети сейчас имеют право отправлять от вашего имени. Если сервиса, которым вы пользуетесь, в списке нет, случай первый. Если счётчик у десяти, второй.

Отдельно про «для домена не настроена SPF-запись». Это не то же самое: там записи нет вовсе, а здесь она есть и не сошлась.