SPF-запись не найдена: почему так бывает и как это исправить

Проверяющий сервис пишет «no SPF record found», а в заголовке письма стоит spf=none. Оба сообщения значат одно и то же: резолвер запросил TXT-записи по одному конкретному имени, и ни одна из них не начиналась с v=spf1. С вашим почтовым сервером всё в порядке. Вопрос в том, почему ответ оказался пустым, и обычно дело в том, что проверяют или публикуют запись не по тому имени.

Эта статья описывает, как искать причину пустого ответа. Если запись существует, но работает с ошибкой, читайте статьи про слишком много DNS-запросов и лимит в 10 запросов.

Что на самом деле значит «не найдено»

SPF хранится в обычной TXT-записи. Получатель берёт домен из письма (как правило, из адреса отправителя в конверте, его ещё называют адресом возврата или Return-Path), запрашивает его TXT-записи и оставляет только те, текст которых начинается с v=spf1. Если после фильтрации список пуст, результат — none. Это не синтаксическая ошибка, а отсутствие политики.

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

Причина 1: запись опубликована не по тому имени

SPF ищется по домену, который используется в письме, и больше нигде. Он не наследуется от родительского домена и не ищется на www. Запись на www.example.com ничего не даёт для почты с адресов @example.com, а запись на example.com ничего не даёт для почты с @news.example.com.

Классическая ошибка случается в панелях DNS. Для записи на корневом домене (так называемом apex) в поле хоста обычно вводят @, хотя некоторые панели требуют оставить его пустым или указать домен целиком. Прочитайте подсказку в панели, а затем проверьте результат запросом, а не полагайтесь на форму.

• Запись на www или mail: текст верный, хост неверный. Если вы отправляете почту с @example.com, перенесите запись на корневой домен.
• Удвоенный домен: панель, которая сама дописывает зону, превращает example.com в example.com.example.com. Запросите это имя, и вы найдёте свою запись там.
• Не тот домен отправки: вы проверили example.com, а в адресе отправителя конверта стоит bounce.example.net или mail.example.com. Получатель смотрел на это имя, а не на ваше.

Причина 2: вы проверяете не тот домен, с которого идёт почта

Адрес, который люди видят в заголовке From, — одно. Адрес отправителя в конверте, который и проверяет SPF, может быть другим. Многие почтовые сервисы используют собственный домен для возвратов, а некоторые по умолчанию применяют свой домен. Тогда SPF проверяется по этому имени, а ваша запись при проверке вообще не учитывается.

В заголовке письма видно, какой домен проверялся (см. ниже). Если это ваш поддомен, ему нужна собственная запись, даже если у родительского домена она безупречна. Поддомен, с которого почта не отправляется, может опубликовать v=spf1 -all.

Причина 3: текст не является корректной строкой SPF

Проверяющий строго относится к началу значения. Текст должен начинаться с v=spf1: со знаком равенства и без пробелов внутри. Все эти почти совпадения приводят к «не найдено»:

• spf1 include:_spf.example.net ~all (нет v=)
• v=spf include:_spf.example.net ~all (версия должна быть spf1)
• v = spf1 ... (пробелы вокруг знака равенства)
• Текст вставлен с «умными» изогнутыми кавычками, скопированными из документа или чата

Про кавычки стоит сказать отдельно. Большинство облачных панелей DNS сами добавляют прямые двойные кавычки, поэтому, если набрать свои, они сохранятся как обычные символы. Если в ответе dig видны два слоя кавычек, уберите те, что вы вводили сами.

Причина 4: вы правили не ту зону, которая работает в сети

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

• Регистратор и DNS-хостинг: домен зарегистрирован в одной компании, а его серверы имён указывают на другую (CDN, хостинг-компанию, отдельного DNS-провайдера). Работает только зона на делегированных серверах имён. Записи, добавленные на странице DNS самого регистратора или в оставшейся зоне у прежнего провайдера, игнорируются.

Узнайте делегированные серверы имён с помощью NS-запроса, а затем правьте зону именно у этого провайдера. Так часто объясняется ситуация «я добавил запись час назад, а её всё нет», причём лучше, чем распространение DNS.

Причина 5: устаревший тип записи, кеш или время

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

