Ошибки SMTP 550, 554 и 535: что означают ответы почтового сервера
Ошибка SMTP показывает, на каком этапе почтовый сервер отказался продолжать отправку. Но одного числа 550, 554 или 535 недостаточно для диагноза. За одинаковым кодом могут стоять неверный получатель, ограничения отправителя, неподдерживаемый способ входа или ошибка формирования письма. Менять пароль и DNS одновременно в такой ситуации — значит усложнять поиск причины.
Начните с полного ответа сервера: сохраните основной код, расширенный статус, текст, время и команду, после которой произошёл отказ. Эта инструкция поможет прочитать ответ, выбрать нужную проверку и принять исправление. Все адреса на example.com и приведённые ниже ситуации — учебные примеры, а не реальные журналы клиентов.
Как читать ответ SMTP: три разных части
Условная строка 550 5.1.1 Recipient address rejected содержит три уровня информации. 550 — основной SMTP-код; 5.1.1 — расширенный статус; оставшаяся часть — пояснение конкретного сервера. Сохраните строку целиком: интерфейс CMS иногда оставляет только число и скрывает полезную причину.
Основной код определяет класс результата
В RFC 5321 ответы разделены по первой цифре. 2xx обозначает успешное завершение команды, 3xx — промежуточный этап, 4xx — временный отказ, 5xx — отказ, при котором тот же запрос не следует повторять без изменений. «Постоянный» здесь не означает, что ящик неисправен навсегда: после устранения причины новая попытка может стать успешной.
Например, 354 после DATA приглашает передать содержимое, но ещё не подтверждает принятие письма. Успех команды проверки сервера также не равен успеху всей отправки. Поэтому анализировать отдельную строку без предшествующей команды недостаточно.
Расширенный статус уточняет направление проверки
Структура класс.категория.деталь описана в RFC 3463. Категории помогают отличать адресацию, состояние ящика, сеть, протокол, содержимое и политику безопасности. Например, 5.1.1 относится к неверному адресу конечного ящика, а 5.7.1 — к отказу по правам или политике.
RFC 5248 определяет реестр таких значений; актуальные определения опубликованы в реестре IANA. Затем сверяйте полный текст со справкой сервиса, который вернул отказ. Код из чужого примера не заменяет ответ вашей системы, а похожая формулировка не доказывает одинаковую причину.
Определите этап: соединение, вход, адрес или содержимое
Сайт обычно передаёт письмо своему сервису отправки, а тот связывается с принимающей системой. Ошибка может возникнуть на любом участке. Отделение отправки приложением от дальнейшей ретрансляции закреплено в RFC 6409. Уточните, какой сервер ответил: выбранный SMTP-провайдер, корпоративный шлюз или сервер получателя.
| Этап | Где искать причину | Что полезно проверить |
|---|---|---|
| Соединение с сервером | DNS, сеть, доступность порта | Имя узла, место запуска приложения, точную сетевую ошибку |
| TLS | Защищённое соединение | Режим шифрования, имя в сертификате, доверенную цепочку |
| AUTH | Вход приложения | Аккаунт, разрешённый механизм, срок действия доступа |
| MAIL FROM | Отправитель конверта | Разрешён ли этот адрес выбранной учётной записи |
| RCPT TO | Конкретный получатель | Адрес, существование ящика, ограничения приёма |
| DATA и завершение передачи | Сообщение и политика обработки | Формат, размер, подписи и точное пояснение отказа |
Если соединение вообще не установлено, искать смысл SMTP 550 рано: ответ этого сервера ещё не получен. Если вход завершился отказом 535, изменение HTML-шаблона обычно не относится к обнаруженному этапу. Такая последовательность экономит время и помогает передать задачу тому, кто управляет нужным участком.
Что означает «ошибка SMTP 25»
25 — обычно номер порта, а не двухзначный код SMTP. Для межсерверной пересылки используется порт 25; подключение приложения к сервису отправки может иметь другой документированный порт и режим защиты. Нельзя выбрать их только по похожему примеру из поиска.
Уточните полное сообщение: тайм-аут, отказ соединения или ошибка TLS требуют разных проверок. Ограничения зависят от среды: например, Amazon описывает ограничения порта 25 для EC2. Это пример политики конкретной платформы, а не объяснение любого сбоя на любом хостинге. Проверяйте правила своего провайдера и не отключайте проверку сертификата ради подключения.
Что собрать до изменения настроек
Выберите одно проблемное уведомление и свяжите его с записью сайта: заказом, заявкой или событием системы. Зафиксируйте время с часовым поясом, имя приложения, среду запуска, получателя и идентификаторы сообщения. Сравнение разных попыток без такой связи легко приводит к ложному выводу: один тест прошёл, а ошибка относится к другому письму.
- Полный ответ сервера вместе с расширенным статусом и пояснением.
- Команда или этап, после которого появился отказ.
- Имя отвечавшего сервера и доступный идентификатор сессии.
- Перечень затронутых адресов: один, один домен или все получатели.
- Время последней успешной отправки и изменения перед сбоем.
- Состояние уведомления в очереди: ожидает, повторяется, принято или завершилось ошибкой.
Секреты в диагностический пакет не включайте. Скройте пароли, токены и данные AUTH, включая строки в Base64. RFC 4648 отдельно предупреждает: такое кодирование не обеспечивает конфиденциальность. Снимок экрана со скрытым полем пароля не делает безопасным полный журнал обмена.
Объём проверки зависит от масштаба. Если отказ получает только один адрес, начните с него и принимающего домена. Если после обновления перестали отправляться все уведомления, сравните способ входа, настройки транспорта и изменения приложения. Это направления расследования, а не готовый диагноз по одному совпадению.
Отделите сообщение CMS от ответа почтового сервера
Если панель пишет только «Не удалось отправить письмо», сначала выясните источник формулировки. Это может быть общее сообщение приложения, под которым скрывается разный результат. Не приписывайте ему код 550 или 535 по догадке. Включите предусмотренную системой диагностику на ограниченное время и воспроизведите одну согласованную попытку, затем верните обычный уровень журналирования.
Сопоставьте запись CMS с журналом транспорта и событиями провайдера. У одной попытки могут быть разные локальные идентификаторы, поэтому сохраните соответствие между ними. Если найден только отказ приложения до соединения с сервером, так и укажите в задаче. Если провайдер уже принял письмо, продолжайте поиск на следующем участке. Такое разделение помогает не выдавать общий текст интерфейса за реальный ответ удалённого сервера.
Краткая таблица SMTP-ошибок
Таблица помогает выбрать следующий шаг. Расширенные статусы в ней приведены как типичные сочетания, а не обязательный ответ каждого провайдера. Для конкретного инцидента приоритет имеют полный журнал, справочник отвечающей системы и обстоятельства отправки.
| Ответ | Что он может означать | Первое действие |
|---|---|---|
| 550, например 5.1.1 | Получатель не существует или адрес указан неверно | Сверить адрес и существование получателя |
| 550 с 5.7.x | Отказ по политике, идентификации или правам | Определить отклонивший сервер и требование из текста |
| 554 | Неудачная транзакция; причина зависит от этапа | Проверить расширенный статус и пояснение |
| 535, например 5.7.8 | Аутентификация не прошла | Сверить учётную запись и допустимый способ входа |
| 530 | Может требоваться вход или предварительный STARTTLS | Читать условие сервера, затем исправлять последовательность |
| 421, 450, 451, 452, 454 | Временное ограничение или сбой | Сохранить причину и проверить управляемые повторы |
Примеры различий есть в официальном справочнике ошибок Gmail. В частности, 554 5.6.0 там связан с некорректным форматом сообщения. Поэтому универсальная инструкция «554 означает спам» направляет проверку не туда.
Ошибка SMTP 550: сначала проверьте адрес и политику
Когда причина в получателе
Если расширенный статус и пояснение указывают на отсутствующий ящик, сравните адрес из задания с подтверждённым контактом. Проверьте опечатку, лишний пробел, устаревший домен и удалённый алиас. При недавнем переносе почты выясните, создан ли получатель на новой стороне. Не заменяйте адрес предположением: уточните его через действующий канал связи.
После подтверждения несуществующего адреса остановите бессмысленные повторные попытки для него. При этом сохраните сам заказ или обращение в бизнес-системе и назначьте дальнейшее действие сотруднику. Неудачная доставка уведомления не должна стирать информацию о том, кому и зачем нужно было написать.
Когда адрес существует, но отправка запрещена
Проверьте, не отклонил ли письмо ваш сервис из-за отсутствия права отправлять от указанного адреса или передавать почту по выбранному маршруту. Если отказ пришёл от принимающей стороны, изучите требование к отправителю или политике домена. Не открывайте сервер для неограниченной ретрансляции: правильное решение — разрешённая схема отправки.
У Mail код 550 применяется и при фильтрации сообщений, и при проблемах с характеристиками отправляющего узла; это видно в справочнике Mail для разработчиков. Следовательно, существование ящика не опровергает сам отказ. Исправление выбирают по его причине, а не по последней цифре кода.
Учебный разбор 550
Допустим, уведомление отправлялось на sales-old@example.com, а принимающий сервер отвечал 550 5.1.1 Recipient address rejected после RCPT TO. Администратор подтвердил, что алиас удалён, а актуальный контакт отдела другой. Команда исправляет источник адреса, выполняет согласованную проверку и сохраняет результат для этого получателя.
В таком сценарии менять SMTP-пароль не нужно: ошибка относилась к адресату. Но тот же вывод нельзя применять к 550 с пояснением о запрете отправителя. Если адрес поступает из нескольких шаблонов или настроек подразделений, проверьте все связанные места, чтобы ошибка не вернулась при другом типе уведомления.
Ошибка 554: выясните, почему отклонена транзакция
554 — общее обозначение неудачной транзакции; при приветствии соединения оно может означать отсутствие доступной SMTP-службы. Если ответ получен после передачи содержимого, посмотрите расширенный статус: проблема может относиться к формату, правам, подтверждению отправителя или правилам принимающей системы.
Например, в справочнике Amazon SES код 554 используется для отказа в разрешениях и для неподтверждённой идентичности отправки. Это условия SES, которые нельзя автоматически переносить на Яндекс или собственный сервер. Один код не определяет универсальный набор DNS-изменений.
Если пояснение указывает на формат сообщения
Разработчик должен проверить сформированное письмо до передачи: обязательные поля, адреса в заголовках, разделение заголовков и тела, кодирование и структуру вложений. Синтаксис заголовков описан в RFC 5322. Формируйте сообщение поддерживаемой почтовой библиотекой, а не склеиванием произвольных пользовательских строк.
Сравните проблемный шаблон с минимальным корректным письмом в согласованном тесте. Затем возвращайте изменяемые элементы по одному. Если без вложения отправка проходит, это повод исследовать его обработку, а не доказательство, что запрещены любые файлы. Не пытайтесь спрятать причину кодированием или переименованием вложения в обход политики сервиса.
Учебный разбор 554
Предположим, после изменения генератора уведомлений сервер возвращает условный ответ 554 5.6.0 Message format rejected после завершения передачи содержимого. Проверка показывает два заголовка Date, добавленных пользовательским кодом вместо одного. Разработчик исправляет генератор, проверяет итоговое сообщение и повторяет тот же сценарий с тестовыми данными.
Результат принимают по новой попытке и корректному письму у согласованного получателя. Простая замена темы здесь не исправила бы генератор. Если же ответ содержит явное указание на аутентификацию домена или ограничение аккаунта, проверять нужно соответствующее условие, а не разбирать формат наугад.
535 Authentication failed: проверьте способ входа приложения
В RFC 4954 ответ 535 5.7.8 связан с неверными или недостаточными данными аутентификации. Это отказ на этапе AUTH, до обычной передачи сообщения. Однако причина не сводится к опечатке в основном пароле: приложение могло использовать неподходящий механизм, отозванный доступ или другой аккаунт.
- Сверьте фактический сервер и учётную запись, которыми пользуется именно проблемное приложение.
- Уточните допустимый способ входа: пароль приложения, OAuth или другой разрешённый механизм.
- Проверьте разрешения для почтового клиента и ограничения организации.
- Проверьте, не истёк ли доступ и не был ли он отозван после изменений аккаунта.
- После исправления повторите один согласованный сценарий и сохраните результат без секретов.
Пароль веб-почты и доступ приложения — разные проверки
Успешный вход в браузере не подтверждает работоспособность SMTP. Например, Яндекс 360 описывает разрешение почтовых клиентов, отдельные пароли приложений и рекомендует OAuth, если программа его поддерживает. Настройки должны соответствовать конкретному продукту и правилам организации.
У Google пароли приложений требуют двухэтапной проверки и доступны не во всех конфигурациях аккаунта. После смены основного пароля они могут быть отозваны — это описано в справке Google о паролях приложений. Не отключайте защиту, чтобы заставить работать устаревший модуль; выберите поддерживаемый способ подключения.
Для OAuth проверьте аккаунт, разрешения, обновление токена и совместимость модуля. Документация Gmail по XOAUTH2 описывает применение токенов в SMTP AUTH. Токен от другой интеграции нельзя считать подходящим только потому, что он выдан тем же провайдером.
Учебный разбор 535
Допустим, после смены доступа почтового аккаунта очередь сайта получает 535 5.7.8 Authentication credentials invalid. Ответ условный: у конкретного сервиса расширенный статус может отличаться. Проверка показывает, что приложение использует отозванный секрет, хотя сотрудник успешно входит в веб-почту.
Администратор подтверждает разрешённый механизм, обновляет доступ в предназначенном хранилище и проверяет, что процесс отправки загрузил новую конфигурацию. Затем выполняет контрольную отправку и разбирает накопленные задания. Важен и последний шаг: изменение значения в панели не помогает, если фоновый процесс продолжает использовать прежние данные.
Не смешивайте этот случай с временной ошибкой аутентификации: например, 454 может указывать на временную проблему сервера. Также сохраняйте точный статус провайдера: текущая справка Gmail содержит 535 5.7.80, что не следует переписывать в журнале как 535 5.7.8.
Письмо сначала приняли, затем вернулся отчёт о недоставке
Отказ бывает немедленным, в SMTP-диалоге, или появляется позже отдельным уведомлением. Документация SES различает синхронные и асинхронные возвраты. Поэтому успешная передача своему сервису не завершает проверку всей доставки.
В отчёте DSN найдите сведения о конкретном получателе. Согласно RFC 3464, один отчёт может содержать несколько таких блоков. Для разбора особенно полезны следующие поля:
- Final-Recipient: адрес, к которому относится этот результат.
- Action: действие, например задержка или окончательный отказ.
- Status: расширенный статус доставки.
- Diagnostic-Code: исходное диагностическое пояснение, если оно доступно.
- Reporting-MTA: система, составившая отчёт.
- Remote-MTA: удалённый сервер, с которым связана попытка доставки, если поле присутствует.
Не путайте автора отчёта с системой, которая первоначально отклонила письмо. Справка Яндекс Почты также предлагает искать диагностический код и сервер, остановивший доставку. Сохраните исходный отчёт для ответственного администратора, а для обсуждения подготовьте обезличенную выдержку.
Для сайта выясните, куда поступают возвраты: в служебный ящик, журнал или систему событий провайдера. Если никто не проверяет этот канал, уведомления могут выглядеть отправленными при фактических отказах. Назначьте владельца обработки и свяжите возврат с исходным заданием, чтобы результат не потерялся между командами.
Когда повторять отправку и как учитывать частичный результат
Один отказ не описывает всех получателей
При нескольких адресатах сервер может отклонить один RCPT TO и принять другой. Поэтому сохраните результат по каждому адресу и итог передачи DATA. Не отмечайте всю рассылку одним общим флагом только по последней строке журнала. После исправления повторно обрабатывайте нужных получателей, учитывая, кому письмо уже было принято для доставки.
Тайм-аут после DATA создаёт неопределённость
Если содержимое передано, но окончательный ответ потерян, отправитель может не знать, принял ли сервер сообщение. Проблема повторной доставки в такой ситуации разобрана в RFC 1047. Сначала сопоставьте журнал приложения, идентификаторы и события провайдера. Не объявляйте письмо точно неотправленным только из-за отсутствия ответа на стороне сайта.
Для очереди храните связь с бизнес-событием, номера попыток и состояние каждого получателя. Один Message-ID полезен для поиска, но не обеспечивает универсальную защиту от дублей. Повторные бизнес-действия должны контролироваться приложением; письмо не должно заново создавать заказ или менять оплату только потому, что уведомление отправлено ещё раз.
Повторы должны иметь причину и предел
Временные отказы обрабатывайте с паузами и ограничениями выбранного транспорта. Учтите лимиты сервиса, возраст задания и необходимость вмешательства сотрудника. Не добавляйте ручные повторы поверх автоматически работающей очереди, пока не понятен её текущий статус. При окончательном отказе сначала устраните установленную причину.
Для просроченных уведомлений определите бизнес-правило. Старый код входа может быть уже бесполезен, а сообщение об изменении заказа — требовать актуальной информации. Исправление SMTP не означает, что нужно немедленно отправить всё накопленное без проверки. Отдельно выделите задания с неопределённым результатом и подтверждённые постоянные отказы.
Как проверить исправление и что написать в поддержку
Повторите именно тот сценарий, который давал сбой: тот же тип уведомления, согласованный получатель и сопоставимый размер сообщения. Используйте новые тестовые данные и уникальную метку. Зафиксируйте успешный этап, итог передачи и результат у получателя; ответ 250 на промежуточную команду не является подтверждением папки «Входящие».
В обращении укажите продукт и среду, точное время, сервер, полный обезличенный ответ, этап отказа и масштаб проблемы. Добавьте идентификатор сессии или сообщения, если он доступен, и опишите уже выполненную проверку. Формулировка «все письма не работают» менее полезна, чем конкретное наблюдение о трёх заданиях с одинаковым отказом AUTH после изменения доступа.
Кому передать задачу
Удобно назначать исполнителя по подтверждённому этапу. Ошибку формирования сообщения проверяет разработчик сайта. Разрешение аккаунта или способ входа — администратор почты. Ограничение исходящего соединения — команда хостинга или сети. Отказ политики принимающего домена может потребовать участия его администратора. Передавайте факты о своей попытке, а не требование отключить чужую защиту.
Если в работе участвуют несколько подрядчиков, назначьте одного ответственного за итоговую проверку. В его карточке должны сходиться сведения сайта, почтового сервиса и получателя. Иначе каждый участник способен подтвердить только свой этап, а рабочая доставка останется непроверенной. Согласуйте также срок следующего обновления и действие с важными уведомлениями, пока причина исправляется: кто свяжется с клиентом и где отметит результат.
Закройте инцидент после проверки очереди и зависших уведомлений. Сохраните причину, исправление, результат контрольной отправки и ответственного за дальнейший мониторинг. Отслеживайте новые ошибки по типам и доменам получателей: общий счётчик способен скрыть проблему одного важного адреса среди успешных отправок.
Частые вопросы
Ошибка SMTP 550 всегда означает неправильный email?
Нет. Нужны расширенный статус, полный текст и этап. Возможны проблемы адреса, прав, идентификации отправителя или политики приёма. Не удаляйте действующий контакт из базы только по числу 550.
Можно ли исправить 554 заменой темы письма?
Только если проверка установила причину, связанную с содержимым, и изменение действительно её устраняет. При ошибке формата, прав или подтверждения отправителя тема не решит основную проблему. Не подбирайте формулировки для обхода фильтра.
Почему появляется 535, если пароль точно правильный?
Приложению может требоваться другой способ входа, отдельный секрет или разрешение организации. Проверьте, какой аккаунт и конфигурацию использует работающий процесс. Успешный вход в браузере проверяет другой маршрут.
Нужно ли менять DNS при любой ошибке SMTP?
Нет. DNS проверяют, когда ответ или маршрут указывает на домен, разрешённые источники либо аутентификацию письма. Ошибку адреса получателя, отозванный доступ или сломанный формат исправляют на соответствующем уровне.
Почему письмо пришло дважды после ошибки?
Проверьте автоматическую очередь и ручные повторы, особенно при обрыве после DATA. Сервер мог принять первое сообщение, а приложение не получить подтверждение. Сопоставьте идентификаторы и время обеих попыток.
После устранения SMTP-ошибки сохраните для команды причину отказа и результат контрольной доставки, затем повторяйте проверку важных уведомлений после изменений сайта. Регулярный контроль доступности сайта дополняет эту работу: оцените SiteGuard как сервис мониторинга для вашего проекта.