Валидация email-адресов: как проверить базу и разобрать результаты

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

Валидация email помогает сделать это до отправки: сохраните исходную базу, проверьте адреса и запишите результат рядом с каждым контактом. Явно недействительные адреса исключите из активного списка, а unknown и catch-all не смешивайте с подтверждёнными. Статус valid тоже не гарантирует, что письмо попадёт во входящие или что адрес принадлежит нужному человеку.

Короткий порядок работы:

Сохранить исходную таблицу и ID каждой строки.
Исправить очевидные опечатки, не угадывая адрес за человека.
Проверить адреса по одному или загрузить список в валидатор.
Вернуть статусы к исходным контактам и сверить строки.
Принять отдельное решение для valid, invalid, unknown и catch-all.

Ноутбук со списком контактов, конверт и карточки на столе — Работа с базой контактов

Содержание: Что проверяет валидатор · Как подготовить список · Как проверить адреса · Как разобрать статусы · Как вернуть результат в базу · Когда проверять повторно · Как выбрать сервис

Что проверяет валидатор

У проверки email несколько уровней. Сервис может посмотреть, правильно ли записан адрес, существует ли домен, есть ли у него почтовая инфраструктура и что отвечает почтовый сервер на попытку проверить конкретный ящик. Некоторые сервисы дополнительно отмечают временные, ролевые и catch-all адреса. Набор проверок зависит от инструмента. Например, Hunter описывает свои проверки отдельно для формата, домена, SMTP-сервера и accept-all.

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

Есть и техническая тонкость. Некоторые сервисы показывают отсутствие MX-записи как проблему домена. Но почтовый стандарт допускает доставку через адресную запись домена, если MX не задан. Поэтому отдельный признак MX not found стоит читать вместе с остальными результатами, а не превращать в универсальное правило «почта не работает». Это следует из RFC 5321.

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

Как подготовить список

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

Поле	Зачем оно нужно
ID строки	Вернуть результат к исходному контакту, даже если порядок строк изменится
Компания и домен	Проверить, что адрес относится к нужной организации
Имя и роль контакта	Не спутать технически рабочий ящик с нужным человеком
Исходный email	Сохранить то, что было до исправлений
Источник и дата получения	Понять происхождение и возраст контакта
Новый статус и дата проверки	Принять решение и позже понять, когда его пересмотреть

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

Если в базе один email повторяется у нескольких строк, можно не платить за одинаковую проверку несколько раз. Но результат всё равно нужно вернуть ко всем связанным записям и разобраться, почему контакт продублирован. Для сверки используйте ID строки и исходный email. Перед сравнением можно убрать пробелы по краям адреса и привести к одному регистру доменную часть после @. Часть до @ автоматически не меняйте.

Результат этапа: у вас есть исходная база, отдельная рабочая копия и понятное число уникальных адресов для проверки.

Как проверить адреса

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

Для списка используйте пакетную проверку. Например, Hunter описывает маршрут: открыть Bulk Email Verifier, загрузить CSV или вставить список, дождаться обработки и скачать результат. Скачайте результаты по всем статусам, включая unknown и catch-all. Отфильтрованная выгрузка или импорт в список лидов может скрыть часть адресов. Это пример доступного рабочего маршрута, а не утверждение, что Hunter лучше остальных. Перед загрузкой реальной базы проверьте, какие столбцы сервис сохранит в выгрузке. Если он принимает только адреса, соединять результат с исходной таблицей придётся отдельно.

Не удаляйте строки, по которым сервис не дал ответа. После пакетной проверки сверьте число отправленных адресов с числом результатов. Часть адресов может остаться без результата из-за лимита сервиса. После выгрузки отдельно отметьте адреса, которые сервис пропустил или которые не удалось сопоставить с исходной строкой. Не присваивайте им valid либо invalid; сохраните причину и следующий шаг.

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

Как разобрать статусы

Названия и правила у сервисов отличаются. Смотрите не только общий статус, но и причину. Например, ZeroBounce отдельно возвращает статус и подстатус, а Hunter использует собственную классификацию.

