Hard bounce и soft bounce: что это, коды отказов и норма bounce rate

Bounce (возврат) означает, что сервер получателя отказался доставить письмо. В отчёте сервиса рассылок такие письма делятся на hard bounce и soft bounce, и от этого деления зависит, удалять адрес или подождать.

Отказ приходит одним из двух путей. Чаще сервер отвечает ошибкой прямо во время SMTP-сессии, и письмо не принимается вовсе. Бывает и иначе: сервер письмо принял, а доставить не смог. Тогда отправитель получает отдельное письмо о недоставке, DSN. В нём есть поле Action: delayed значит «пока не доставлено, пробую дальше», failed значит «не доставлено окончательно». Письмо «Delivery delayed» ещё не отказ.

Hard bounce: постоянный отказ

Hard bounce (жёсткий возврат) выдаёт ответ с кодом 5xx. RFC 5321 называет такие ответы постоянными: клиенту не следует повторять тот же запрос. Если в отчёте написано «hard bounced», сервер получателя сказал «нет», и повторная отправка ничего не изменит.

Откуда берётся

• Ящика нет. Сотрудник уволился, ящик удалили, или при подписке опечатались: gmial.com вместо gmail.com. Сервер отвечает 550 5.1.1.
• Домена нет или он не принимает почту. Компания закрылась, домен не продлили. Если у домена опубликован Null MX (RFC 7505), сервер отправителя отказывает сразу, кодом 556 5.1.10, и даже не ставит письмо в очередь.
• Адрес записан с ошибкой синтаксиса: пробел, две «@», запрещённые символы. Ответ 553.
• Ящик отключён навсегда (5.2.1).

Адрес с таким отказом убирают из рассылки сразу, после первого же случая. Этого ждут и почтовики, и сервисы отправки. Yahoo пишет, что письмо с ошибкой 5xx повторять не нужно, а у владельца списка должно быть правило удаления таких адресов. Amazon SES пишет в FAQ, что отскочившие адреса нужно немедленно исключить и больше на них не отправлять.

Ответ 5.7.1 тоже постоянный, но означает, что письмо отклонил фильтр или политика сервера, а 5.3.4, что письмо слишком большое. Ящик в обоих случаях жив, и удаление адреса ничего не исправит. Причину ищут у себя: в чёрных списках, в настройках SPF, DKIM и DMARC, в размере вложений.

Soft bounce: временный отказ

Soft bounce (мягкий возврат) выдаёт ответ с кодом 4xx. Адрес, скорее всего, существует, но сейчас письмо принять нельзя. По RFC 5321 ответ относится к временным, если тот же запрос может пройти при повторе без изменений.

Почему сервер просит подождать

• Ящик переполнен (452, расширенный код 4.2.2). Если человек почистит почту, письмо дойдёт.
• Сервер получателя перегружен или на обслуживании (421).
• Грейлистинг: незнакомому отправителю первый раз отказывают временной ошибкой, обычно 450 или 451, и принимают при повторе.
• Отправитель превысил лимит скорости, и сервер просит сбавить темп.
• Ящик временно заблокирован правилами сервера. Такой случай RFC 5321 прямо упоминает в описании кода 450.

Письмо с временной ошибкой не пропадает. Сервер отправителя ставит его в очередь и повторяет попытки. RFC 5321 требует ждать между попытками, как правило не меньше 30 минут, и продолжать не меньше четырёх-пяти дней, прежде чем сдаться. Если за это время письмо так и не приняли, отправитель получает DSN с failed, и в отчёте мягкий отказ превращается в жёсткий. Сервисы рассылок обычно держат окно повторов короче и настраивают его сами.

Если адрес отскочил один раз, его оставляют в базе. Если он отскакивает рассылку за рассылкой, решает счётчик. Mailchimp, например, допускает семь мягких отказов у контакта без активности и до пятнадцати у того, кто раньше проявлял активность как подписчик. После этого адрес считается жёстким отказом и уходит из аудитории.

Чем hard bounce отличается от soft bounce

Как читать код отказа SMTP

