Ответ почтового сервера: чек-лист для диагностики SMTP

Настоящая причина обычно находится в SMTP-логе — в последовательности команд, кодах ответа и расширенном статусе вроде 4.4.2 или 5.7.1.

Ответ почтового сервера — это не декоративная строка в журнале отправки, а технический маршрут, по которому можно восстановить всю историю сбоя: установилось ли соединение, прошла ли аутентификация, принял ли сервер адрес получателя, дошло ли письмо до команды DATA и на каком именно шаге возник отказ.

В SMTP используются трехзначные коды, стандартизированные RFC 5321. Первая цифра сразу задает тактику: 2xx означает успех, 3xx — необходимость продолжить диалог, 4xx — временный сбой, а 5xx — постоянную ошибку. Но одного первого кода недостаточно: для рабочего решения нужно читать весь ответ вместе с расширенным статусом и контекстом SMTP-сессии.

Как читать SMTP-сессию: от EHLO до DATA

SMTP — это последовательный диалог между отправляющим и принимающим сервером. В логах он выглядит как чередование команд клиента и ответов сервера. Если анализировать только последнюю строку, можно пропустить исходную причину сбоя.

Типовая сессия проходит несколько этапов.

1. Установка соединения

При успешном подключении сервер обычно отвечает кодом 220. Это означает, что сервис готов принимать команды. Само по себе наличие 220 еще не говорит, что письмо будет принято: это только старт транспортного диалога.

Дальше отправляющая сторона выполняет приветствие:

• EHLO — расширенное приветствие SMTP-клиента;
• HELO — базовый вариант для старых или ограниченных сценариев.

В ответ сервер сообщает, какие возможности поддерживает. Среди них могут быть STARTTLS, AUTH, ограничения размера сообщения и другие расширения. Для диагностики полезно зафиксировать именно этот участок лога: если сервер не принимает EHLO, проблема находится еще до аутентификации и передачи письма.

Код 250 на этом этапе означает, что команда выполнена и сервер готов перейти к следующему шагу. Но это не гарантия доставки во «Входящие» и не подтверждение, что письмо уже прошло фильтры. Сервер лишь успешно завершил конкретный этап обработки.

2. Защищенное соединение

Если отправка выполняется через STARTTLS, клиент сначала устанавливает обычное SMTP-соединение, а затем предлагает перейти на шифрованный канал. После успешного TLS-обмена команды продолжаются уже внутри защищенной сессии.

Сбой здесь может быть связан с:

• неверной настройкой TLS;
• несовместимой версией протокола;
• проблемой сертификата;
• тем, что клиент ожидает STARTTLS, а сервер его не объявляет;
• тем, что выбран порт или режим шифрования не соответствует настройкам.

На этом этапе важно не смешивать режимы. STARTTLS обычно используется как расширение на порту 587, а SMTPS — на порту 465. Порт 25 чаще применяется для межсерверной передачи и во многих сетях ограничивается провайдерами. 2525 может использоваться как альтернативный порт клиентской отправки, если стандартный порт недоступен.

3. Аутентификация

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

Код 535, включая вариант 535 5.7.8, обычно указывает на неудачную аутентификацию. Возможные причины:

• неверный логин;
• неправильный пароль;
• попытка авторизации не тем пользователем;
• включенная двухфакторная аутентификация, при которой нужен пароль приложения;
• неподдерживаемый или запрещенный метод аутентификации;
• подключение к серверу, где данный ящик не имеет права отправлять почту.

Здесь не работает стратегия «попробовать отправить еще раз». Повторная попытка с теми же параметрами только увеличит шум в логах и может привести к дополнительным ограничениям. Сначала нужно сверить учетную запись, SMTP-хост, порт, режим шифрования и способ авторизации.

4. MAIL FROM и RCPT TO

После успешной аутентификации клиент сообщает отправителя командой MAIL FROM, затем передает адрес получателя через RCPT TO.

Эти команды разделяют две разные зоны диагностики:

• ошибка на MAIL FROM чаще связана с правами отправителя, политиками домена или синтаксисом адреса;
• ошибка на RCPT TO указывает на проблему с ящиком получателя, маршрутизацией, доменом или политикой приема.

Например, ответ 450 или 550 после RCPT TO означает не то же самое, что такой же код после DATA. Команда и контекст имеют значение.

