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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Несуществующие ящики дают хард-баунсы, которые гарантированно отвалятся при рассылке и ударят по репутации.
• Переполненные и замороженные ящики, где сервер принимает соединение, но письмо не доставит.
• Домены без MX-записей и домены, чьи почтовые серверы не отвечают на запросы.
• Домены в публичных чёрных списках вроде DNSBL, Spamhaus и URIBL.
• Опечатки в доменах: gmal.com, yandx.ru, 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-базы используются как синонимы. На практике различают три уровня:

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

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

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

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

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

Пятая группа называется unknown. В неё попадают адреса, по которым сервер не дал внятного ответа из-за грейлистинга или лимита запросов; в расширенном статусе такой адрес помечен как risk. Денег за unknown мы не берём: платить за ответ «не знаю» неправильно. Доля этой группы показывает качество самой проверки, потому что ноль неопределённых означает не идеальную точность, а то, что спорные случаи молча записали в рабочие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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