Как сделать массовую проверку email-адресов для рассылки

База на 20 адресов проверяется глазами. Но в списке на 20 000 контактов такой подход уже не работает. Там обязательно окажутся опечатки, удалённые ящики, старые корпоративные адреса, временная почта, дубли и домены, которые давно перестали принимать письма.

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

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

Зачем проверять всю базу до рассылки

Email-база постепенно устаревает, даже если изначально была собрана нормально. Сотрудник увольняется – корпоративный ящик удаляют. Человек перестаёт пользоваться старой почтой. Домен компании закрывается. При регистрации пользователь ошибается в одной букве. Одноразовый адрес существует несколько минут, а потом исчезает.

Поэтому «мы уже отправляли на эту базу год назад» не означает, что она готова к новой кампании.

Основная проблема – возвраты писем. Когда адрес не существует, почтовый сервер отправителя получает отказ. Если таких отказов становится много, страдает статистика рассылки и репутация отправителя. Почтовые сервисы учитывают качество базы при фильтрации входящей почты.

Перед массовой отправкой проверьте:

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

После очистки файл уже можно переносить в ESP. В качестве проверенного сервиса рекомендуем RuSender (для него у нас есть отдельный обзор).

Из чего складывается массовая проверка

Проверка списка – это не отправка тестового письма каждому получателю. Валидатор анализирует адрес в несколько этапов и пытается определить возможность доставки без реальной рассылки.

Сначала формат

Сначала отсеиваются явно неправильные записи:

ivanmail.ru
ivan@@mail.ru
ivan @mail.ru

Проверяется структура адреса и допустимость используемых символов.

Это самый простой этап. Он полезен, но сам по себе почти ничего не говорит о существовании ящика. Адрес abc123@company.ru может быть записан без единой ошибки, хотя такого пользователя никогда не было.

Дальше домен и MX-записи

Следующий вопрос – существует ли домен и настроена ли на нём почта.

Для этого проверяются DNS и MX-записи. MX указывает серверы, которые должны принимать электронную почту для домена. Если почтовой инфраструктуры нет, такой адрес нет смысла оставлять в базе.

Стучимся на сервер по SMTP

Затем валидатор обращается к почтовому серверу и пытается выяснить, принимает ли он сообщения для конкретного пользователя.

Письмо при этом не отправляется. Проверяется реакция сервера на запрос. Именно здесь можно выявить значительную часть удалённых и несуществующих ящиков.

Технически живой, но рискованный

С адресом может быть всё нормально технически, но для массовой рассылки он всё равно требует отдельного внимания.

В эту группу входят:

• временная почта;
• catch-all домены;
• ролевые адреса;
• переполненные ящики;
• замороженные аккаунты;
• почтовые серверы, которые не позволяют точно проверить получателя;
• домены из публичных чёрных списков.

Поэтому нормальный результат массовой проверки редко выглядит как две колонки «существует / не существует».

Почему нельзя проверять большую базу отправкой писем

Иногда предлагают простой способ: отправить письмо всем контактам и удалить тех, от кого пришёл bounce.

Технически он работает, но для большой базы это плохой вариант.

Допустим, в списке 100 000 адресов, из которых 15 000 давно не существуют. Чтобы обнаружить их таким способом, придётся сначала отправить 15 000 заведомо недоставляемых сообщений. Именно эти возвраты и хотелось предотвратить.

Кроме того, вы расходуете лимит сервиса рассылок и получаете плохую статистику кампании ещё до начала нормальной работы с аудиторией.

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

Готовим файл к загрузке

Чаще всего база хранится в Excel, Google Таблицах, CRM или старом сервисе рассылок. Для проверки достаточно выгрузить адреса в поддерживаемый валидатором формат.

Перед загрузкой посмотрите на сам файл:

• Убедитесь, что нужная колонка действительно содержит email.
• Уберите пустые строки, если экспорт создал их автоматически.
• Сохраните исходный файл отдельно.
• Не заменяйте сомнительные домены вручную без подтверждения.

Последний пункт особенно важен. Если в базе встречается user@gmal.com, кажется очевидным заменить домен на gmail.com. Но нельзя знать наверняка, что человек имел в виду именно Gmail. Валидатор должен пометить проблему, а не придумывать новый контакт вместо пользователя.

Как это выглядит в uChecker

Для примера возьмём uChecker – отдельный сервис валидации email. Он работает через веб-кабинет, REST API и Telegram-бот. Через веб можно загрузить базу и получить готовые списки после окончания проверки. Сервис заявляет обработку до 9 млн адресов за одну задачу и скорость около 3200 проверок в минуту.

1. Загружаем список

В кабинете создаём задачу и выбираем TXT или CSV с адресами. Предварительно запускать отдельную проверку доменов не требуется. uChecker сам выполняет несколько этапов анализа.

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

2. Запускаем проверку

После загрузки начинается обработка адресов.