Синтаксическая ошибка может возникнуть из-за некорректного формата адреса, лишних символов или проблем в формировании SMTP-команд. Ошибка политики — из-за ограничений сервера, проверки отправителя, антиспама или требований к аутентификации домена.

5. DATA и содержимое письма

После принятия отправителя и получателя сервер обычно отвечает 354 — это промежуточный статус: можно начинать передачу тела сообщения. Клиент передает заголовки и содержимое письма, после чего сервер возвращает финальный ответ, часто 250.

Именно здесь могут сработать проверки содержимого, размера, вложений и репутации отправителя. Поэтому успешный 250 после EHLO не равен успешному 250 после DATA. В первом случае сервер принял техническую команду, во втором — завершил конкретный этап приема сообщения.

Код 250 подтверждает успешное выполнение SMTP-операции, но не обещает попадание письма во «Входящие». Для доставляемости важны дальнейшая фильтрация, репутация и политики принимающей стороны.

Для рабочего разбора в логе нужно искать минимум такую цепочку:

1. ответ 220 после подключения;

2. результат EHLO или HELO;

3. объявленные сервером возможности, включая STARTTLS и AUTH;

4. результат TLS-перехода;

5. ответ на аутентификацию;

6. ответ на MAIL FROM;

7. ответ на каждый RCPT TO;

8. статус после DATA;

9. полный текст ошибки и расширенный код состояния.

Если в журнале отсутствует один из этапов, это тоже диагностический сигнал. Например, если нет RCPT TO, письмо не дошло до проверки адресата: сбой произошел раньше, вероятно на аутентификации или принятии отправителя.

Классификация кодов: первая цифра задает тактику

Три цифры SMTP-кода читаются не как случайный идентификатор. Первая определяет класс ответа, вторая уточняет область, третья конкретизирует операцию.

Коды 2xx: успех конкретного шага

На практике чаще всего встречаются:

• 220 — сервис готов;
• 221 — сервер закрывает канал передачи;
• 250 — операция выполнена успешно.

Если сервер вернул 250 после MAIL FROM, это означает принятие команды с указанным отправителем. Если 250 пришел после RCPT TO, сервер принял адрес получателя на данном этапе. Если 250 вернулся после DATA, сообщение принято сервером к дальнейшей обработке.

Это разные события, хотя код одинаковый. В дашборде ESP их нельзя сводить в одну метрику «доставка успешна». Для анализа воронки лучше разделять:

• соединение;
• аутентификацию;
• принятие отправителя;
• принятие получателя;
• прием сообщения;
• последующую доставку и поведение пользователя.

Коды 3xx: сервер ждет продолжения

Код 354 появляется перед передачей тела письма. Он не означает ошибку. Это приглашение отправить данные после завершения командной части SMTP-диалога.

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

Коды 4xx: временный сбой и soft bounce

Класс 4xx обычно означает, что сервер не может завершить операцию сейчас, но ситуация потенциально изменится. Поэтому такие ответы называют временными ошибками или soft bounce.

Типовые варианты:

• 421 — сервис временно недоступен;
• 450 — ящик временно недоступен;
• 451 — локальная ошибка обработки;
• 452 — недостаточно места или временный ресурсный лимит.

Повторная отправка допустима, но она должна быть управляемой. В массовых рассылках повтор не должен превращаться в бесконечный цикл: система должна учитывать число попыток, интервалы и финальный статус адреса.

Перед повтором полезно определить, что именно было временным:

• соединение с сервером;
• обработка команды;
• доступность ящика;
• лимит ресурсов;
• локальная ошибка принимающей системы.

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

4xx — не индульгенция на бесконечные ретраи. Повтор должен быть частью политики доставки, а не попыткой скрыть проблему в статистике.

Коды 5xx: постоянная ошибка и hard bounce

Код 5xx означает, что операция отклонена как постоянная. Повторять ее без изменения условий обычно бессмысленно: сервер снова вернет отказ, а отправляющая система будет накапливать hard bounce и ухудшать качество базы.

Частые примеры:

• 500 — синтаксическая ошибка команды;
• 501 — ошибка синтаксиса параметров;
• 503 — неверная последовательность команд;
• 535 — ошибка аутентификации;
• 550 — ящик или адрес недоступен.

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

