CRM-аналитика
Email помечен как invalid: какие причины скрываются за статусом и что делать с каждой
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
В отчёте платформы выросло количество invalid email. Маркетолог готов удалить эти контакты, интегратор предлагает повторить отправку, а менеджер уверяет, что вчера общался с одним из клиентов по почте. Все трое могут описывать реальные наблюдения: общий статус часто скрывает разные технические причины.
Invalid означает, что адрес признан непригодным по правилам конкретной проверки или системы. Это не единый универсальный диагноз. Ошибка написания, отсутствие ящика, временный сбой и отказ принять письмо от вашего домена требуют разных действий. Начните с исходной причины, времени проверки и системы, которая присвоила статус.
Четыре разных вопроса вместо одного
Корректно ли записан адрес? В нём могут быть лишние пробелы или ошибка формата. Но слишком примитивная проверка способна отклонить допустимые адреса, например с поддерживаемыми платформой международными символами. Правила формы нужно согласовать с реальными возможностями всей цепочки отправки.
Может ли домен принимать почту? Проверка DNS помогает найти проблемы маршрутизации. Результат стоит интерпретировать по полной диагностике используемой системы, а не по единственному признаку из формы.
Существует ли ящик и принимает ли сообщение? Получающий сервер не всегда раскрывает это при предварительной проверке. Статусы unknown и accept-all нужно хранить как неопределённость, а не автоматически переводить в «валиден». Accept-all означает, что сервер принимает адреса без надёжного подтверждения существования конкретного ящика на этом этапе. Mailgun описывает аналогичную неопределённость своим статусом catch_all.[1]
Тот ли это получатель и ожидает ли он письмо? Ни формат, ни DNS, ни ответ валидатора не доказывают личность владельца и его согласие. Даже технически работающий адрес может оказаться чужим или больше не относиться к прежнему клиенту.
Что означает bounce
Bounce — сообщение или событие о неудаче доставки. Hard bounce обычно обозначает постоянный отказ для данной попытки, soft bounce — временную проблему. В расширенных кодах SMTP первая цифра 4 указывает на временную неудачу, 5 — на постоянную; следующие части уточняют причину. Например, 5.1.1 относится к отсутствующему ящику, а 5.7.1 — к запрету доставки по правилам безопасности или политики.[2]
Поэтому «постоянный» не всегда означает «этого человека никогда не существовало». Это может означать, что повтор того же сообщения без исправления ничего не изменит. Политика ESP по исключению адреса при этом обязательна для вашего рабочего процесса: её нельзя обходить ручным включением в следующую кампанию.
| Наблюдение | Возможная причина | Рабочее действие |
|---|---|---|
| Адрес не проходит проверку формата | Опечатка или неподдерживаемая запись | Предложить владельцу исправление; проверить ограничения формы |
| Получатель не существует | Ящик удалён или адрес неверен | Прекратить отправки на этот адрес; уточнять контакт другим допустимым способом |
| Ящик переполнен / временно недоступен | Ограничение у получателя | Следовать ограниченным повторам ESP; не запускать новую кампанию как повтор |
| Отказ по политике или аутентификации | Проблема отправителя, сообщения или правил домена | Расследовать причину; не записывать всех получателей в «несуществующие» |
| Unknown / accept-all | Проверка не дала определённого ответа | Сохранить неопределённость; оценить происхождение и подтверждение адреса |
| Отправка подавлена платформой | Ранее установленный запрет | Найти основание исключения, не снимать его автоматически |
Названия статусов и их отображение различаются между платформами. В Amazon SES, например, отдельно передаются тип и подтип bounce, диагностический код и сведения о получателе. Система также различает реальный отказ и некоторые случаи подавления отправки.[3] Для своего ESP сделайте такую же карту перевода в рабочие решения.
Почему вчерашняя проверка не защищает навсегда
Сотрудник сменил работу, компания отключила домен, пользователь удалил ящик. Возможны и адреса-ловушки — контакты, применяемые антиспам-системами для выявления проблемных практик сбора и ведения списков. Среди них бывают ранее использовавшиеся адреса.[4]
Это не основание считать любой старый контакт ловушкой. Это причина поддерживать историю доставки и происхождения адреса, своевременно прекращать неподходящие отправки и не полагаться на один раз купленную «очистку». Валидатор снижает часть технической неопределённости, но не сертифицирует аудиторию как безопасную.
Как устроить обработку статусов
Сохраняйте исходный ответ, нормализованную категорию, время, источник, идентификатор сообщения и адрес, к которому относится событие. Разделяйте статус адреса, запрет на конкретную программу и проблему отправляющей инфраструктуры. Иначе массовый сбой домена может навсегда испортить тысячи клиентских карточек.
Повторы временно не принятых сообщений лучше оставлять единому механизму платформы. Параллельная ручная отправка создаёт дубли и затрудняет диагностику. Когда лимит повторов исчерпан, решение зависит от причины и текущих правил, а не от желания во что бы то ни стало доставить промо.
Условный пример. У магазина 700 отказов после смены отправляющего сервиса. У 620 один код, связанный с политикой получающего домена, у 80 подтверждено отсутствие ящиков. Первые 620 требуют расследования настройки и соблюдения блокировки до решения. Для 80 прекращают отправки на адреса и создают задачу уточнения контакта при будущем обращении. Одинаковое удаление всех 700 клиентских профилей решило бы совсем не ту проблему.
Что передать маркетологу в интерфейсе
Вместо одного красного invalid полезно показывать понятную причину, последнюю проверку и допустимое следующее действие. Например: «Отправки остановлены: ящик не существует. Новый адрес может добавить сам клиент» или «Письма отклонены по политике провайдера. Требуется проверка домена отправителя».
Такая детализация превращает гигиену из периодического удаления строк в управляемый процесс. Как безопасно изменить контакт после уточнения, разобрано в статье о восстановлении email клиента.
Источники
[1] Mailgun. Single Validation. Mailgun Validate Documentation; результаты проверки, risk и catch_all. Проверено 24.09.2026.
[2] Vaudreuil G. Enhanced Mail System Status Codes. RFC 3463. IETF / RFC Editor, январь 2003; разделы 2, 3.2, 3.3, 3.8.
[3] Amazon Web Services. Amazon SNS notification contents for Amazon SES. Amazon SES Developer Guide; bounce object, bounce types и delivery object. Проверено 24.09.2026.
[4] The Spamhaus Project. Spamtraps — fix the problem, not the symptom. Resource Hub; электронная версия проверена 24.09.2026.