Время — последний подозреваемый и самый слабый. Если резолвер уже узнал, что по этому имени нет TXT-записи, он может продолжать отдавать пустой ответ в течение срока, который зависит от настроек отрицательного кеширования зоны. Запрос напрямую к авторитетному серверу имён снимает сомнения. Механику разбирает наша статья о том, как долго распространяется DNS.

Проверьте, что DNS возвращает на самом деле

Прежде чем что-либо менять, задайте DNS тот же вопрос, что и получатель. В Linux или macOS:

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Пустой ответ или ответ, в котором есть только такие вещи, как токены подтверждения сайта, подтверждает «не найдено». Чтобы обойти кеш собственного резолвера, спросите сервер имён напрямую: dig TXT example.com @ns1.example.net +short, подставив сервер имён из NS-запроса. Если он вернул запись, а обычный запрос нет, вы имеете дело с кешем. Если запись не вернул ни один из запросов, её нет в рабочей зоне.

Проверка SPF на этом сайте запрашивает TXT-записи введённого домена, оставляет те, что начинаются с v=spf1, и сообщает «No SPF record», если их нет. Если запись найдена, она также обходит include и считает запросы. TXT-запрос показывает все TXT-значения по имени, что помогает, когда запись есть, но написана неверно: вы видите исходный текст.

Прочитайте заголовок письма, которое не прошло проверку

Откройте исходный текст доставленного письма и найдите заголовок Authentication-Results, добавленный принимающим сервером. В части про SPF указан результат и, как правило, проверенный домен. Формулировки заголовков зависят от получателя, поэтому воспринимайте примеры как образец, а не как точный формат.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: по проверенному домену нет записи. Вам подходит эта статья.
• spf=fail или softfail: запись есть, но IP отправителя не авторизован. Добавьте отправителя или исправьте политику.
• spf=permerror: запись неисправна: либо две записи, либо слишком много запросов.

Обратите внимание на домен в smtp.mailfrom (или Return-Path). Именно он, а не адрес From, проверялся SPF. Как читать заголовки целиком, см. в статье как отследить исходного отправителя письма.

Опубликуйте минимальную безопасную запись

Опубликуйте одну TXT-запись по имени, которое используется в адресе отправителя конверта. Запись — это список механизмов, которые читаются слева направо и заканчиваются правилом по умолчанию для всех остальных.

• ip4 / ip6: разрешает адрес или диапазон, например ip4:203.0.113.25. DNS-запрос не тратится.
• include: разрешает всё, что разрешает SPF-запись другого домена, например include:_spf.example.net. Тратит один запрос.
• a: разрешает IP-адреса из собственной A-записи (или AAAA) домена. Тратит один запрос.
• mx: разрешает хосты, указанные в MX-записях домена. Тратит один запрос; неверно, если входящий хост не тот, что отправляет почту.
• ~all, -all, ?all: правило по умолчанию. ~all — softfail, -all — fail, ?all — neutral.

Начните с ~all, пока вы проверяете, что все отправители перечислены, а затем, убедившись в этом, подумайте о -all. ?all ничего не утверждает и в основном нужен на переходный период. Полный и верный список важнее окончания, ведь получатели оценивают SPF вместе с DKIM и DMARC.

Краткие подсказки для популярных платформ

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

• Microsoft 365 и Google Workspace: оба сервиса дают include, который нужно скопировать из консоли администратора или руководства по настройке. «Не найдено» здесь обычно значит, что запись попала не к тому DNS-провайдеру или не на тот хост.
• GoDaddy и другие регистраторы: если серверы имён заменили на CDN или хостинг-компанию, страница DNS у регистратора больше не является авторитетной. Правьте записи у провайдера, которого показывает NS-запрос.
• Cloudflare: если домен использует серверы имён Cloudflare, добавляйте TXT-запись на вкладке DNS в Cloudflare.

Что делают получатели, когда SPF нет

SPF none — это не автоматический отказ. Стандарт оставляет решение за локальной политикой получателя, поэтому результаты различаются. Почта без SPF и без DKIM или DMARC, которые это компенсируют, с большей вероятностью выглядит подозрительной, а некоторые провайдеры публикуют требования к аутентификации для массовых отправителей. Проверьте актуальные правила тех провайдеров, которым вы отправляете почту.

SPF проверяет отправителя в конверте, поэтому сам по себе он не мешает подделать видимый адрес From; это задача DMARC. См. SPF, DKIM и DMARC: объяснение и как проверить SPF-запись.