Расширенные статусы RFC 3463: где находится причина

Базовый код отвечает на вопрос «какого класса проблема». Расширенный статус помогает понять «почему». Он записывается в формате класс.тема.детали, например 5.7.1 или 4.4.2.

В диагностике удобно читать его по частям:

• первая цифра повторяет класс: временная или постоянная ошибка;
• вторая описывает тематическую область;
• третья уточняет конкретную причину.

Что может означать 4.4.2

Статус 4.4.2 относится к временному сбою в зоне соединения или доставки. В зависимости от конкретной системы он может указывать на проблемы коммуникации между серверами, тайм-аут или невозможность завершить транспортный обмен.

Точный текст зависит от почтового сервиса и его внутренних настроек. Поэтому нельзя интерпретировать расширенный код изолированно. Сопоставьте его с:

• временем возникновения;
• количеством попыток;
• этапом SMTP-сессии;
• доменом получателя;
• доступностью порта;
• соседними строками лога.

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

Что может означать 5.7.1

Статус 5.7.1 часто связан с политикой безопасности, отклонением сообщения или неудачной аутентификацией домена. Среди возможных причин:

• SPF не подтверждает разрешенный сервер отправки;
• DKIM-подпись отсутствует или не проходит проверку;
• DMARC-политика домена не согласуется с результатами SPF и DKIM;
• сервер считает отправителя подозрительным;
• письмо нарушает правила принимающей системы;
• отправка выполняется без нужной авторизации или с неподходящего IP.

Здесь нельзя лечить симптом, меняя тему письма или увеличивая частоту повторов. Сначала нужно проверить инфраструктурный слой:

• какой домен стоит в MAIL FROM;
• какой домен указан в заголовке From;
• через какой сервер и IP уходит сообщение;
• подписывается ли письмо DKIM;
• опубликованы ли корректные DNS-записи;
• совпадает ли фактический маршрут с заявленными политиками.

Если сбой затрагивает массовую рассылку, полезно посмотреть не только общий bounce rate, но и разрезы по доменам получателей, потокам отправки и IP. Одна и та же ошибка в Gmail, Microsoft 365 или другом сервисе может иметь разные текстовые пояснения, поэтому в отчетах нужно сохранять полный ответ сервера, а не только трехзначный код.

Диагностика аутентификации и защитных политик

Ошибки SMTP часто выглядят как проблема почтового клиента, хотя фактическая причина находится в DNS или настройках домена. Особенно это заметно при кодах 535 и 550 5.7.1.

Если сервер возвращает 535

Проверяйте параметры в такой последовательности:

1. Уточните SMTP-хост, к которому подключается приложение.

2. Сверьте порт: 587, 465 или альтернативный 2525.

3. Проверьте соответствие режима шифрования выбранному порту.

4. Убедитесь, что логин передается в полном формате, если сервер требует полный email-адрес.

5. Проверьте пароль без ручного копирования лишних пробелов.

6. Если включена двухфакторная аутентификация, создайте пароль приложения, когда это предусмотрено сервисом.

7. Убедитесь, что ящику разрешена отправка через SMTP.

8. Сравните результат подключения из приложения и из административного интерфейса почтовой системы.

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

Если сервер возвращает 550 5.7.1

Здесь нужно разделить две гипотезы: отказ из-за доменной аутентификации и отказ из-за фильтрации.

Для первой гипотезы смотрим:

• SPF-запись домена;
• DKIM-подпись;
• DMARC-политику;
• соответствие доменов в заголовках;
• фактический IP отправляющего сервера;
• наличие промежуточного сервиса рассылки.

Особенно часто ломается связка после смены ESP или почтового хостинга. В DNS остается старый SPF, DKIM-ключ не опубликован для нового селектора, а письма уже уходят с другого сервера. В результате домен формально существует, SMTP-сессия устанавливается, но принимающая сторона не может подтвердить право отправки.

Для второй гипотезы анализируем:

• долю отказов по конкретному домену получателей;
• динамику после изменения шаблона или сегмента;
• объем и частоту отправки;
• репутацию IP и домена;
• наличие резкого роста жалоб и неактивных адресов;
• результаты прогрева домена, если инфраструктура новая.

