Ошибка SPF: причины, коды и исправление DNS

Ваше письмо вернулось. В заголовках указано spf=fail. Вы видите ошибку 550 5.7.1 или 550 5.7.26, а клиент ждет так и не пришедшего ответа.

Ошибка SPF связана не с содержимым, а с DNS-аутентификацией. Почтовый сервер получателя проверил запись SPF, не нашел IP отправки в списке разрешенных и мог отклонить сообщение еще до его попадания в папку спама.

С февраля 2024 года Google и Yahoo чаще отклоняют неаутентифицированные письма на уровне протокола, а не просто помечают их как подозрительные. Это руководство объясняет конкретные коды, показывает, где найти проблемный IP в заголовках, и разбирает три исправления DNS, способные устранить большинство распространенных ошибок SPF. Так можно начать с наиболее подходящего решения.

Если вы впервые настраиваете почту на своем домене, сначала создайте корректную базовую конфигурацию DNS. Многие проблемы SPF связаны с неполной первоначальной настройкой.

Что такое ошибка SPF?

Ошибка SPF возникает, когда принимающий сервер проверяет запись Sender Policy Framework домена и не находит IP отправки среди разрешенных. SPF публикуется в виде DNS-записи TXT и перечисляет IP-адреса и почтовые сервисы, которым разрешено отправлять письма от вашего имени. При отрицательном результате сервер может сразу отклонить сообщение (hard fail) или принять его как подозрительное (soft fail). Политика DMARC учитывает оба варианта как неудачную проверку.

SPF проверяет отправителя конверта, то есть адрес MAIL FROM, согласованный во время SMTP-рукопожатия, а не видимый получателю заголовок "From". Это различие важно при поиске причины.

Прочитайте код ошибки до любых изменений

Почтовые серверы возвращают разные SMTP-коды при ошибке SPF. Код показывает решение получателя и его причину. Если рассматривать 550 5.7.26 как обычный 550 5.7.1, диагностика займет больше времени. Сначала сопоставьте код с причиной и лишь затем меняйте DNS.

Шаг 1: найдите проблемный IP в заголовках

Не угадывайте, какой IP вызвал ошибку SPF. Откройте исходные заголовки возвращенного сообщения или уведомления о недоставке и найдите Authentication-Results. Этот заголовок содержит IP, который проверял получатель, и принятое решение.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

Здесь есть две важные улики: IP отправки (192.0.2.55) и проверяемый домен (example.com). Теперь определите владельца IP:

• Недавно подключенный сервис SaaS? (HubSpot, Zendesk, Shopify)
• Ваш веб-сервер? (WordPress, cPanel)
• Почтовый пересыльщик? (см. раздел о ловушке переадресации ниже)

Затем быстро проверьте текущую запись SPF:

dig +short txt yourdomain.com | grep spf

Если строк, начинающихся с v=spf1, больше одной, вы уже нашли одну из возможных причин.

Шаг 2: три наиболее частых исправления SPF

Большинство ошибок SPF связано с одной из трех причин: отсутствующим include провайдера, дублирующей записью или превышением лимита в 10 DNS-запросов. Выберите исправление по результатам шага 1.

Исправление 1: отсутствующий include провайдера

Вы добавили новый почтовый инструмент, например HelpScout, HubSpot, Zendesk или транзакционную почту Shopify, но не обновили DNS. Сервис отправляет от вашего имени с неразрешенного IP. Это частая причина ошибки SPF после подключения нового провайдера.

Ошибочная запись:

v=spf1 include:spf.trekmail.net -all

Успешная запись (после добавления HelpScout):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

Найдите обязательную строку SPF include в документации провайдера. Добавьте ее в существующую запись SPF TXT, а не создавайте новую. Следует перечислить каждый сервис, через который идет отправка.

Исправление 2: две записи (критическая синтаксическая ошибка)

У домена может быть только одна запись SPF. Если вместо объединения с существующей записью создать для нового инструмента вторую запись TXT, получатели увидят две противоречащие политики и признают обе недействительными. Возникнет PermError, который может вызвать hard fail для всех писем домена, включая ранее успешно доставлявшиеся.

Неверно, две отдельные записи:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

Верно, объединено в одну запись:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Войдите в панель DNS-провайдера, оставьте только одну запись SPF TXT и объедините все данные в одной строке. Вызванный дубликатами PermError может нарушать SPF для всех отправителей, пока запись не будет исправлена.

Исправление 3: лимит в 10 запросов (архитектурная ошибка)

RFC 7208 ограничивает проверку SPF 10 DNS-запросами, чтобы серверы нельзя было использовать для усиления DNS-атак. Механизмы include, a и mx учитываются в лимите. Вложенные include, где провайдер ссылается на запись своего поставщика, также учитываются.

