Как проверить SPF в DNS и найти ошибку в записи

Если SPF настроен, а письмо не проходит проверку, сначала смотрите TXT-записи именно для домена MAIL FROM: дубликаты, забытые отправители и лишние DNS-запросы ломают политику. Если SPF проходит, а письмо в спаме, проверяйте Authentication-Results и выравнивание DMARC: SPF сам по себе не обещает место во «Входящих». Ниже — пять проверок и порядок исправления.

Ошибка 1. Для домена опубликовано несколько SPF-записей

SPF публикуют в TXT-записи DNS. Для одного доменного имени допускается одна SPF-запись, то есть один TXT-ответ с политикой, начинающейся с v=spf1. Обычные TXT-записи для подтверждения домена или других сервисов этому не мешают: искать нужно именно строки SPF. Если у одного имени нашлись две политики v=spf1, проверяющая сторона возвращает permerror. Это ошибка SPF, но RFC не заставляет получателя немедленно отклонять письмо: решение о доставке остаётся за его локальными правилами. Поэтому фраза «две записи — и вся почта гарантированно в спаме» звучит эффектно, но не описывает протокол.

Я проверяю ответы DNS для того имени, которое участвует в отправке, а не только корень зоны. В условном примере ООО «Хрусталь-Плюс» на документационном домене example.com обнаружились две отдельные политики v=spf1; это учебная схема, а не история реального клиента. Исправление — свести разрешённые источники в одну согласованную запись и повторно проверить ответ DNS. Например, строка v=spf1 ip4:192.0.2.25 ~all показывает форму правила, но адрес 192.0.2.25 зарезервирован для документации и не должен использоваться в рабочей зоне. Для реальной настройки я сначала составляю список отправителей и только потом публикую политику. Начать можно с почтовой инфраструктуры для компании.

Не считайте каждую видимую строку или пару кавычек отдельной политикой. TXT — общий тип DNS-записи, и длинное содержимое одной записи может быть представлено несколькими фрагментами. В панели управления это иногда выглядит как несколько строк, хотя DNS-ответ остаётся одним ресурсом. Сверяйте имя, тип и сами ответы: дубликатом SPF будет отдельная TXT-запись для того же имени, начинающаяся с v=spf1. Поэтому я не удаляю запись только по скриншоту зоны; сначала проверяю, что именно опубликовано в DNS.

После правки я сохраняю точное имя DNS, которое проверял, и исходный ответ. На корне example.com и на notify.example.com могут быть разные политики; запрос для одного имени не показывает состояние другого. Кроме того, кэш DNS некоторое время хранит старый ответ согласно TTL. Если панель уже показывает исправление, а внешний проверяющий ещё старое значение, сравните ответы и время обновления, прежде чем вносить повторную правку. Две поспешные публикации подряд часто создают новую путаницу вместо устранения первой.

Ошибка 2. В запись не попали все источники отправки

SPF отвечает на конкретный вопрос: разрешено ли этому IP отправлять письмо от имени проверяемого домена. Поэтому до редактирования записи я собираю отправителей по факту: основная почтовая система, сайт, бухгалтерские и CRM-уведомления, резервный шлюз, сервис рассылки. Вспоминаю не только то, что настраивали год назад, но и то, что «временно» подключили к сайту и забыли. Google отдельно рекомендует включать в SPF все источники, отправляющие почту от домена; иначе письма от пропущенного сервиса могут чаще попадать в спам. Это не означает, что нужно вписать каждую машину компании: учитывается тот источник, который действительно отправляет почту наружу.

Для фиксированных адресов в SPF есть механизмы ip4 и ip6; для почтовых сервисов обычно используют include с доменом, который провайдер указывает в своей инструкции. Не подставляйте выдуманное имя после include и не копируйте чужую запись целиком. Механизм include запускает отдельную проверку политики названного домена; он не переносит туда ваши серверы и не означает «разрешить весь этот сервис» без условий. Когда меняется провайдер, старое правило не стирают наугад и новое не приписывают вслепую: сначала инвентаризируют действующие отправки, затем собирают одну запись и проверяют её результат. При переносе почты эта сверка идёт вместе с остальными этапами; см. проверку SPF, DKIM и DMARC при смене провайдера.

