Проверять базу лучше до первой массовой отправки, а не после отчёта с десятками или сотнями недоставленных писем. За время хранения часть адресов перестаёт существовать, пользователи меняют работу и корпоративную почту, при заполнении форм появляются опечатки, а временные ящики могут исчезнуть уже через несколько часов.
Если отправить письма по такой базе без подготовки, часть сообщений вернётся с ошибкой. Высокая доля возвратов служит для почтовых провайдеров сигналом, что отправитель плохо работает со своей аудиторией. Это может сказаться на репутации домена и последующей доставляемости.
Проверка особенно нужна перед импортом старой базы в новый сервис, после длительного перерыва в рассылках и при объединении контактов из нескольких источников. После очистки список можно загрузить в один из сервисов email-рассылок и уже там проводить кампанию.
Правильно написанный адрес ещё не обязательно рабочий. Запись вида name@company.ru может выглядеть нормально, но домен может не принимать почту, самого ящика может не существовать, а сервер может временно отказываться отвечать на запросы.
Поэтому проверка состоит из нескольких этапов.
Синтаксис. Проверяется структура адреса: наличие имени пользователя, символа @, домена, допустимых символов и других обязательных элементов.
Домен. Система проверяет, существует ли доменная часть адреса.
MX-записи. Они показывают, какие серверы принимают почту для домена. Если MX-записей нет, доставить обычное письмо на такой адрес, как правило, невозможно.
SMTP. Валидатор соединяется с почтовым сервером и проверяет его реакцию на конкретного получателя. Само письмо при этом не отправляется. Именно этот этап позволяет выявить значительную часть несуществующих ящиков.
Одной регулярки или проверки формата для подготовки базы недостаточно. Такой тест найдёт user@@mail.ru, но спокойно пропустит аккуратно написанный адрес на несуществующем домене.
Перед рассылкой полезно разделить найденные проблемы на несколько групп. Не все они требуют одинаковых действий.
Часть ошибок появляется ещё при вводе данных:
Некоторые ошибки можно исправить автоматически, но делать это без проверки опасно. Если пользователь действительно указал другой домен, автоматическая замена создаст новый адрес, который ему не принадлежит.
Это адреса, которые были удалены или никогда не существовали. Массовая отправка по ним приводит к hard bounce. Такие контакты обычно удаляют из активной базы и заносят в список исключений, чтобы они не вернулись при очередной выгрузке из CRM.
Сервер существует, но письмо сейчас принять не может. Причиной может быть переполненный почтовый ящик, временная блокировка или сбой.
Один такой ответ ещё не означает, что адрес нужно навсегда удалить. Если ошибка повторяется в нескольких рассылках подряд, контакт уже можно считать проблемным.
Disposable email создают на короткий срок. Такой ящик может быть технически рабочим во время проверки, но через несколько часов или дней перестать существовать.
Для регистрации на сайте временная почта иногда допустима. Для постоянной маркетинговой базы она мало полезна: подписчик не планирует регулярно читать письма по этому адресу.
Это адреса вроде:
Они могут быть полностью рабочими, поэтому удалять их как невалидные неправильно. Но это не персональные контакты, а общие ящики организации. Для массовых маркетинговых рассылок их обычно обрабатывают отдельно.
Некоторые домены принимают письмо независимо от того, существует ли указанное имя пользователя. Например, сервер одинаково отреагирует на ivan@company.ru и случайный abc123@company.ru.
Такой домен называется catch-all или accept-all. Обычная SMTP-проверка не может достоверно подтвердить конкретный ящик, поэтому подобные адреса лучше держать в отдельной группе, а не автоматически записывать в хорошие или плохие.
Повторяющиеся адреса не относятся к проблемам валидации, но их тоже лучше удалить до импорта. Иначе один подписчик может получить несколько одинаковых писем, а количество контактов в сервисе рассылок окажется искусственно завышенным.
Если адресов пять или десять, часть работы можно выполнить без специального сервиса.
Сначала проверить написание. Затем посмотреть, существует ли домен и есть ли у него MX-записи. Для диагностики отдельного адреса можно дополнительно проверить почтовый сервер.
Но такой подход плохо масштабируется. Уже для списка на тысячу контактов придётся выполнять тысячи однотипных запросов, учитывать ограничения серверов и сохранять результаты. Для базы на десятки или сотни тысяч адресов ручная проверка теряет смысл.
Есть и ещё одна проблема. Отправлять тестовое письмо на каждый сомнительный адрес и определять валидность по возвратам не стоит. В этом случае почтовые провайдеры увидят настоящую рассылку с большим числом ошибок. Проверка через SMTP позволяет получить ответ сервера без отправки содержимого письма.
Для массовой обработки используют email-валидаторы. Они получают список адресов, последовательно выполняют технические проверки и возвращают готовый отчёт.
Обычно схема выглядит так:
Разница между сервисами заключается в глубине проверки, способе обработки неоднозначных ответов, скорости, ограничениях на размер файла и цене.
Для примера дальше разберём процесс на uChecker.
uChecker работает как самостоятельный валидатор. Для проверки не требуется аккаунт в конкретном сервисе рассылок. Веб-версия принимает TXT и CSV, одна задача может содержать до 9 млн email. Помимо кабинета доступны REST API и Telegram-бот. Заявленная скорость составляет около 3200 адресов в минуту.
Если база хранится в CRM или сервисе рассылок, сначала сделайте выгрузку. Для веб-проверки в uChecker можно использовать .csv или .txt.
Нет необходимости предварительно вручную отсеивать домены, которые выглядят подозрительно. Лучше передать исходный список валидатору и затем работать с результатом.
После входа в веб-кабинет создаётся новая задача и загружается файл с контактами.
Это подходит как для небольшой тестовой выборки, так и для крупных списков. На сайте uChecker указан лимит до 9 миллионов email за одну задачу.
Во время обработки сервис последовательно проверяет адреса. В базовый набор входят синтаксическая проверка, DNS и MX, а затем SMTP-валидация конкретного ящика.
Дополнительно определяются ситуации, в которых результат нельзя считать однозначным: catch-all, временные проблемы сервера и другие ответы, не позволяющие подтвердить существование ящика.
Письма получателям во время SMTP-проверки не отправляются.
После завершения задачи uChecker показывает статистику и причины ошибок. В кабинете можно увидеть количество валидных, невалидных и неопределённых адресов, а для конкретных записей сохраняется ответ почтового сервера.
Для выгрузки используются три основных списка:
Такое разделение удобнее схемы, где каждый контакт принудительно относится только к рабочим или нерабочим.
После проверки результаты можно скачать архивом. Для дальнейшей обработки доступны CSV и JSON с причинами присвоения статуса.
Если рассылка выполняется вручную, обычно достаточно списка подходящих адресов. Для CRM, собственных приложений и автоматизированных процессов полезнее подробная выгрузка, в которой статус можно обрабатывать программно.
После валидации не нужно механически брать один файл и удалять всё остальное. У разных групп разная логика.
Good – адреса, для которых проверка не выявила проблем. Их оставляют в рабочей базе.
Bad – адреса с явными ошибками: несуществующий ящик, отсутствующая почтовая инфраструктура домена и другие причины, при которых отправлять письмо бессмысленно. Их лучше удалить из активного списка.
Risk – спорная группа. Сюда могут попадать адреса на catch-all доменах и контакты, по которым сервер не дал однозначного ответа. Если это ценная корпоративная база, удалять всю группу Risk не стоит. Её можно отправлять отдельными небольшими партиями и следить за фактическими отказами.
У uChecker в кабинете дополнительно показывается группа неопределённых результатов. Сервис не записывает такой адрес в валидные только потому, что сервер не вернул прямого отказа.
Одна проверка не делает список постоянным. Даже если сегодня все адреса работают, через несколько месяцев часть из них перестанет принимать почту.
Проверка нужна в нескольких случаях:
Если рассылки идут регулярно, результаты самих отправок тоже становятся источником данных. Постоянные hard bounce нужно сразу исключать, а повторяющиеся soft bounce отслеживать отдельно.
Чистить уже накопленную базу полезно, но ещё дешевле не допускать очевидный мусор при сборе контактов.
Минимальная синтаксическая проверка должна работать ещё до отправки формы. Она поймает адрес без @, лишние пробелы и часть других ошибок.
Если лиды собираются через онлайн-формы, можно дополнительно проверять домен и предупреждать пользователя о вероятной опечатке.
При double opt-in подписчик должен перейти по ссылке из письма и подтвердить адрес. Это сразу решает две задачи: проверяет возможность доставки и подтверждает, что у человека есть доступ к указанному ящику.
Валидатор и double opt-in не заменяют друг друга. Первый проверяет техническое состояние адреса, второй подтверждает действие пользователя.
Удалённый невалидный адрес не должен возвращаться после следующей синхронизации CRM. Для этого используют suppression list, куда записывают контакты, на которые больше не следует отправлять письма.
Технически валидный email ещё не означает, что его владелец подписался на маркетинговую рассылку. Проверка подтверждает состояние ящика, но не происхождение контакта.
Это особенно актуально для купленных или собранных из открытых источников баз. Валидатор может убрать мёртвые адреса, но не превратит такую базу в подписную.
Если email собираются постоянно, например при регистрации пользователей или оформлении заказа, нет необходимости каждый раз выгружать всю базу.
Проверку можно встроить непосредственно в продукт через API. uChecker предоставляет REST API, а для больших асинхронных задач поддерживает webhook. Такой вариант позволяет проверять адрес при добавлении либо отправлять полную SMTP-валидацию в фоновую обработку.
У сервиса есть и MCP-подключение для работы с AI-агентами. Это уже более технический сценарий: совместимый агент может обращаться к валидатору как к внешнему инструменту. Если интересует сама логика использования таких систем в веб-проектах, у нас есть отдельный материал про AI в веб-разработке.
Для обычной рассылки API и MCP не обязательны. Веб-кабинета достаточно, если задача сводится к периодической загрузке и очистке файлов.
В uChecker первые 100 адресов можно проверить бесплатно. Далее стоимость зависит от размера пакета. На момент подготовки статьи цена начинается с 0,20 ₽ за адрес для небольших объёмов и снижается до 0,05 ₽ при покупке от 500 тысяч проверок. Например, пакет на 10 000 адресов стоит 2 000 ₽, на 200 000 – 16 000 ₽, на 500 000 – 25 000 ₽.
Для небольшой базы расходы на валидацию стоит сравнивать не только с ценой самой рассылки. Отправка на заведомо несуществующие адреса расходует лимит ESP и одновременно ухудшает статистику отправителя.
После очистки базы работа продолжается уже в сервисе рассылок.
Сначала импортируйте рабочие адреса. Bad оставьте в списке исключений, а Risk при необходимости вынесите в отдельный сегмент. Если используется RuSender или другая ESP, первые отправки по старой базе лучше делать контролируемыми партиями и смотреть на статистику возвратов.
Следить нужно как минимум за hard bounce и soft bounce. Первый означает постоянную ошибку доставки и обычно требует удаления адреса. Второй может быть временным, поэтому решение принимают после нескольких повторений.
Проверка базы не отвечает на вопросы вовлечённости. Адрес может быть рабочим, но принадлежать человеку, который давно перестал читать рассылку. Поэтому техническую валидацию полезно сочетать с очисткой по активности: отдельно работать с теми, кто месяцами не открывает письма и не переходит по ссылкам.
Перед запуском кампании последовательность действий можно свести к семи шагам:
Для нескольких адресов часть проверок можно сделать вручную. Для базы на тысячи контактов проще использовать валидатор, который автоматически проверит синтаксис, домен, MX и SMTP.
ОБ АВТОРЕ
Приветствую!
Я Евгений Куликов - автор и основатель этого сайта. Имея за плечами более, чем десятилетний опыт создания сайтов, я знаю, как порой сложно бывает определиться с выбором подходящего инструмента для своего проекта. Особенно - если вы новичок в сайтостроении.
Не можете определиться с выбором нужного конструктора? Обращайтесь ко мне за консультацией - расскажите, для каких целей вам нужен сайт и я с удовольствием помогу с выбором наиболее оптимальной для вас платформы.
ЛУЧШИЕ СЕРВИСЫ
|
5++
оценка
|
UKIT.COM наш обзор → |
|
5.0
оценка
|
UCOZ.RU наш обзор → |