Проверка почты на валидность и чистка базы email-рассылки

uChecker — это онлайн-сервис проверки адреса электронной почты. Валидация почты и чистка базы рассылки идут в одном прогоне: за одну задачу обрабатываем до 9 миллионов адресов и возвращаем результат тремя списками: Good, Bad и Unknown. Чистка базы убирает несуществующие и переполненные ящики, а адреса на доменах без MX-записей или из публичных чёрных списков откладывает в Unknown, чтобы ваша email-рассылка приходила только живым подписчикам.

Зачем нужна проверка email на существование перед отправкой? Любой ESP (Unisender, Mailchimp, Sendsay, Brevo, SendPulse) считает bounce rate (процент возвратов) и снижает доставляемость, если в базе много мёртвых адресов. Высокий bounce портит репутацию домена и IP, письма уходят в спам, отписки растут. Один прогон базы через валидатор email убирает мёртвые адреса до отправки и возвращает рассылке нормальный inbox placement.

Как проверить, существует ли адрес электронной почты

Вопрос звучит просто, а ответ на него нельзя получить, просто посмотрев на адрес. Правильно написанный адрес и работающий адрес это разные вещи: petrov@gmial.com выглядит безупречно, но домена gmial.com не существует, и письмо туда не уйдёт никогда.

Способ узнать наверняка один. Спросить у почтового сервера, который обслуживает домен, есть ли у него такой ящик. Именно это делает валидатор uChecker, и делает без отправки письма: диалог с сервером обрывается до передачи содержимого, поэтому владелец адреса ничего не получает и не узнаёт о проверке.

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

Проверить один адрес или всю базу

Один адрес просто вставьте в форму. Ответ приходит в двух видах: ящик принимает почту либо не принимает, и во втором случае указана причина.

Список вы загружаете файлом, порядок тот же. Один запрос обрабатывает до миллионов адресов, и на выходе получается разбивка: рабочие, несуществующие и те, по которым сервер не дал внятного ответа. За последних мы денег не берём.

Существует ли почта на Gmail, Mail.ru и Яндексе

Крупные провайдеры ведут себя по-разному, и это стоит понимать, потому что ответ «адрес рабочий» у них имеет разный вес.

Gmail отвечает честно. Несуществующий ящик он отклоняет, и такой адрес видно сразу.

Mail.ru принимает почту почти на любой адрес своего домена, а решение о существовании ящика принимает уже после приёма. Обычная SMTP-проверка на нём поэтому врёт, и мы используем отдельные методы.

Яндекс посередине. На часть адресов отвечает определённо, на часть нет.

Поэтому доля unknown в отчёте зависит и от того, на каких провайдеров приходится ваша база.

Что означает несуществующий адрес в отчёте

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

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

Как работает валидатор email uChecker

Сервис проверяет каждый адрес через каскад валидаций. Первой идёт синтаксическая проверка email, она смотрит формат и запрещённые символы. Дальше подключается DNS-валидация и проверка MX-записей домена: существует ли почтовая инфраструктура. Затем SMTP-валидация: открываем соединение с почтовым сервером и спрашиваем, есть ли такой ящик, без отправки письма. Для крупных провайдеров вроде Mail.ru у сервиса отдельные методы, причина описана выше.

SMTP-валидация — это оборванный диалог с сервером: команды EHLO, MAIL FROM и RCPT TO с проверяемым адресом, затем QUIT, до передачи письма дело не доходит. Ответ 250 значит, что сервер примет почту для этого ящика, 550 говорит, что ящика нет, а коды 4xx, например 450 и 451, означают временный отказ, и проверку повторяют позже. В SMTP есть и специальная команда VRFY, но стандарт RFC 5321 разрешает её отключать, и выключенный сервер отвечает на неё кодом 252, который ничего не подтверждает. Поэтому валидаторы спрашивают через RCPT TO.