Отдельная ловушка — механизм mx. Он проверяет адреса хостов, перечисленных в MX домена; само наличие сервера, принимающего входящую почту, ещё не доказывает, что этот сервер отправляет исходящие письма от вашего домена. Если включить mx автоматически «на всякий случай», можно разрешить больше источников, чем требуется. Я добавляю этот механизм только после проверки реального маршрута исходящих сообщений. Для IPv4 и IPv6 проверяю соответствующие механизмы раздельно: наличие адреса в ip4 не описывает отправку с IPv6.

Для каждого сервиса я записываю не только название, но и адрес, от которого тот реально отправляет: домен MAIL FROM, фактический адрес отправителя и используемый IP-протокол. Это особенно полезно для приложений: система может отправлять уведомления напрямую с отдельного шлюза, хотя сотрудники отправляют обычную почту через другой сервер. Отправка через общий ретранслятор и отправка напрямую — разные потоки. Если приложение использует корпоративную почту как SMTP-релей, его адрес может уже покрываться SPF этого релея; не добавляйте сервер приложения автоматически, пока журнал не подтвердит прямую отправку.

Ошибка 3. Превышен лимит DNS-проверок SPF

Лимит часто пересказывают как «десять include». Это неточно: RFC 7208 ограничивает десятью суммарно DNS-запрашивающие термины. В счёт идут include, a, mx, ptr, exists и модификатор redirect; вложенные проверки тоже расходуют общий лимит. Механизмы ip4, ip6 и all сами по себе DNS-запросов при вычислении SPF не добавляют. Поэтому короткая на вид запись с двумя include может запустить длинную цепочку, а запись с несколькими прямыми IP не обязательно приблизит к лимиту. Если десять превышены, результат SPF — permerror, а не универсальная команда «отправить письмо в спам».

Я раскрываю каждую ссылку include по актуальной документации поставщика и считаю термины во всей цепочке, а не только в строке основного домена. Исправлять начинаю с неиспользуемых отправителей и ненужных механизмов, затем проверяю SPF повторно. Механически «сплющивать» внешнюю политику в список IP рискованно: адреса сервиса могут измениться, а копия в вашей зоне останется старой. Если у сервиса есть поддерживаемый им способ уменьшить число проверок, использую его; самовольно менять схему авторизации ради красивого счётчика не надо. Итог сверяю по результату SPF и опубликованному DNS, а не по цветному индикатору непонятного сканера.

Удобный контрольный вопрос для провайдера: сколько DNS-запрашивающих терминов получится с учётом всех политик, на которые ссылаются include и redirect? Уточните, есть ли вложенные ссылки и как поставщик сообщает об изменении своих механизмов. Счётчик только по корневой строке вводит в заблуждение: он не видит дочерние правила. Если смена IP у сервиса требует обновления его SPF, оставьте поддерживаемую ссылку провайдера и следите за её результатом, а не ведите вручную свою копию чужого списка.

Для проверки одной цепочки записывайте не только число ссылок в своей строке, но и каждый DNS-запрашивающий термин, который сработает внутри дочерних политик. Например, include может запустить другую SPF-проверку, где обнаружатся собственные include и mx; они расходуют общий бюджет. А десять прямых механизмов ip4 не расходуют этот лимит. Это разные вещи, хотя оба случая могут выглядеть как длинная запись. Я фиксирую результат развёртки по каждому домену поставщика и после изменения повторяю подсчёт, а не ориентируюсь на длину строки.

Ошибка 4. Механизм all считают командой почтовому серверу

Механизм all сопоставляется с любым IP и обычно стоит последним. Знак перед ним задаёт результат: -all означает fail, ~all — softfail, ?all — neutral, а вариант без знака — pass. При этом получатель сам решает, что делать с результатом: fail может привести к отклонению, а softfail может стать поводом для более строгой проверки, но SPF не диктует действие фильтру. Если all отсутствует и другие механизмы не совпали, SPF возвращает neutral, а не ошибку синтаксиса. Вот почему утверждение «без -all SPF не работает» слишком грубое; точнее сказать, что владелец домена не задал явный итог для не совпавших источников.

Я не советую всем подряд переходить с ~all на -all через условную неделю. Сначала находят все легитимные источники, проверяют заголовки и отчёты, затем выбирают политику осознанно. Если в список не попал рабочий шлюз, жёсткий fail может повлиять на письма этого шлюза у тех получателей, чья политика на это реагирует. Мягкий результат тоже не означает «пропустить и пометить»: приёмник вправе оценить письмо вместе с другими сигналами. Важно не угадать символ в конце строки, а понимать, кто отправляет от домена и какой результат получит каждый такой источник.