В ответе сервера два кода. Первый, трёхзначный, задан в RFC 5321. Второй, вида 5.1.1, называется расширенным кодом статуса (RFC 3463) и уточняет причину. Вот как Gmail отвечает на письмо несуществующему получателю:

550-5.1.1 The email account that you tried to reach does not exist.

Основные коды ответа

Оговорка про 552 взята из самого RFC 5321. Старый стандарт по ошибке назначал этот код ситуации «слишком много получателей», и клиентам велено считать такой 552 временной ошибкой. Правильный код для неё 452. А 550 в стандарте описан шире, чем «ящика нет»: он же приходит при отказе по политике. Поэтому решение принимают по расширенному коду и тексту ответа, а не по одной первой цифре.

Расширенные коды, которые стоит различать

В отчётах иногда пишут «ошибка 571». Стандарт такого кода не описывает, но некоторые серверы его отдают; читать его стоит как 5.7.1.

Норма bounce rate и как её считать

Bounce rate (процент отказов) считают так: число возвратов делят на число отправленных писем и умножают на 100. Отправили 2 000 писем, вернулось 30, получается 1,5%.

bounce rate = возвраты ÷ отправлено × 100%

Дальше начинаются расхождения, потому что сервисы считают по-разному. Amazon SES, например, включает в показатель только жёсткие отказы и только на домены, которые вы не подтверждали. Переполненный ящик или блокировка IP в его bounce rate не попадают. Считается показатель не за фиксированный период, а по «репрезентативному объёму» писем, своему для каждого отправителя. Сравнивать цифры из разных сервисов напрямую поэтому нельзя.

Какой процент считать нормой? Единого ответа нет: почтовые провайдеры свои пороги по отказам не публикуют, и Mailchimp объясняет это тем, что пороги меняются, а спамерам лишнего знать не нужно. Из открытых цифр самые конкретные у Amazon SES:

• держать bounce rate ниже 2%;
• от 5% аккаунт ставят на проверку;
• от 10% отправку могут приостановить до исправления.

Эти пороги можно брать за ориентир и в других сервисах. Для транзакционных писем планка ниже: адрес только что ввёл живой человек, и заметная доля отказов означает, что в форме регистрации нет проверки адреса.

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

Почему отказы бьют по репутации

Высокий процент отказов почтовики и антиспам-организации используют как признак плохой практики отправителя. Так пишет Amazon SES, и там же сказано, что последствие бывает простым: письма начинают уходить в спам, а не во входящие. Отправитель, который пишет на несуществующие адреса, явно не знает, откуда у него база.

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

Как обрабатывать отказы после рассылки

1. Выгрузите отказы и разделите по коду: 5xx и 4xx.
2. Адреса с 5.1.1, 5.1.2, 5.1.10 и 553 отправьте в список исключений (suppression list) навсегда.
3. Отказы 5.7.1 и 5.3.4 не удаляйте вслепую. Посмотрите, у какого провайдера они собрались, и разберитесь с репутацией или размером письма.
4. Для 4xx ведите счётчик по адресу. Серия мягких отказов в нескольких рассылках подряд означает, что ящик заброшен.
5. Посчитайте bounce rate кампании и сравните с прошлыми.

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

Автоответ «я в отпуске» по RFC 3834 обычное письмо с заголовком Auto-Submitted: auto-replied. Считайте такие письма отдельно от отказов, иначе они засорят статистику.

Как снизить bounce rate

• Проверяйте базу до отправки. Валидатор находит несуществующие ящики и домены без почты раньше, чем они превратятся в жёсткие отказы. В отчёте uChecker адреса разложены на валидные, невалидные и неизвестные, у отбракованных указана причина.
• Проверяйте адрес прямо в форме регистрации. Amazon SES советует ещё и просить ввести адрес дважды.
• Включите double opt-in: письмо с подтверждением до опечатки просто не дойдёт.
• Не покупайте и не арендуйте базы. Это первый пункт в списке Amazon SES.
• Старую базу, на которую давно не писали, отправляйте небольшими частями и только после проверки.