SMTP 550 5.7.1: что значит ошибка и как исправить

1. Что значит ошибка 550 5.7.1

Код 550 задан в стандарте SMTP (RFC 5321): это постоянный отказ, запрошенное действие не выполнено, почтовый ящик получателя недоступен, в том числе по соображениям политики или безопасности. Первая цифра 5 означает класс ошибки: повтор попытки в неизменном виде не имеет смысла, в отличие от временных кодов 4xx, например 421 или 450, где сервер просит паузу.

Расширенный код 5.7.1 описан в RFC 3463 как delivery not authorized, message refused: доставка не разрешена, сообщение отклонено. Ключевой нюанс: проблема не в самом ящике получателя, а в политике сервера получателя по отношению к вашему письму, IP или домену отправителя.

Практический смысл: 550 5.7.1 это жесткий возврат (hard bounce). Письмо возвращается отправителю с отчетом о недоставке (NDR), и именно этот отчет, а не пересказ словами, главный источник данных о причине. Пока причина не устранена, повторные отправки копят отказы и портят статистику домена и IP. Различие жестких и мягких возвратов разобрано в [отдельном материале](/blog/bounce-hard-soft).

2. Как выглядит ошибка 550 5.7.1 при отправке

Отказ приходит письмом от Mailer-Daemon вашего почтового сервера или ESP. Типовой фрагмент отчета:

This is the mail system at host mail.example.ru. I am sorry to inform you that your message could not be delivered to one or more recipients. <client@example.com>: host mx.example.com[203.0.113.10] said: 550 5.7.1 Message rejected due to local spam policy (in reply to end of DATA command)

В отчете важны три места. Первое: полный текст после 550 5.7.1, часто именно там указана причина, имя блок-листа или ссылка на разбор ошибки у провайдера. Второе: строка host mx.example.com[203.0.113.10], она показывает, какой сервер и на каком этапе отклонил письмо. Третье: место в SMTP-сессии, указанное в скобках в конце.

По стандарту RFC 5321 почтовая транзакция внутри SMTP-сессии (она открывается приветствием EHLO или HELO) состоит из команд MAIL FROM, RCPT TO и DATA, и сервер может отклонить сообщение на любом из этих этапов, а иногда и раньше - на самом соединении или в ответ на EHLO. Отказ в ответ на RCPT TO означает, что содержимое еще не передавалось: решение приняли по адресу, политике пересылки или IP. Отказ после end of DATA command означает, что сервер видел письмо целиком и отклонил его по результатам проверки подлинности, контента или репутации. Это первая развилка диагностики, к ней вернемся ниже.

3. Типичные формулировки: message rejected, blocked и другие

Код 5.7.1 один, а причины за ним разные. Таблица сопоставляет частые формулировки из отчетов с типовой причиной.

Если в отчете есть ссылка на справку провайдера, начните с нее: справка Mail.ru описывает порядок действий, когда письма не доходят, а руководство Microsoft для операций безопасности разбирает проверки подлинности писем. Формулировки сторонних антиспам-систем отличаются, и по ссылке обычно видно, чей фильтр сработал.

4. Дерево диагностики: шесть шагов до причины

Шаг 1. Соберите факты. Возьмите 3-5 отчетов с кодом 550 5.7.1 за последние дни. Один отказ может быть разовым срабатыванием фильтра, закономерность видна на выборке: отклоняет один провайдер или несколько, один ESP или все ваши платформы отправки.

Шаг 2. Определите этап отказа. Отказ на RCPT TO это адрес, политика пересылки или IP. Отказ после DATA это подлинность, контент или репутация. Этот шаг отсекает половину гипотез до любых проверок.

Шаг 3. Проверьте IP в черных списках. Строка host mx.example.com[203.0.113.10] в отчете - это принимающий сервер получателя, а не ваш адрес: проверять его в блок-листах бессмысленно. Возьмите исходящий IP своего почтового сервера или ESP, с которого реально ушла рассылка, - из логов MTA, кабинета ESP или заголовка Received уже доставленного письма. Запрос к Spamhaus ZEN выполняется с октетами этого IP в обратном порядке: например, для адреса 198.51.100.7 команда dig +short 7.100.51.198.zen.spamhaus.org. Ответ NXDOMAIN (нет записи) означает, что IP в списке отсутствует, ответ вида 127.0.0.x означает попадание, а 127.255.255.254 означает, что запрос заблокирован из-за публичного резолвера. Учитывайте, что Spamhaus не отвечает на запросы через крупные публичные резолверы вроде 8.8.8.8 или 1.1.1.1: проверяйте со своего DNS-сервера. Быстрее прогнать адрес по нескольким спискам сразу [автоматической проверкой](/tools/blacklist-check).

