SMTP-ошибки и баунсы: как читать коды и что делает SaM oTPravil

Bounce (баунс, отлуп, отскок) — ответ почтового сервера о том, что письмо не доставлено получателю. В логах и отчётах он выглядит как SMTP-код и текстовое сообщение — например, 550 Spam Message Rejected или 451 Ratelimit exceeded for mailbox.

При отправке через SaM oTPravil ошибка может появиться на разных этапах:

1. До приёма письма нашим сервером — например, адрес в стоп-листе (550 bounced check filter).
2. При доставке на сервер получателя — ответ receiver-MTA: временная ошибка 4xx или постоянная 5xx.
3. На стороне почтового ящика отправителя — если вы подключаете публичный SMTP (Mail.ru, Gmail, Яндекс) к CRM или helpdesk: аутентификация или лимиты режут отправку ещё до нашего транспорта.

Общая логика кодов SMTP описана в глоссарии Mailganer и в RFC 5321. Разбор конкретных bounce-ответов — в справочнике ошибок недоставки.

По первой цифре SMTP-кода ошибки делятся на временные и постоянные. Та же схема используется в статье Mailganer про ошибки недоставки:

Важно: не все провайдеры строго следуют RFC. Например, переполненный ящик у большинства сервисов — 452, а у Яндекса встречается 552 5.2.2 Mailbox size limit exceeded. Смотрите полный текст ответа в логе, а не только цифру.

Кратко о цепочке доставки:

1. Приём письма. Если адрес в стоп-листе, сервер сразу вернёт 550 bounced check filter — письмо не уйдёт на доставку. Подробнее: стоп-листы SMTP.
2. Передача на сервер получателя. Если сервер ответил 4xx, включается политика ретраев (см. ниже).
3. Постоянная недоставка (5xx) или исчерпание ретраев по 4xx — письмо попадает в отчёт «Недоставки» в личном кабинете SMTP. Адрес может быть добавлен в стоп-лист; для софт-баунса в ответе указывается ttl_date — дата выхода из стоп-листа.
4. Уведомления. О событиях недоставки можно получать через вебхуки или смотреть в логах отправки.

Статус Completed в истории отправок означает, что письмо принято и отправлено с нашего сервера; строка ниже — ответ сервера получателя (250 ok — доставлено, иначе — код ошибки).

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

Первые 2 часа — повторные попытки каждые 5 минут.
Следующие 16 часов — интервал постепенно увеличивается: старт 5 минут, коэффициент 1.1.
Оставшееся время до 24 часов — повторные попытки каждые 6 часов.

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

После неудачной доставки из-за временной ошибки адрес может попасть в стоп-лист. В ответе сервера и в личном кабинете для таких случаев указывается параметр `ttl_date` — дата, когда адрес снова станет доступен для отправки.

• Если выход из стоп-листа невозможен, в ответе будет `ttl_date: 0`.
• Обычно с ttl_date ничего делать не нужно: после даты адрес автоматически вернётся в отправки.

Подробнее: Особенности интеграции с SMTP — дата выхода из стоп-листа и раздел «Стоп-листы» в личном кабинете.

1. Личный кабинет SMTP → Недоставки — отчёт за период с текстом ошибки по каждому адресу. Обзор разделов
2. Личный кабинет SMTP → Отправки — история по message id, статусы и полный лог SMTP-сессии (кнопка «Показать»).
3. Личный кабинет SMTP → Стоп-листы — поиск адреса, причина, ttl_date. Стоп-листы SMTP
4. Вебхуки — автоматическое оповещение о недоставке. Вебхуки в SMTP
5. API — документация

Если код ошибки непонятен — напишите в поддержку с email получателя, датой отправки и полным текстом ответа сервера.

Текст (T004): Используйте эту статью как хаб. Ниже — ссылки на разборы по провайдерам и типовым кодам.

Лимиты и политики почтовых провайдеров (блог)