Не стоит смешивать SMTP-отказ и низкий опенрейт. Если сервер вернул 250, это еще не означает попадание во «Входящие», но и не является SMTP-ошибкой. Доставляемость и вовлеченность измеряются на разных слоях:

• SMTP-коды показывают реакцию сервера на транспорт и прием;
• bounce rate отражает отказы;
• опенрейт зависит от попадания в папку, загрузки изображений и поведения клиента;
• кликрейт и конверсия показывают результат коммуникации.

Чек-лист анализа логов SMTP

Рабочий разбор лучше проводить в одном порядке. Это снижает риск перескочить к контенту, когда проблема находится в соединении или DNS.

Шаг 1. Зафиксировать исходные данные

Сохраните:

• адрес отправителя;
• адрес или домен получателя;
• дату и время попытки;
• идентификатор сообщения;
• исходящий IP;
• SMTP-хост;
• выбранный порт;
• полный текст ответа;
• число повторных попыток.

Без этого сложно сравнивать инциденты и строить когорты по доменам. В интерфейсе ESP обычно виден только сокращенный статус, поэтому для инфраструктурного разбора нужен серверный лог или расширенный отчет доставки.

Шаг 2. Найти первый код ошибки

Последний ответ не всегда является первопричиной. Например, после разрыва соединения система может записать общий статус недоставки, хотя исходная проблема появилась при TLS или аутентификации.

Ищите первую ошибку в последовательности:

1. подключение;

2. EHLO или HELO;

3. TLS;

4. AUTH;

5. MAIL FROM;

6. RCPT TO;

7. DATA;

8. финальное подтверждение.

Первый отказ обычно лучше объясняет, почему сессия не продолжилась.

Шаг 3. Определить класс ошибки

• 2xx — этап завершен;
• 3xx — сервер ожидает продолжения;
• 4xx — планировать контролируемый повтор;
• 5xx — искать постоянную причину и не зацикливать отправку.

Этот шаг задает направление, но не закрывает диагностику. Для 4xx нужно понять, временный ли сбой действительно краткосрочный. Для 5xx — выяснить, что изменить: адрес, учетные данные, DNS, маршрут или параметры сообщения.

Шаг 4. Проверить этап SMTP-сессии

Одинаковый код на разных командах означает разные риски. Отказ на AUTH — это не проблема ящика получателя. Отказ на RCPT TO — не обязательно проблема шаблона. Ошибка после DATA уже требует анализа содержимого, размера, вложений и политик фильтрации.

Шаг 5. Сопоставить ошибки с сегментами

В маркетинговой инфраструктуре нельзя смотреть на среднее значение по всей базе. Разложите ошибки:

• по домену получателя;
• по отправляющему домену;
• по IP;
• по конкретному SMTP-потоку;
• по типу кампании;
• по новым и активным адресатам;
• по времени и волнам отправки.

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

Шаг 6. Проверить изменения перед инцидентом

Сверьте, что происходило незадолго до роста ошибок:

• сменился ESP;
• добавился новый IP;
• изменился SMTP-порт;
• обновился пароль или включилась двухфакторная аутентификация;
• изменились SPF, DKIM или DMARC;
• начался прогрев домена;
• увеличился объем рассылки;
• в базу попал новый источник адресов.

Для каждой причины сформулируйте гипотезу и проверку. Например: «после миграции DKIM-подпись формируется новым сервисом, но DNS содержит старый ключ». Проверка — сравнить селектор в заголовке письма с опубликованной записью. Такой подход быстрее, чем последовательно менять все настройки.

Порт 25, 465, 587 и 2525: какой маршрут выбирать

Выбор порта влияет не только на успешность подключения, но и на архитектуру отправки.

Для корпоративного приложения или CRM порт 25 обычно не должен быть первым выбором, если сервис предоставляет submission-порт. Он исторически используется для межсерверного обмена, а исходящие подключения к нему могут ограничиваться сетью или хостингом.

587 часто подходит для авторизованной отправки от имени ящика: клиент подключается, запускает STARTTLS, затем проходит AUTH. Ошибки в этой схеме обычно хорошо видны в логе, потому что каждый этап отделен.

465 использует TLS уже при установлении соединения. Если приложение настроено на STARTTLS, а сервер ожидает SMTPS, можно получить ошибку подключения еще до команды EHLO.