Catch-all домен распознаётся контрольным запросом на выдуманный адрес: если сервер согласился и на него, ответ по настоящему адресу ничего не стоит. Такие адреса, как и ответы при грейлистинге или лимитах провайдера, попадают в unknown. Свой почтовый сервер можно проверить отдельным инструментом, для этого есть проверка SMTP-сервера.

Что находит чистка базы рассылки

• Несуществующие ящики дают хард-баунсы, которые гарантированно отвалятся при рассылке и ударят по репутации.
• Переполненные и замороженные ящики, где сервер принимает соединение, но письмо не доставит.
• Домены без MX-записей и домены, чьи почтовые серверы не отвечают на запросы. Такие адреса попадают в unknown: завтра сервер может ожить.
• Домены в публичных чёрных списках вроде DNSBL, Spamhaus и URIBL. Их тоже откладывают в unknown.
• Опечатки в доменах популярных почт: gmal.com, gmial.com, mial.ru. Такие домены сервис знает по списку и отбраковывает адрес сразу.

Отдельно стоят catch-all домены, role-адреса и disposable email. SMTP-проверка по ним не даёт однозначного ответа, и это ограничение протокола, а не конкретного сервиса. Что это такое и как с этим работать на своей стороне, разобрано в глоссарии.

Кому нужна валидация email-базы

Email-маркетологам перед запуском кампании, B2B-командам перед холодной рассылкой, продуктам с регистрацией по email. Валидация нужна везде, где важна репутация отправителя. Чистка базы перед импортом в новый ESP экономит деньги: вы не платите за отправку писем на мёртвые адреса, а высокий процент валидных подписчиков сразу даёт хороший прогрев домена.

Сколько стоит проверить email

Цена за проверку одного email начинается с 0,20 ₽ на пакете «1 000 адресов» и снижается до 0,05 ₽ при объёме от 500 000. Первые 100 адресов проверяются бесплатно, и этого хватает, чтобы прогнать тестовую выборку из своей базы и убедиться в качестве валидатора. Зарегистрироваться можно в веб-кабинете или через Telegram-бот @uchecker_bot, без банковской карты.

Валидация и верификация email: одно и то же?

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

Если всё-таки разводить термины, то по этапам. Валидацией обычно называют проверку формата адреса и домена, верификацией подтверждение того, что конкретный ящик существует и принимает почту. Уровней получается три:

• Синтаксическая валидация разбирает адрес по правилам RFC 5321 и 5322 и ловит пропущенную «собаку», пробелы, две точки подряд. Самый быстрый уровень и самый слабый: безупречно записанный адрес может вести в ящик, которого нет.
• DNS- и MX-валидация показывает, что у домена существует почтовый сервер. Проверка MX-записи отсекает мёртвые домены.
• SMTP-верификация ящика открывает соединение с почтовым сервером и проверяет существование адреса без отправки письма (HELO/EHLO, MAIL FROM, RCPT TO).

Владельцу базы важнее глубина, чем название. Форма на сайте заметит опечатку в записи, но не узнает, открыт ли ящик. Чтобы это выяснить, валидатор должен дойти до DNS и до почтового сервера домена, как бы он себя ни называл.

Как читать результат проверки

Отчёт делит адреса на три группы: рабочие (good), нерабочие (bad) и неопределённые (unknown). У рабочих сервер подтвердил существование ящика, на них можно писать. У нерабочих ящика нет, он переполнен или адрес записан с ошибкой. Их вы удаляете из базы навсегда и вносите в suppression-лист. Для нерабочих и неопределённых отчёт показывает причину в виде ответа сервера, и от неё зависит, что делать дальше.

Catch-all означает, что домен принимает почту на любой адрес, поэтому подтверждение ничего не доказывает. Такие адреса не выбрасывают: за catch-all часто стоят корпоративные домены с нужными контактами. Вынесите их в отдельный сегмент и отправляйте небольшими партиями, отслеживая отказы по факту.