Шаг 4. Проверьте DNS-записи домена отправителя: dig +short TXT example.com покажет запись SPF, dig +short TXT sel1._domainkey.example.com публичный ключ DKIM селектора sel1, dig +short TXT _dmarc.example.com политику DMARC. Селектор DKIM берется из тега s= заголовка DKIM-Signature любого доставленного письма.

Шаг 5. Проверьте обратную зону: dig -x 203.0.113.10. PTR должен существовать и соответствовать имени, которое сервер называет в HELO/EHLO. Вопросам PTR и HELO посвящен [отдельный разбор](/blog/ptr-helo-dlya-email).

Шаг 6. Отправьте тестовое письмо с рабочего домена на свой ящик и разберите заголовки. Блок Authentication-Results показывает вердикты SPF, DKIM и DMARC глазами сервера получателя. Бесплатный [анализатор заголовков](/tools/email-header-analyzer) выполняет разбор прямо в браузере.

5. Как исправить smtp 550 5.7.1 по каждой причине

IP в черном списке. Запросите удаление по инструкции владельца списка и параллельно снижайте жалобы, иначе попадание повторится. Процедура для Spamhaus разобрана [в отдельной статье](/blog/spamhaus-delisting). Если IP общий, обсудите с провайдером переход на выделенный адрес, но помните: перенос без работы с причинами переносит и проблему.

Ошибки подлинности. Оставьте ровно одну запись SPF (дубли ломают проверку), опубликуйте DKIM для всех сервисов, которые отправляют от вашего домена, и настройте DMARC с согласованием домена. Проверяйте результат командами из шага 4 или [проверкой SPF](/tools/spf-check), [DKIM](/tools/dkim-check) и [DMARC](/tools/dmarc-check). Взять настройку на себя может [услуга по аутентификации](/services/email-authentication).

Ошибка пересылки. Если в отчете Relay access denied или Unable to relay, проблема в вашей цепочке отправки, а не в репутации: клиент обращается к серверу, которому не разрешена пересылка. Включите SMTP-аутентификацию и отправляйте через submission-порт 587 либо через штатный сервер вашего ESP.

Репутация и жалобы. Если формулировка про спам-политику, а DNS и IP чистые, сервер реагирует на долю жалоб и качество базы. Допустимая доля жалоб у Mail.ru зависит от объема отправки:

У Gmail ориентир жестче: доля жалоб в Google Postmaster Tools должна держаться ниже 0,1%, а значение выше 0,3% трактуется как несоблюдение требований к отправителям. Эти пороги относятся только к Gmail, у Mail.ru действует таблица выше.

Общие направления работы разобраны в материалах о [причинах попадания рассылок в спам](/blog/pochemu-rassylka-popadaet-v-spam), [управлении жалобами](/blog/zhaloby-fbl-i-otpiska) и [качестве базы](/blog/kachestvo-bazy-i-dostavlyaemost).

6. Ограничения и похожие коды

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

Не смешивайте классы проблем. Код 550 5.7.1 означает отказ вашему сообщению целиком: авторизация, репутация, политика сервера. Код 550 5.1.1 означает, что конкретного адреса не существует, и чинится чисткой базы, а не настройками инфраструктуры.

Близкий код 550 5.7.26 в Gmail связан с проверкой DMARC, у него [отдельный разбор](/blog/gmail-550-5-7-26). Если вместо 5xx приходят 421 или 451, это временные ограничения: пауза и снижение темпа. И еще один случай: письмо принято сервером, но оказывается в спаме. Это не 550 5.7.1, [разница разобрана отдельно](/blog/delivery-ne-ravno-inbox).

7. Как проверить результат

Повторите проверки шагов 3-5: записи DNS отдают ожидаемые значения, IP отсутствует в основных DNSBL, а в Authentication-Results тестового письма стоят pass по SPF, DKIM и DMARC.

Отправьте письма на контрольные ящики Gmail, Mail.ru, Яндекса и Outlook и убедитесь, что код 550 5.7.1 не возвращается. Единичные отказы по отдельным адресам нормальны, следите за долей таких возвратов в логах ESP.

Дальше нужен постоянный контроль. PostmastersTool собирает через API доли SPF, DKIM и DMARC, долю жалоб и соответствие требованиям Google из Google Postmaster Tools, а также объем, доставку и жалобы из Mail.ru Postmaster, проверяет DNS и черные списки доменов и присылает уведомление при пересечении порогов, с историей по дням.

Критерий результата: доля отказов 550 5.7.1 в возвратах снизилась до фонового уровня, жалобы уложены в пороги провайдеров, новые отправки не приводят к попаданиям в блок-листы.