2525 не является универсальной заменой для любого SMTP-сервера. Это альтернативный вариант только тогда, когда его поддерживает конкретный провайдер или ESP. Проверять нужно не название порта, а документацию и фактическую конфигурацию сервиса.

Типовые ошибки, которые затягивают диагностику

Повторная отправка при коде 5xx

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

Анализ только последней строки лога

Финальный статус может быть следствием более раннего сбоя. Без всей SMTP-сессии мы видим симптом, но не маршрут его появления.

Подмена SMTP-диагностики метриками кампании

Опенрейт и кликрейт не объясняют, почему сервер вернул 535. Эти показатели нужны для оценки результата рассылки, а SMTP-коды — для проверки инфраструктуры и приема сообщения.

Игнорирование расширенного статуса

550 без 5.7.1, 5.1.1 или другого уточнения — слишком широкий сигнал. Сохраняйте полный ответ сервера, включая текстовое пояснение. При этом не переносите формулировку одного провайдера на все остальные: внутренние правила и тексты ответов отличаются.

Проверка DNS без сверки фактического маршрута

Можно иметь корректную SPF-запись и все равно получать отказ, если письмо уходит с IP, которого в SPF нет. Проверяйте не только DNS, но и реальный SMTP-сервер, IP, DKIM-селектор и домены в заголовках.

Отсутствие раздельных статусов для разных потоков

Транзакционные письма, массовые кампании и сообщения от корпоративных ящиков могут идти через разные IP, домены и настройки. Сводный bounce rate скрывает проблему. Раздельные дашборды дают более точную картину и помогают локализовать инцидент.

Для команд, которые регулярно разбирают доставку, полезно держать под рукой справочник SMTP-кодов и расширенных статусов и использовать его как базу для классификации ответов. Но финальное решение все равно принимается по конкретному логу: стандарт объясняет структуру кода, а серверный контекст показывает реальную причину.

Как превратить логи в управляемый процесс

Разовая ручная проверка помогает погасить инцидент. Системный процесс дает профит на дистанции: меньше повторных отправок, быстрее реакция на миграции и понятнее влияние инфраструктурных изменений на конверсию.

Минимальный набор автоматизации выглядит так:

• хранить полный SMTP-ответ, а не только короткую категорию;
• отделять soft bounce от hard bounce;
• сохранять команду, на которой произошел сбой;
• группировать ошибки по доменам и IP;
• строить алерты на резкий рост 4xx, 5xx, 535 и 550 5.7.1;
• исключать адреса с постоянными отказами из повторных попыток;
• вести историю изменений DNS, SMTP-настроек и отправляющей платформы;
• сравнивать метрики до и после релиза или миграции;
• проверять новые настройки на ограниченном сегменте до масштабирования.

Полезный дашборд диагностики должен показывать не только количество ошибок. В него стоит вынести:

• долю успешных SMTP-сессий;
• долю ошибок по классам 4xx и 5xx;
• распределение кодов по этапам AUTH, MAIL FROM, RCPT TO, DATA;
• топ доменов с отказами;
• динамику 535 после изменения учетных данных;
• динамику 550 5.7.1 после изменений SPF, DKIM или DMARC;
• количество повторных попыток;
• долю адресов, переведенных в постоянный bounce.

Так мы видим не просто «почта не доставилась», а точку, где теряется конверсия: на соединении, при авторизации, при приеме адресата или при политической проверке сообщения.

Финальная последовательность действий

Если ответ почтового сервера указывает на сбой, действуйте по короткой, но полной последовательности:

1. Сохраните полный лог SMTP-сессии и расширенный код состояния.

2. Найдите первый отказ, а не только финальную строку.

3. Определите класс ошибки: 4xx или 5xx.

4. Уточните команду, на которой возник сбой.

5. Проверьте порт, TLS и доступность SMTP-хоста.

6. Для 535 перепроверьте логин, пароль, 2FA и права отправки.

7. Для 550 5.7.1 проверьте SPF, DKIM, DMARC, IP и фактический маршрут.

8. Разложите проблему по доменам, IP и потокам отправки.

9. Для 4xx настройте ограниченный повтор с понятной политикой.

10. Для 5xx сначала измените причину отказа, затем запускайте новую отправку.

11. После исправления сравните SMTP-метрики с доставляемостью и конверсией кампании.

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