У одноразовых ящик существует прямо сейчас и перестанет через час, отправлять на него бессмысленно. Ролевые вроде info@ или support@ существуют и читаются, но согласия на рассылку никто не давал, поэтому маркетинговое письмо туда почти наверняка соберёт жалобу. Оставьте их для транзакционных писем и уберите из рассылок.

Группа unknown собирает адреса, доставляемость которых определить не удалось. У домена нет MX-записей, ни один из его почтовых серверов недоступен, домен выглядит подозрительно или стоит в чёрных списках. Сюда же идут catch-all домены, серверы, которые так и не подтвердили ящик, и временные отказы, не прошедшие после повторных попыток. Писать на них сразу не стоит, лучше отложите и перепроверьте позже. Денег за unknown мы не берём: платить за ответ «не знаю» неправильно. Доля этой группы показывает качество самой проверки, потому что ноль неопределённых означает не идеальную точность, а то, что спорные случаи молча записали в рабочие.

Когда проверять базу

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

• перед первой рассылкой по новой базе, особенно если контакты копились долго, пришли из нескольких источников или достались от другой команды;
• после долгой паузы в отправках и перед реактивацией старого сегмента;
• при импорте чужого списка (проверка покажет состояние адресов, но права писать этим людям не даст);
• когда вырос bounce rate, чтобы отделить постоянные отказы от временных и не выбросить живой контакт после одного сбоя;
• когда сменился источник лидов или одна форма вдруг начала приносить много опечаток.

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

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

Что происходит с базой после проверки

Отчёт — это не конец работы, а её начало. Несуществующие адреса вы удаляете сразу и вносите в suppression-лист, чтобы они не вернулись при следующей загрузке из CRM. Это важнее, чем кажется: чаще всего мёртвые адреса возвращаются в рассылку именно потому, что список чистят в одном месте, а выгружают из другого.

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

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

Почему высокий процент отказов опасен

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

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

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

Отдельно про спам-ловушки

Самый неприятный тип мёртвого адреса тот, который технически жив. Провайдеры переоформляют заброшенные ящики в ловушки: MX на месте, SMTP отвечает подтверждением, синтаксис верный. Любая проверка признает такой адрес рабочим, потому что он и есть рабочий. Отличается только тем, что за ним никого нет.

Поэтому валидация снижает риск, но не снимает его. Она убирает мёртвые адреса и тем сокращает будущий приток переработанных ловушек. От уже существующей защищает только гигиена: подписка через double opt-in, регулярная чистка по вовлечённости и исключение тех, кто не открывал писем год.

Проверка в форме регистрации

Дешевле всего держать базу чистой, не пуская в неё мусор. Опечатка в домене вроде gmial.com или yandex.ry попадает в базу навсегда, если форма её не ловит, и превращается в отказ при первой же отправке. Проверка на этапе ввода стоит одного запроса и снимает основную часть проблемы.

Здесь важна скорость, а не глубина. Пока пользователь ждёт ответа, разумна быстрая проверка: синтаксис, наличие MX у домена, списки одноразовых сервисов. Она укладывается в сотни миллисекунд. Полная SMTP-верификация занимает секунды и зависит от чужого сервера, поэтому её ставят в фоновую задачу, а результат догоняет письмом или обновлением статуса.

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

Чем проверка отличается от отправки тестового письма

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

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

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

API для интеграции валидации в продукт

Кроме веб-кабинета и Telegram-бота, uChecker предоставляет REST API валидации email для встраивания проверки в форму регистрации, CRM (Bitrix24, amoCRM, HubSpot) или ESP. Поддерживается webhook для асинхронной обработки больших списков. Методы, примеры кода и форматы ответов собраны в документации API.

Хотите подробнее разобраться в терминах валидации email, доставляемости и аутентификации (SPF, DKIM, DMARC), загляните в наш глоссарий email-маркетинга и валидации (более 100 статей про SMTP, SPF, DKIM, DMARC, BIMI, bounce-коды, прогрев домена и почтовые протоколы) и блог про email-маркетинг и рассылки.