Не ставьте +all как удобный способ «чтобы SPF точно проходил»: такой механизм совпадает с любым IP и возвращает pass для любого отправителя, фактически разрешая отправку откуда угодно. Это противоположность ограничительной политики. После all остальные механизмы уже не проверяются, поэтому адреса, случайно дописанные справа, не исправят ситуацию. Я проверяю не только наличие хвостового all, но и его знак и место. Если нужно разрешить конкретный источник, его описывают отдельным корректным механизмом до финального all.

Ошибка 5. SPF проверяют не для того домена

SPF обычно проверяет домен SMTP-команды MAIL FROM, а не видимый адрес в заголовке From, который читает человек. После доставки адрес конверта часто виден в Return-Path; при пустом обратном адресе проверяется идентификатор HELO. Поэтому запись для example.com не обязана описывать отправку, у которой домен MAIL FROM — notify.example.com. SPF ищет политику для конкретного имени DNS: настройка родительского домена автоматически не становится политикой каждого поддомена. А include — это проверка SPF указанного домена, не способ добавить поддомен в запись родителя.

Здесь начинается DMARC: он сопоставляет видимый домен From с доменом, который прошёл проверку SPF или DKIM. Для успешного DMARC достаточно хотя бы одного прошедшего и выровненного механизма. Значит, обычный SPF pass ещё не подтверждает выравнивание: сторонний отправитель может быть разрешён своей политикой, но домен этой проверки не совпадёт с видимым From. При пересылке письма SPF может не пройти, потому что принимающий сервер видит IP пересылающего узла; при этом выровненная DKIM-подпись всё ещё может позволить DMARC пройти. Я проверяю именно итоговые поля, а не делаю вывод по одному зелёному слову pass.

Когда сервис использует технический адрес возврата на отдельном поддомене, ищите SPF для домена этого адреса, а не настраивайте вслепую корень, который виден в From. Проверка исходного сообщения покажет MAIL FROM и позволит выбрать правильное имя DNS. Затем смотрите, совпадает ли этот прошедший домен с видимым From по правилам DMARC. Если провайдер не даёт управлять техническим доменом, выровненная подпись DKIM может дать второй путь к успешному DMARC. Здесь нельзя угадать по адресу в поле «От»: нужны заголовки конкретного письма.

Если SPF проходит, почему письмо всё равно в спаме

Откройте полный заголовок проблемного письма и найдите Authentication-Results или Received-SPF. В Authentication-Results смотрите результат SPF, домен MAIL FROM и IP отправителя, затем сравнивайте DKIM, DMARC и видимый From. Так можно отличить fail от permerror, увидеть, что SPF прошёл для одного домена, но не выровнялся с From, и заметить несовпадение IP. Это один из полезных фактов из базы знаний: результат SPF в заголовке несёт не только слово pass или fail, но и контекст проверки. Для проверки DNS можно выполнить dig TXT example.com; это запрос TXT для выбранного имени, а не тест того, куда письмо положит конкретный получатель.

Даже корректная запись не гарантирует папку «Входящие». SPF — один сигнал аутентификации. На решение также влияют DMARC, DKIM, репутация отправляющего адреса и содержание потока писем; конкретные правила принадлежат получателю. Я не меняю DNS, пока не сопоставлю результат проверки с заголовком и источником отправки: можно исправить безошибочную запись и оставить настоящую причину нетронутой. Если SPF и остальные проверки настроены, разбираю доставку отдельно; общие причины собраны в разборе SPF, DKIM и DMARC и материале о репутации отправляющего IP.

Разделяйте два симптома. При SMTP-отказе ищите текст ответа и отчёт о недоставке: там может быть указана конкретная причина отказа. Если письмо принято, но оказалось в спаме, исследуйте заголовки и результат фильтрации получателя. В обоих случаях сначала сопоставьте домен и IP из результата SPF с отправляющей системой. Не добавляйте адрес в разрешённый список только потому, что письмо не понравилось фильтру: так можно закрепить ошибочную отправку и не устранить причину.

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

Частые вопросы