Сервис проверяет формат, DNS, MX и возможность существования конкретного ящика через SMTP. Дополнительно определяются проблемные и неоднозначные случаи.

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

Число обработанных строк в секунду – не единственный критерий качества валидатора. Важно, как он поступает с адресами, по которым сервер не дал однозначного ответа.

3. Разбор базы после проверки

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

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

Это полезно при большой базе. Если просто получить сообщение «18% адресов плохие», непонятно, что именно произошло. Детализация помогает увидеть, состоит ли проблема из удалённых ящиков, неработающих доменов или временных ошибок серверов.

4. Три файла на выходе

uChecker разделяет итог на списки Good, Bad и Risk. Готовые группы можно скачать архивом, а для дальнейшей обработки доступны CSV и JSON.

Такое разделение удобнее, чем безусловное «валиден / невалиден», поскольку часть адресов невозможно достоверно проверить автоматически.

Что делать с Good, Bad и Risk

На этом этапе маркетологи чаще всего допускают ошибку: оставляют Good, а Bad и Risk сразу удаляют.

С Bad всё достаточно просто. Если ящика нет, домен не принимает почту или сервер явно сообщил о постоянной ошибке, адрес нет смысла включать в кампанию. С Risk же ситуация другая.

Good

Это адреса, для которых проверка не выявила критических проблем. Их можно переносить в рабочий список рассылки.

Bad

Это контакты с явными причинами недоставки. Их обычно исключают из активной базы.

Строки из текущего CSV лучше не удалять насовсем. Отправьте такие адреса в suppression list. Тогда они не вернутся после очередной синхронизации со старой CRM или повторного импорта.

Risk

Здесь могут оказаться рабочие адреса, которые нельзя подтвердить с достаточной уверенностью.

Типичный пример – catch-all. Почтовый сервер говорит, что примет сообщение для любого имени внутри домена. Получается, он одинаково реагирует и на существующего сотрудника, и на придуманного пользователя.

Удалять всю группу Risk без разбора не стоит, особенно если база состоит из корпоративных клиентов.

Заведите для неё отдельный сегмент, отправьте небольшую партию и посмотрите на реальные возвраты.

Что такое статус «Неизвестно»

Почтовые серверы не обязаны помогать сторонним системам проверять своих пользователей.

Некоторые ограничивают частоту запросов. Другие дают временный ответ. Корпоративная почта может намеренно скрывать существование конкретного ящика.

Поэтому качественный валидатор не должен записывать любой неопределённый адрес в Good только потому, что сервер прямо не сказал «такого пользователя нет».

В uChecker такие случаи выводятся отдельно. В кабинете можно увидеть количество неопределённых адресов и работать с ними как с самостоятельной группой.

Сколько стоит массовая проверка

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

На август 2026 года в кабинете uChecker пакеты выглядят так:

Чем больше пакет, тем дешевле проверка одного адреса. Первые 30 адресов проверяются бесплатно, так что попробовать сервис можно без оплаты.

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

Периодичность: раз в сколько гонять базу

Универсального графика нет. Всё зависит от происхождения базы и частоты рассылок.

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

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

Гоните базу заново, если:

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

Проверять всю активную базу после каждой отправки необходимости нет.

Можно ли автоматизировать проверку новых адресов

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

Для этого у uChecker есть REST API. Его можно связать с регистрацией на сайте, CRM или собственной системой, чтобы адрес уходил на проверку автоматически. Для крупных фоновых задач предусмотрен пакетный сценарий через API.

Например:

• пользователь оставляет email;
• контакт сохраняется в CRM;
• адрес передаётся валидатору;
• результат записывается в отдельное поле;
• при подготовке рассылки используются только нужные статусы.

Так большая база изначально накапливается в более чистом виде.

Валидация не заменяет нормальный сбор подписчиков

Есть ещё один принципиальный момент. Валидатор отвечает на вопрос «работает ли адрес?», но не отвечает на вопрос «хочет ли владелец получать ваши письма?».

Рабочий адрес, найденный в открытом доступе, остаётся рабочим после проверки, но подписчиком от этого не становится.

Лучший вариант – собирать собственную базу через формы, подтверждать подписку и параллельно контролировать техническое качество адресов.

Email-рассылка сама по себе может быть отдельным каналом работы с аудиторией и монетизации сайта – этот вариант мы также разбирали в материале о способах заработка на своём сайте.

На чём спотыкаются чаще всего

Проверять только синтаксис. Это найдёт опечатки в структуре, но не удалённые ящики.

Считать все Risk плохими. Среди них могут быть реальные корпоративные контакты.

Исправлять домены автоматически. Замена gmal.com на gmail.com кажется очевидной, но создаёт адрес, который пользователь не вводил.

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

Забывать про дубли. Даже полностью валидный адрес не должен присутствовать в одном списке несколько раз.

Возвращать Bad после нового импорта. Для удалённых адресов лучше вести постоянный список исключений.

Путать валидацию с согласием на рассылку. Существование ящика ничего не говорит о происхождении контакта.