Высокий показатель отказов в email рассылке: как найти и устранить причины
После отправки кампании в статистике появляется неприятная цифра: часть писем не доставлена, bounce rate вырос, а рядом с ним — тревожное ощущение, что домен вот-вот потеряет репутацию.

Высокий показатель отказов в email-рассылке: как найти и устранить причины
В такой момент легко сделать лишнее: удалить половину базы, срочно сменить сервис рассылок или повторно отправить ту же кампанию всем, кто «не получил». Обычно ни один из этих шагов не решает проблему сам по себе.
Высокий bounce rate в email-рассылке — не диагноз, а сигнал, что в цепочке доставки что-то нарушилось. Иногда это старая база с удалёнными ящиками. Иногда — слишком резкий объём отправки на Gmail или Yahoo. Иногда письма упираются в неверно настроенный SPF, слабый DKIM, отсутствующий DMARC, тяжёлое вложение или сомнительную ссылку в шаблоне. А иногда показатель выглядит страшнее, чем есть, потому что разные сервисы считают отказы по-разному.
Я в таких ситуациях не начинаю с общего процента. Сначала возвращаю себе спокойный фокус: смотрю на тип SMTP-ответа, домен получателя, источник адресов и характер конкретной кампании. Это превращает хаотичную цифру в понятную задачу.
Bounce rate полезен не сам по себе, а как карта: искать нужно не «высокий процент», а место, где доставка перестала быть предсказуемой.
Почему общий bounce rate может вводить в заблуждение
Bounce rate обычно считают как долю недоставленных сообщений от всех попыток отправки. Но одинаковая цифра в двух ESP вовсе не означает одинаковую ситуацию.
Например, в Amazon SES показатель bounce rate включает только постоянные отказы — hard bounce — при отправке на неподтверждённые домены. Переполненный ящик, временная недоступность сервера или блокировка IP могут не попасть в эту метрику. В другом сервисе статистика может объединять больше типов ошибок. Поэтому сравнивать 3% в одной платформе и 3% в другой без расшифровки бесполезно: визуальный шум есть, а ясности нет.
В качестве внутренних ориентиров можно держать в голове рекомендации самих платформ:
| Ориентир | Что означает |
|---|---|
| Менее 5% hard bounce | Практическая рекомендация Twilio SendGrid |
| Менее 2% bounce rate | Целевой ориентир Amazon SES |
| 5% bounce rate в Amazon SES | Аккаунт могут отправить на проверку |
| 10% и выше в Amazon SES | Возможна приостановка дальнейшей отправки |
| Менее 0,3% жалоб на спам | Рекомендация Google и Yahoo для массовых отправителей |
Это не универсальные санкционные нормы для любого сервиса. Но если доля постоянных отказов выросла относительно вашей обычной статистики, откладывать разбор не стоит. Особенно если параллельно снижаются открытия, растут жалобы или письма начинают попадать в спам.
Полезнее всего разбить отчёт хотя бы по четырём измерениям:
- по типу отказа — временный или постоянный;
- по домену получателя — Gmail, Yahoo, корпоративные домены, локальные провайдеры;
- по источнику подписки — форма на сайте, импорт из CRM, офлайн-мероприятие, лид-магнит, покупка;
- по конкретной кампании — всем ли письмам плохо или проблема только у одного шаблона, сегмента либо дня отправки.
Если 80% отказов пришли с одного провайдера, это не обязательно означает плохую базу. Возможно, именно для этого провайдера вы слишком быстро отдали большой объём, не прошли техническую проверку или отправили письмо с неподходящим вложением.
Анатомия SMTP-ответов: 4xx и 5xx нельзя лечить одинаково
SMTP-код — это первое, на что я смотрю в журнале рассылки. Он не всегда даёт исчерпывающий ответ, но сразу подсказывает правильный маршрут диагностики.
Коды класса 4xx означают временный отрицательный результат. Принимающий сервер сейчас не готов принять письмо, однако по стандартной логике SMTP отправляющая система должна повторить попытку позже. Это может происходить по множеству причин: ящик временно переполнен, сервер получателя занят, провайдер ограничил скорость приёма, возникла кратковременная техническая проблема.
Коды класса 5xx говорят о постоянном отказе. Повторять идентичную отправку без разбора причины в таком случае не стоит. Среди типичных сценариев — несуществующий ящик, некорректный адрес, отказ из-за политики получателя, проблемы с аутентификацией или контентом.
Что делать с отказами разных классов
1. Для 4xx не удаляйте адрес после первого события.
Временный отказ — не доказательство того, что ящик «мёртвый». Дайте ESP завершить стандартные повторные попытки доставки. Если временные ошибки регулярно повторяются по одному домену, анализируйте частоту отправки, репутацию и технические ответы сервера.
2. Для 5xx читайте не только цифру, но и диагностический текст.
Код 5xx может скрывать как несуществующий ящик, так и блокировку по политике провайдера. Формулировки вроде mailbox unavailable, user unknown, address rejected и похожие нужно сохранять в отчётах: именно они позволяют отделить проблему базы от проблемы отправителя.
3. Изолируйте повторяющиеся постоянные отказы.
Адреса, которые сервис определил как invalid address или hard bounce, стоит сразу исключать из следующих кампаний. Ящик, который раньше работал, тоже может стать недействительным: пользователь мог удалить его, а провайдер — отключить неактивный аккаунт.
4. Отмечайте не только адрес, но и причину исключения.
В CRM или в самой ESP полезно хранить статус: hard bounce, жалоба на спам, ручная отписка, временная проблема, технический отказ. Это создаёт порядок в рутине и не даёт случайно вернуть проблемный контакт в новый импорт.
5. Не пытайтесь интерпретировать один код вне контекста.
Один и тот же класс ответа не объясняет, что именно стало причиной: репутация, контент, DNS, объём отправки или сбой на стороне получателя. Здесь помогает только сочетание логов, разбивки по доменам и истории кампаний.
Временный отказ — это пауза в доставке. Постоянный отказ — повод остановиться и понять, что именно сервер больше не готов принимать.
База подписчиков: откуда в ней появляются несуществующие адреса
Когда речь идёт о высоком проценте возвратов писем, первым подозреваемым почти всегда становится база. И часто это справедливо — но не в смысле «подписчики плохие». База стареет сама по себе, даже если вы ничего не делаете неправильно.
Адреса меняются после увольнений, закрытия компаний, переезда на другой домен. Личные ящики удаляются из-за долгой неактивности. Ошибки попадают в форму подписки: лишняя буква в домене, неверная раскладка, случайный пробел. Особенно уязвимы базы, собранные много лет назад, выгруженные из нескольких CRM или дополненные после конференций и офлайн-встреч.
В моей практике самый заметный рост hard bounce обычно появлялся не после обычных подписок с сайта, а после «ценного импорта»: старых лидов отдела продаж, списка участников мероприятия или контактов, которые когда-то оставили визитку. У такого списка может быть вполне деловой вид, но он не равен актуальной базе согласившихся получать рассылку.
Как выстроить спокойную гигиену базы
Не обязательно устраивать большую чистку раз в год и переживать, что полезные контакты исчезнут. Лучше сделать обработку адресов частью регулярной системы.
- Подключите автоматическую обработку bounce-уведомлений. При большом объёме ручная работа быстро превращается в источник ошибок. Hard bounce должен автоматически переводить контакт в статус исключения, чтобы адрес не попадал в новые отправки.
- Разделяйте источники сбора. Метка источника подписки позволяет быстро увидеть, откуда пришёл проблемный сегмент. Если отказы растут только у контактов из партнёрской формы, искать надо не в шаблоне письма.
- Подтверждайте подписку там, где это возможно. Double opt-in не отменяет все проблемы с доставкой, но заметно уменьшает долю случайных и ошибочных адресов.
- Не возвращайте в активную рассылку старые контакты одним запуском. Если база не получала писем несколько месяцев или лет, разумнее начать с небольшого реактивационного сегмента, а не отправлять сразу на весь архив.
- Следите за неактивностью отдельно от bounce. Адрес может формально принимать письма, но давно не открывать их. Такой контакт не создаёт возврат, зато постепенно ухудшает качество аудитории и повышает риск жалоб.
Покупные базы здесь особенно разрушительны для комфорта и отправителя, и получателя. Они почти всегда содержат устаревшие или неверные адреса, а главное — люди не ожидают письмо. Даже если технически часть сообщений дойдёт, итогом будут жалобы, спам-фильтры и ещё больше проблем с доставляемостью.
SPF, DKIM и DMARC: техническая основа, без которой письму не доверяют
Низкая доставляемость писем не всегда начинается с несуществующих ящиков. Иногда письмо просто не проходит проверку доверия у принимающего сервера. И тогда в отчётах могут быть и отказы, и попадания в спам, и замедленная доставка.
Для массовых отправителей на личные Gmail-адреса требования Google с 1 февраля 2024 года стали заметно строже. Если вы отправляете более 5 000 сообщений в сутки, нужны SPF, DKIM и DMARC, корректные прямая и обратная DNS-записи, TLS при передаче, а также выравнивание домена в поле From с SPF или DKIM. Для маркетинговых и подписных писем необходимы one-click unsubscribe и заметная ссылка для отписки.
Проверка этих вещей не должна быть ритуалом «один раз настроили и забыли». Домен, сервис рассылок, CRM, подрядчик по транзакционным письмам — всё это меняется. Вместе с изменениями часто ломается и аутентификация.
Где чаще всего прячутся ошибки настройки SPF, DKIM, DMARC
SPF определяет, какие серверы имеют право отправлять письма от имени домена. Распространённая проблема — когда в SPF не добавили новый ESP или добавили записи так, что DNS-проверка перестала работать корректно. Ещё одна неприятная ситуация — несколько SPF-записей вместо одной итоговой политики.
DKIM добавляет криптографическую подпись письма. Для отправки на личные Gmail-аккаунты ключ должен быть не менее 1024 бит; при поддержке со стороны провайдера Google рекомендует 2048 бит. На практике стоит проверить не только наличие DKIM-записи, но и то, что конкретный поток рассылок действительно подписывается этим ключом.
DMARC формулирует политику домена и связывает аутентификацию с видимым адресом отправителя. Его смысл не в том, чтобы поставить самую строгую политику за пять минут. Сначала нужно убедиться, что все легитимные сервисы отправки проходят выравнивание, иначе можно создать себе дополнительный поток отказов.
Отдельное внимание стоит уделить полю From. Бывает, что сервис технически отправляет письма от своего служебного домена, а в интерфейсе кампании указан ваш брендовый адрес. Для получателя это выглядит не так цельно, как кажется в редакторе рассылки. Когда домены SPF или DKIM не выровнены с From, доверие к письму снижается.
Контент и размер письма: иногда причина отказа лежит в шаблоне
Маркетолог часто смотрит на письмо как на коммуникацию: тема, оффер, баннер, кнопка, тон. Почтовый сервер смотрит строже и суше: размер сообщения, вложения, ссылки, структура HTML, репутация доменов в ссылках.
Провайдеры могут отклонять письмо из-за подозрительных URL, слишком крупного сообщения, запрещённых или тяжёлых вложений. Лимиты различаются. В качестве примера: Gmail допускает сообщения до 25 МБ, Hotmail — до 10 МБ, а у небольших или устаревших провайдеров ограничение может быть около 2 МБ. При этом реальный размер после кодирования вложений и добавления служебных частей письма может оказаться больше, чем кажется по файлу на компьютере.
Я бы не советовал превращать email в папку для передачи файлов. Если нужно отправить презентацию, каталог или запись вебинара, комфортнее для подписчика и безопаснее для доставки дать понятную ссылку на страницу скачивания. Так письмо быстрее загрузится на мобильном устройстве, а вы сможете отдельно измерить интерес к материалу.
Перед повторной отправкой кампании, которая дала всплеск отказов, стоит внимательно проверить:
- не появился ли в шаблоне новый домен для ссылок или сокращатель URL;
- не ведут ли кнопки на страницы с редиректами и подозрительными параметрами;
- не добавили ли тяжёлые изображения, PDF или другие вложения;
- не изменилась ли структура HTML после правок в стороннем редакторе;
- не отправляете ли вы с адреса, который не соответствует настроенной аутентификации;
- не отличается ли проблемная кампания по составу аудитории от обычных рассылок.
Контентные причины особенно легко пропустить, если предыдущие письма с тем же доменом доставлялись нормально. Но достаточно заменить посадочную страницу, подключить новый трекер или добавить вложение — и поведение фильтров меняется.
Объём и скорость: почему хорошая база тоже может получить отказы
Отказ вида Frequency/Volume Too High означает, что принимающий провайдер не может или не хочет обработать текущий поток сообщений. Это не обязательно обвинение в спаме и не приговор домену. Но это ясный сигнал: темп отправки нужно снизить.
Частая ситуация — компания долго не рассылала письма, затем решила «вернуться» и отправила кампанию сразу на всю базу. Или база резко выросла после лидогенерации, а инфраструктура и репутация остались на уровне небольших объёмов. Почтовый провайдер видит непривычную нагрузку, особенно если сообщения идут плотной волной на один домен получателей.
Здесь помогает не героическая повторная отправка, а аккуратное распределение объёма.
Как снизить риск отказов из-за скорости
1. Найдите провайдера, который возвращает ошибки.
Если отказы приходятся преимущественно на Gmail, не нужно замедлять всю рассылку одинаково. Сначала выделите конкретный домен и оцените его долю в базе.
2. Разбейте крупную кампанию на части.
Вместо одного мощного запуска распределите отправку на несколько волн в течение дня. Это снижает нагрузку на принимающую сторону и оставляет пространство для наблюдения за статистикой.
3. Разогревайте новый домен и IP постепенно.
Не стоит начинать новую отправляющую инфраструктуру с максимального объёма. Наращивание темпа на вовлечённой аудитории выглядит для провайдеров естественнее и даёт вам время заметить проблему до масштабной кампании.
4. Отправляйте сначала наиболее вовлечённым подписчикам.
Контакты, которые недавно открывали письма или переходили по ссылкам, — хороший стартовый сегмент. Их поведение поддерживает репутационный профиль лучше, чем молчаливая архивная аудитория.
5. Не путайте отказы и жалобы.
Bounce говорит о технической невозможности или отказе принять письмо. Жалоба на спам — сигнал, что получатель не хотел видеть это письмо. Для Google и Yahoo ориентир для массовых отправителей — менее 0,3% жалоб. Это отдельный показатель, но он напрямую влияет на то, почему письма попадают в спам и почему дальше растёт доля проблемной доставки.
Порядок действий, если bounce rate вырос сегодня
Когда кампания уже ушла, задача не в том, чтобы мгновенно «исправить процент». Задача — не усугубить ситуацию следующей отправкой и понять, какой слой требует работы.
Я бы действовал в такой последовательности:
1. Поставить на паузу повторные отправки проблемному сегменту. Не отправляйте идентичное письмо повторно всем недоставленным контактам.
2. Выгрузить SMTP-логи и разделить 4xx с 5xx. Без этого анализ причин bounce email остаётся догадкой.
3. Посмотреть распределение по доменам получателей. Один провайдер, один корпоративный домен или вся база — это три разных сценария.
4. Сравнить проблемную кампанию с предыдущими. Проверьте объём, скорость, шаблон, ссылки, вложения, отправляющий домен и сегмент.
5. Исключить подтверждённые hard bounce из будущих рассылок. Это нужно сделать сразу и автоматизировать на будущее.
6. Проверить SPF, DKIM, DMARC, TLS и выравнивание доменов. Особенно после миграции между ESP, подключения CRM или смены домена отправителя.
7. Снизить темп отправки для проблемного провайдера. Если логи указывают на ограничения объёма, дайте серверу получателя более ровный поток.
8. Отдельно оценить жалобы, отписки и неактивность. Если люди не ждали рассылку, техническая настройка сама по себе не вернёт здоровую доставляемость.
Высокий процент возвратов писем редко исчезает от одной настройки. Но и не требует паники. Когда база очищается от постоянных отказов, аутентификация домена собрана корректно, скорость отправки соответствует реальной репутации, а письма не перегружены тяжёлыми вложениями и сомнительными ссылками, доставка постепенно становится ровнее.
В email-маркетинге полезно относиться к bounce не как к неприятной красной цифре, а как к обратной связи от почтовой инфраструктуры. Она говорит достаточно прямо — нужно лишь не смешивать разные причины в одну. Тогда у команды появляется не тревожная рутина бесконечных «перезапусков», а понятная система: кому писать, с какого домена, в каком объёме и почему именно так.