После превышения 10 запросов возникает PermError, и SPF может не проходить для всех отправителей. Проверьте число запросов, проследив запись:

dig +short txt yourdomain.com

Посчитайте каждый механизм include, a и mx, а затем проверьте вложенные include каждого провайдера. При превышении лимита есть два надежных подхода:

1. Разделите отправителей по поддоменам. Перенесите инструменты массового маркетинга на marketing.yourdomain.com. Поддомен получит собственный лимит в 10 запросов, отдельный от записи основного домена.
2. Разверните запись. Замените цепочки include фактическими IP, в которые они разрешаются, используя механизмы ip4: или ip6:. Они не считаются запросами. Недостаток: при смене IP провайдером запись придется обновлять вручную.

Есть и ограничение пустых запросов. Если более двух запросов в цепочке возвращают NXDOMAIN, например из-за опечатки include:spf.gogle.com, запись становится недействительной по RFC 7208 §11.1. Одна опечатка во вложенных include провайдера способна нарушить всю проверку SPF.

Ловушка переадресации: почему SPF не проходит для легитимной почты

Ошибка SPF может возникнуть и при корректной DNS-конфигурации. Вы отправляете письмо на адрес выпускника (alice@university.edu), который автоматически пересылает его в Gmail (alice@gmail.com). Gmail видит письмо с IP сервера университета. В вашей записи SPF этот IP не разрешен, поэтому проверка завершается ошибкой.

Путь выглядит так: ваш сервер -> сервер университета -> Gmail. Gmail проверяет последний переход. Ошибки переадресации нельзя исправить одним SPF, поскольку он разрешает только исходный IP отправки. При появлении пересыльщика проверяемый IP меняется.

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

Если вы управляете переадресацией на уровне инфраструктуры и хотите совместимое с SPF переписывание, изучите Sender Rewriting Scheme (SRS). Эта схема позволяет пересыльщику менять отправителя конверта так, чтобы SPF мог пройти в конечной точке. Полный путь диагностики рассмотрен в руководстве по настройке и исправлению переадресации.

Проверьте исправление перед продолжением

После обновления DNS дождитесь распространения записи. У многих провайдеров это обычно занимает от 5 до 30 минут, а в отдельных случаях несколько часов. Затем убедитесь, что изменение действительно применилось.

Отправьте тестовое письмо на Gmail, откройте исходные заголовки и найдите Authentication-Results. Требуемый результат выглядит так:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

Если по-прежнему указан spf=fail или spf=softfail, изменение еще не распространилось либо запись все еще содержит проблему. Сравните IP в заголовках с IP в обновленной записи. Они должны совпадать.

Запись можно проверить и напрямую:

dig +short txt yourdomain.com

Убедитесь, что с v=spf1 начинается ровно одна запись, в нее включены используемые сервисы отправки, а заканчивается она на -all (hard fail) или ~all (soft fail).

Управление SPF для нескольких доменов

Для одного домена управление SPF обычно является разовой задачей: добавить include, объединить дубликаты и исправить число запросов. Но при управлении почтой для 10, 50 или 500 доменов с собственными записями SPF и наборами SaaS-провайдеров ручная диагностика каждой ошибки становится заметной операционной нагрузкой.

Управляемый SMTP TrekMail, доступный в Starter от $3.50/mo, сокращает настройку до одного include на домен. TrekMail выполняет смену IP, наблюдение за возвратами, выравнивание DKIM и поддержку базовой инфраструктуры доставки. В плане Agency ($23.25/mo) агентства могут применять стандартный шаблон DNS к клиентским доменам вместо поиска ошибок SPF во множестве отдельных записей.

Чтобы оценить управляемую доставку на практике, можно начать 14-day бесплатный пробный период.

Кратко об ошибке SPF

Ошибка SPF означает, что принимающий сервер проверил DNS, не нашел IP отправки и применил вашу политику. Hard fail (-all) может означать отказ. Soft fail (~all) может привести к папке спама. PermError означает, что запись повреждена и SPF может не проходить для отправителей, пока запись не исправлена.

Выполните исправления по порядку:

1. Найдите проблемный IP в заголовке Authentication-Results
2. Добавьте отсутствующий include провайдера, если причиной стал новый сервис
3. Объедините дублирующие записи SPF в одну
4. Сократите число DNS-запросов ниже 10 или перенесите массовых отправителей на поддомены
5. При ошибке SPF на пересланной почте внедрите DKIM, поскольку SPF не сохраняется при ретрансляции

Сначала выберите подходящее исправление, а затем подтвердите результат по заголовкам.