Результат	Что он позволяет сказать	Что делать с записью
`valid`	Адрес прошёл проверки этого сервиса на момент запроса	Сохранить результат и дату. Отдельно проверить компанию, человека и допустимость контакта
`invalid`	Адрес не прошёл проверку или сервер отказал в приёме	Убрать email из активного списка. Контакт и компанию не удалять автоматически
`unknown`	Сервис не смог установить результат	Оставить отдельный статус. Посмотреть причину и решить, есть ли смысл повторить проверку позже
`catch-all` или `accept-all`	Домен может принимать письма на разные адреса без подтверждения конкретного ящика	Не считать ящик подтверждённым. Искать дополнительное подтверждение контакта
Ролевой адрес, например `info@`	Ящик может обслуживать команду, а не нужного человека	Оценить, подходит ли такой канал для задачи; не подменять им контакт ЛПР
Одноразовый адрес	Адрес может быть временным	Не считать его устойчивым рабочим контактом

Это редакционное правило принятия решений, а не обещание определённого процента доставок. Например, Hunter допускает осторожное использование accept-all, но одновременно пишет, что конкретный ящик при таком статусе подтвердить нельзя. Для B2B-базы разумнее хранить эту неопределённость явно, чем записывать её как valid. Hunter: значения статусов.

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

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

Как вернуть результат в базу

После скачивания файла не заменяйте исходную таблицу целиком. Соедините результаты с рабочей копией по ID строки. Если сервис не сохранил ID, используйте email и дополнительно проверьте дубли: один адрес может относиться к нескольким исходным строкам.

Добавьте как минимум четыре поля: статус, причина, сервис, дата проверки. Отдельное поле решение команды позволит не путать ответ инструмента с вашим действием. Например, сервис вернул catch-all, а команда записала «нужно подтвердить адрес другим источником».

Проверьте итог:

Сколько адресов отправлено и сколько результатов получено.
Какие строки пропущены или остались без ответа.
Не изменились ли компания и контакт у нескольких проверенных строк.
Не попал ли unknown в группу valid из-за фильтра или формулы.
Есть ли причина исключения, если адрес убран из активной работы.

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

Учебный пример: строка A получила valid, поэтому осталось проверить связь адреса с нужным человеком. Строка B получила catch-all и требует другого подтверждения. Строка C получила unknown, причину которого нужно выяснить до следующего решения. Это вымышленные записи, а не результаты проверки реальной базы.

Когда проверять повторно

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

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

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

Отдельно от технической проверки решается вопрос, можно ли вообще писать человеку. Наличие адреса в открытом источнике и статус valid сами по себе такого разрешения не дают. Правила зависят от страны и типа адресата. Например, британский регулятор ICO различает корпоративных и индивидуальных подписчиков и отдельно рассматривает обработку персональных данных B2B-контактов.

Как выбрать сервис

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

различает ли сервис invalid, unknown и catch-all;
показывает ли причину или подстатус;
можно ли выгрузить все результаты, включая неопределённые;
сохраняются ли ваши исходные столбцы;
что происходит со строками сверх лимита;
сколько стоят именно обработанные адреса;
как долго сервис хранит загруженный файл и как его удалить;
нужен ли вам API или достаточно разовой загрузки.

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

Не нужно искать инструмент, который обещает «точно узнать, существует ли любой ящик». Catch-all, блокировка проверок и временные ошибки делают такой ответ невозможным для части адресов. Хороший рабочий результат выглядит скромнее: вы убрали явные ошибки, сохранили неопределённость отдельным статусом и можете объяснить решение по каждой строке.

Вывод

Валидация email полезна тогда, когда после неё база становится понятнее. Для каждого адреса сохранены исходное значение, дата проверки, результат и принятое решение. Invalid исключён из активного списка, unknown и catch-all не названы подтверждёнными, а valid не превращён в гарантию доставки или разрешение на рассылку.

Валидация email: как проверить B2B-адреса и разобрать результаты