Проверка синтаксиса SPF-записи до публикации

Когда это пригодится

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

Что вставлять

Только значение TXT-записи, строку, начинающуюся с v=spf1. Имя записи, тип и TTL из панели DNS копировать не нужно. Внешние кавычки мы уберём сами, если они попадут вместе с текстом.

Что проверяет валидатор

Разбор идёт по RFC 7208, а не по списку типовых опечаток, поэтому находятся и редкие случаи:

• Версия. Запись обязана начинаться с v=spf1, и такая запись у домена должна быть ровно одна: две записи — это ошибка permerror, при которой проверка не проходит ни для одного отправителя.
• Счётчик DNS-запросов. Механизмы include, a, mx, ptr и exists и модификатор redirect тратят лимит в десять запросов, причём рекурсивно: вложенные include чужих сервисов считаются тоже.
• Финальный механизм. -all, ~all или ?all в конце: без него запись ничего не запрещает, а всё после all просто не выполняется.
• Синтаксис адресов. Маски вроде ip4:192.0.2.0/33, IPv6 в механизме ip4, лишние пробелы внутри значения.

Ошибки, которые встречаются чаще всего

Первая это переполнение лимита после подключения очередного сервиса: рассылки, CRM и служба поддержки приносят по два-три вложенных include каждая. Вторая это ptr, который давно объявлен устаревшим и которым часть провайдеров вообще пренебрегает. Третья это попытка перечислить всех отправителей вручную вместо include, из-за чего запись разрастается и начинает превышать 255 символов в одной строке TXT.

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

Чем это отличается от проверки домена

Чекер SPF идёт в DNS и разбирает то, что там опубликовано. Валидатор работает с текстом, который вы вставили, и записи может ещё не существовать. Это разные задачи: первая отвечает на вопрос «что сейчас у домена», вторая «взлетит ли то, что я собираюсь опубликовать».

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

Как читать счётчик запросов

Валидатор показывает не только итоговое число, но и вклад каждого механизма. Это важнее суммы: строка вида include:_spf.example.com может стоить один запрос, а может восемь, если внутри спрятана своя цепочка.

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

Чего валидатор не проверит

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

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

Где брать значения для include

Каждый сервис публикует своё в документации, и брать их нужно оттуда, а не из статей в интернете: значения меняются. Опечатка в имени include означает домен без SPF-записи, а такой механизм ломает разбор целиком: запись перестаёт работать, а не просто теряет один сервис.

Отдельная ловушка это примеры из документации вместе с чужим доменом. Строка вида include:_spf.example.com, скопированная как есть, синтаксически безупречна, проходит валидацию и авторизует инфраструктуру, к которой вы не имеете отношения.

Две SPF-записи на домене: почему так нельзя

Это самая частая поломка, и она не про синтаксис. Стандарт разрешает домену иметь ровно одну запись, начинающуюся с v=spf1. Если их две, проверка возвращает permerror, и SPF перестаёт работать полностью, а не частично.

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

Лечится объединением в одну строку. Все механизмы include из обеих записей переносятся в одну, дубли убираются, all остаётся один. Проверить результат до публикации можно формой на этой странице: она читает запись как читает её получатель и покажет, укладываетесь ли вы в лимит запросов.