SPF проверка

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

Проверка SPF онлайн начинается с DNS: инструмент запрашивает TXT-записи домена и берёт ту, что начинается с v=spf1. Дальше запись разбирается на механизмы, и вы видите оценку от 0 до 100, саму строку, число механизмов, число DNS-запросов и итоговую политику (-all, ~all, ?all или +all). Оценка зависит прежде всего от политики:

Если механизмов, требующих DNS-запроса, больше десяти, из оценки вычитается ещё 30 баллов. Учтите: счётчик считает механизмы самой записи. Каждый include — это один запрос, но внутри подключённой записи могут быть свои include, и они тоже расходуют лимит. Раскрыть цепочку можно вручную:

dig +short TXT example.com
dig +short TXT _spf.google.com

И обязательно сверьте исходную строку записи в отчёте: если механизма all в ней нет вовсе, по стандарту для неперечисленных серверов результат будет neutral, как у ?all. Голое all без знака равно +all.

Синтаксис SPF: механизмы и квалификаторы

Запись читается слева направо до первого совпадения. Перед механизмом может стоять квалификатор: + (pass, по умолчанию), - (fail), ~ (softfail), ? (neutral).

• ip4:203.0.113.10, ip4:203.0.113.0/24, ip6:2001:db8::/32 — адреса и подсети. DNS-запросов не требуют.
• a — IP из A/AAAA-записей домена; mx — IP почтовых серверов из MX. По одному запросу (у mx — плюс запросы на каждое имя).
• include:domain — «спроси SPF у другого домена». Основной способ подключить почтовый сервис.
• exists и ptr — редкие; ptr стандарт прямо не рекомендует использовать.
• redirect=domain — модификатор: вся политика берётся у другого домена. Работает, только если в записи нет all.

Лимит 10 DNS-запросов: почему SPF ломается после подключения сервисов

RFC 7208 ограничивает проверку десятью DNS-запросами. Считаются include, a, mx, ptr, exists и redirect, включая вложенные. При превышении получатель возвращает permerror — и SPF для всех писем домена считается непройденным, хотя запись выглядит правильной. Типичная история: Google Workspace (3–4 запроса со вложенными), CRM, сервис рассылок, тикет-система — и лимит исчерпан.

Как уложиться:

1. Удалите include сервисов, которыми больше не пользуетесь. Это самая частая находка.
2. Уберите a и mx, если сайт и входящая почта не отправляют письма от имени домена.
3. Свои серверы перечисляйте через ip4/ip6 — они бесплатны по лимиту.
4. Рассылки отправляйте с поддомена (news.example.com) со своей SPF-записью — у поддомена отдельный лимит.

«Плоское» разворачивание include в список IP тоже снимает проблему, но адреса сервисов меняются, и такую запись придётся поддерживать.

Частые ошибки в SPF

• Две записи v=spf1 на одном домене. Стандарт требует одну; две дают permerror. Обычно вторую добавляет новый сервис по инструкции «создайте TXT-запись». Правильно — объединить механизмы в одну строку. Наш отчёт показывает первую найденную запись, поэтому количество проверьте командой dig TXT example.com.
• +all — разрешает отправку от вашего имени кому угодно.
• Опечатки: v=spf без единицы, include: _spf.google.com с пробелом, ip4: с IPv6-адресом.
• SPF на поддомене не наследуется. Запись для example.com не защищает mail.example.com — нужна своя (хотя бы v=spf1 -all, если с него не шлют).
• Тип записи SPF (99) устарел — публикуйте только TXT.

Готовые SPF-записи для популярных сервисов

Пример для домена на Google Workspace, который рассылает через SendGrid и шлёт уведомления со своего VPS:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all

Многие сервисы рассылок проверяют SPF не основного домена, а отдельного поддомена возврата (Return-Path), который они просят направить на себя CNAME-записью. Сверяйтесь с инструкцией конкретного сервиса, а не копируйте include вслепую.

Как добавить или исправить SPF-запись в DNS

SPF правится там, где живут NS-серверы домена: у регистратора, у хостера или в Cloudflare. Неважно, где куплен домен, — важно, чьи NS в нём прописаны. Порядок одинаковый везде:

1. Найдите существующую TXT-запись с v=spf1 на корне домена (имя @ или пустое поле). Если она есть — редактируйте её, а не создавайте вторую.
2. Тип — TXT, имя — @ (для поддомена — его имя без основного домена, например news), значение — запись целиком, TTL — 3600 или «авто».
3. Кавычки большинство панелей добавляет само. Если панель показывает значение в двойных кавычках, внутрь лишние кавычки не ставьте.
4. Запись длиннее 255 символов должна быть разбита на несколько строк внутри одной TXT-записи; Cloudflare и большинство панелей делают это автоматически.

В Cloudflare TXT-записи не проксируются, оранжевого облака у них нет — настраивать ничего дополнительно не нужно.

Как проверить SPF в заголовках полученного письма

DNS-проверка показывает, что опубликовано. Что увидел получатель — видно в заголовках письма. В Gmail откройте письмо → «Показать оригинал»: в строке SPF будет PASS, SOFTFAIL, FAIL, NEUTRAL или PERMERROR и IP отправителя. В сыром заголовке ищите Authentication-Results:

Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected]
       does not designate 198.51.100.25 as permitted sender) [email protected]

Здесь видно главное: проверялся домен из smtp.mailfrom, а IP 198.51.100.25 в записи не перечислен. Добавьте этот сервер через ip4 или include его сервиса. Результат permerror почти всегда означает две записи или превышение лимита запросов.

~all или -all: что выбрать

-all строже, но часть серверов отклоняет письмо по SPF ещё до проверки DKIM — и пересланные письма, где SPF неизбежно ломается, теряются. Поэтому при настроенном DMARC часто оставляют ~all: решение о судьбе письма принимает DMARC по совокупности SPF и DKIM. Если домен вообще не отправляет почту, ставьте v=spf1 -all — это закрывает его от подделки.

SPF, DKIM и DMARC: как они работают вместе

SPF проверяет адрес конверта (Return-Path), а не адрес «От кого», который видит человек. Поэтому одного SPF мало: DKIM подписывает письмо ключом домена, а DMARC требует, чтобы SPF или DKIM прошли для того же домена, что в поле From, и говорит получателю, что делать с остальными письмами. С 2024 года Gmail и Yahoo требуют от массовых отправителей все три механизма. После SPF проверьте ключ подписи в проверке DKIM, политику в проверке DMARC, а почтовые серверы домена — через MX-записи. Как вообще читать DNS-ответы, разобрано в статье «Проверка DNS-записей»; остальные типы записей покажет DNS lookup.

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