SPF fail и softfail: как читать результат проверки и что исправлять

1. Что означают результаты проверки SPF

При приеме письма сервер получателя берет IP подключившегося сервера и домен из адреса обратного пути MAIL FROM (или из HELO, если MAIL FROM пустой) и сверяет их с записью SPF этого домена. Стандарт RFC 7208 определяет семь результатов такой проверки.

Результат проверки виден в технических заголовках письма, в поле Authentication-Results. Пример письма, где SPF не прошел:

Authentication-Results: mx.google.com; spf=fail (google.com: domain of bounce@news.example.com does not designate 203.0.113.10 as permitted sender) smtp.mailfrom=news.example.com

Ключевая деталь здесь: проверяется домен news.example.com из smtp.mailfrom, а не домен из поля From, которое видит подписчик. Если смотреть не на тот домен, диагностика уйдет не туда.

2. SPF fail и softfail: в чем разница на практике

Разница задается последним механизмом записи. Запись v=spf1 include:_spf.esp-example.com ip4:203.0.113.10 -all дает fail для всех IP, которые не перечислены явно. Та же запись с ~all в конце дает softfail.

Fail с -all: жесткое запрещение. Принимающая сторона вправе отклонить письмо еще на SMTP-сессии. Gmail, например, в подобных ситуациях может вернуть отказ 550 5.7.26 с требованием настроить аутентификацию отправителя.

Softfail с ~all: мягкий сигнал. Письмо, скорее всего, будет принято, но результат проверки уйдет в минус при спам-оценке. Такой вариант используют на этапе внедрения SPF, когда список отправителей еще не собран полностью.

Если письма уходят с общего IP платформы рассылок, сама площадка обычно дает готовый include для записи. Если у домена выделенный IP, его нужно внести явно через ip4 или ip6.

3. Neutral и none: когда запись ничего не решает

Neutral возникает, когда запись заканчивается механизмом ?all: v=spf1 ip4:203.0.113.10 ?all. Отправитель тем самым говорит: перечисленные адреса разрешены, про остальные ничего не знаю. Для антиспам-систем это почти то же самое, что отсутствие записи.

None означает, что TXT-записи, начинающейся с v=spf1, у домена просто нет. Проверить это можно командой:

dig +short TXT news.example.com

Если в ответе нет строки, начинающейся с v=spf1, любая проверка SPF для этого домена вернет none. Для массовых рассылок это прямое нарушение требований крупных почтовых сервисов к аутентификации отправителя.

Частая ловушка: запись опубликована на корневом домене example.com, а рассылка идет с поддомена news.example.com, где записи нет. SPF не наследуется вниз по дереву поддоменов: для каждого домена из MAIL FROM запись должна существовать отдельно.

4. Temperror: временная ошибка DNS

Temperror возвращается, когда проверка не смогла завершиться из-за временной проблемы с DNS: таймаут ответа, ошибка SERVFAIL, недоступность авторитативных серверов домена. По стандарту это временная ситуация, проверку нужно повторить позже.

На практике принимающие серверы обычно трактуют temperror как повод для временного отказа класса 4xx и повторной попытки доставки, а не как постоянный запрет. Но если ошибка держится часами, письма начнут отклоняться окончательно уже на стороне отправителя по таймауту повторов.

Диагностика: проверьте ответ домена от нескольких резолверов и напрямую у авторитативных серверов:

dig TXT news.example.com @8.8.8.8 dig NS news.example.com dig TXT news.example.com @ns1.your-dns-provider.com

Если один резолвер отвечает, а другой возвращает SERVFAIL, смотрите на делегирование зоны, сроки жизни NS-записей и ошибки DNSSEC. Если домен недавно переносили к другому DNS-провайдеру, типичная причина: старые NS еще живут в кеше, а зона на новых серверах настроена не полностью.

5. Permerror: запись есть, но она невалидна

Permerror означает, что запись найдена, но вычислить ее невозможно. В отличие от fail, здесь виноват не IP отправителя, а сама запись. Типовые причины:

1. Несколько записей v=spf1 на одном домене. Стандарт запрещает больше одной записи SPF на имя: проверка обязана вернуть permerror. Частый сценарий: маркетолог добавил include новой ESP отдельной строкой, не удалив старую.

2. Синтаксическая ошибка в самой записи: опечатка в имени механизма или незнакомое имя механизма (стандарт требует вернуть permerror для всей записи, если хотя бы один термин не распознан), include или redirect без домена после двоеточия или знака равенства, недопустимый квалификатор перед механизмом. Неизвестные модификаторы (после знака =) стандарт как раз предписывает игнорировать, permerror они не дают.

3. Превышен лимит в 10 DNS-запросов при вычислении записи. Каждый include, a, mx, exists и redirect считается, включая вложенные цепочки include внутри include.

Пока запись возвращает permerror, SPF фактически не работает: аутентификация не проходит, DMARC теряет одну из опор. Подробные разборы этих сценариев: статьи про несколько SPF-записей и про лимит DNS-запросов в SPF.

6. Дерево диагностики: пошаговый разбор

Шаг 1. Возьмите письмо, которое попало в спам или было отклонено, и откройте полные заголовки. Найдите строку Authentication-Results и зафиксируйте точный результат spf= и домен из smtp.mailfrom.

Шаг 2. Проверьте запись именно этого домена: dig +short TXT <домен из mailfrom>. Нет записи: результат none, нужно публиковать SPF. Две и больше записи: permerror, объединять в одну.

Шаг 3. Если запись одна и синтаксически читается, проверьте, покрывает ли она IP отправляющего сервера. Разверните цепочку include вручную командами dig TXT по каждому включенному домену, пока не дойдете до механизмов ip4 и ip6. Если IP письма в списках нет, результат fail или softfail объяснен: добавьте нужный include или ip4.

Шаг 4. Если IP в записи есть, а результат все равно fail, проверьте, тот ли это IP. Письмо могло уйти через другой поток: тестовая отправка с личного ящика, новый сервис рассылок, переадресация. При переадресации SPF почти всегда ломается, потому что сервер, который доставляет письмо получателю, не принадлежит отправителю. Эту ветку разбираем в статье про переадресацию и ARC.

Шаг 5. Если запись выглядит корректно, но результат temperror, проверьте зону с разных резолверов и у авторитативных серверов, как показано в разделе 4. Ищите проблему в DNS, а не в тексте записи.

7. Как проверить, что исправление сработало

После правки DNS дождитесь обновления кеша (ориентир: TTL записи) и отправьте тестовое письмо на адрес Gmail и на ящик Mail.ru или Яндекса. В заголовках доставленного письма Authentication-Results должен показать spf=pass для домена из MAIL FROM.

Для объемного контроля смотрите долю писем, прошедших SPF, в Google Postmaster Tools. Там метрика считается по трафику с вашего домена, и падение доли SPF это ранний сигнал, что часть потока уходит в обход настроенной записи.

Разовые проверки не защищают от регрессий: запись могут изменить коллеги, ESP может поменять адреса отправки, DNS-зону могут перенести. PostmastersTool проверяет DNS доменов, включая SPF, DKIM и DMARC, собирает данные Google Postmaster Tools и Mail.ru Postmaster, хранит историю по дням и присылает уведомление в Telegram или на почту, когда метрики выходят за пороги. Так поломку SPF видно в день изменения, а не после падения открываемости.