Email-верификация против Email-валидации: что показывает каждый этап

Email-валидация подтверждает, что адрес написан правильно; email-верификация проверяет, является ли он доставляемым на момент проверки, и каждый из этих этапов занимает свое место в рабочем процессе.

Разница между email-верификацией и email-валидацией сводится к двум разным вопросам. Валидация проверяет, написан ли адрес в допустимом формате: наличие одного символа @, локальной части, домена и отсутствие недопустимых символов. Верификация проверяет, является ли корректно оформленный адрес доставляемым, то есть может ли он получать почту на момент проверки. Валидация выполняется мгновенно в вашем коде и ничего не стоит, но она не может определить, существует ли почтовый ящик. Проверка доставляемости, такая как Проверка доставляемости email от EmailCheckPro, возвращает результат Доставляемый или Недоставляемый, не отправляя ничего на проверяемый адрес. Большинству команд нужны оба этапа: сначала валидация для выявления опечаток, а затем проверка доставляемости для адресов, прошедших первый этап.

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

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

• Наличие ровно одного символа @, разделяющего локальную часть и домен.
• Отсутствие пробелов, запятых или специальных символов без кавычек.
• Домен, содержащий как минимум одну точку и правдоподобную доменную зону верхнего уровня.
• Ограничения по длине. RFC 5321 ограничивает локальную часть 64 октетами, а полный путь — 256 октетами, поэтому адреса длиннее этого значения можно смело отклонять.

Браузеры уже применяют намеренно упрощенный набор правил для <input type="email">; HTML Living Standard описывает это определение как намеренное нарушение полной грамматики RFC 5322, выбранное потому, что полная грамматика допускает строки, которые реальные пользователи никогда не вводят.

Не менее важно и то, чего валидация сделать не может. Адреса jane.doe@example.com и jdoe1987@example.com проходят все правила формата, однако один из них может быть рабочим почтовым ящиком, а второй — никогда не существовать. Проверка формата также не может обнаружить опечатку в корректно сформированном домене, например gmial.com, поскольку синтаксически эта строка верна.

Что показывает этап email-верификации

Верификация начинается там, где заканчиваются правила формата. С помощью EmailCheckPro завершенная Проверка доставляемости email сообщает один из двух результатов для корректно оформленного адреса:

• Доставляемый: адрес мог получать почту на момент проверки.
• Недоставляемый: адрес не мог получать почту на момент проверки.

Третья ситуация обрабатывается отдельно. Некоторые домены принимают почту для любой локальной части (домены Catch-All), поэтому подтвердить наличие конкретного почтового ящика невозможно. EmailCheckPro помечает их как Не определено, а не пытается угадать; при выполнении запроса в реальном времени возвращается ненулевой бизнес-код без результата, и плата за такую проверку не взимается.

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

Верификация также имеет свои границы. Она информирует о том, может ли адрес получать почту; она ничего не говорит о том, кто управляет почтовым ящиком или давал ли владелец согласие на получение писем от вас.

Email-верификация против Email-валидации: сравнение

Таблица показывает, почему эти этапы следует использовать последовательно, а не заменять один другим. Валидация дешева и отфильтровывает очевидный «мусор» до того, как вы потратите ресурсы. Проверка доставляемости — единственный из двух методов, который взаимодействует с самим почтовым ящиком. Адрес, не прошедший валидацию, является просто некорректным вводом; его не следует записывать как Недоставляемый, поскольку вопрос о доставляемости для него даже не ставился.

Где каждый этап должен находиться в процессе регистрации

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

1. Выполняйте валидацию в браузере и на сервере. Используйте type="email" для немедленной обратной связи, а затем повторите те же правила на стороне сервера, так как клиентские проверки можно обойти.
2. Предлагайте исправления для распространенных опечаток в доменах. Короткий список частых ошибок (gmial.com, hotmial.com) поможет исправить опечатки, которые проходят проверку формата.
3. Запускайте единичную проверку доставляемости. Вызывайте POST /api/v1/check с введенным адресом после того, как он пройдет валидацию.
4. Действуйте в зависимости от результата. Доставляемый: продолжайте. Недоставляемый: попросите пользователя проверить адрес, вместо того чтобы молча отклонять его. Не определено: завершите регистрацию и полагайтесь на обычное подтверждающее письмо.
5. Сохраняйте результат с отметкой времени. Это позволит службам поддержки видеть состояние адреса на момент регистрации.

Делайте сообщение о недоставляемости дружелюбным и конкретным, например: «Мы не смогли подтвердить, что этот адрес может получать почту. Пожалуйста, проверьте правильность написания». Жесткая блокировка без объяснения причин часто расстраивает добросовестных пользователей, допустивших опечатку в одном символе.

Где каждый этап должен находиться при импорте списков

Импорт из мероприятий, электронных таблиц или старых CRM обычно содержит множество проблем, поэтому выполняйте валидацию как этап очистки перед любой проверкой:

1. Нормализуйте. Удалите лишние пробелы, приведите домен к нижнему регистру и разделите ячейки, содержащие два адреса.
2. Выполните валидацию и отложите ошибки. Поместите строки, не прошедшие правила формата, в категорию «некорректный ввод» для ручной проверки.
3. Удалите дубликаты. Один и тот же адрес в трех строках требует только одной проверки.
4. Выберите тип запроса в зависимости от объема. Для небольшого списка POST /api/v1/batch-check принимает от 1 до 100 адресов и возвращает результаты в порядке ввода в одном ответе. Для большого файла POST /api/v1/bulk-tasks принимает TXT или CSV с одним полным адресом в строке; задача выполняется асинхронно, и вы опрашиваете GET /api/v1/bulk-tasks/{id}, пока результат CSV не будет готов. Ограничения задач для каждого продукта указаны в документации API EmailCheckPro.
5. Используйте четыре категории. Доставляемый, Недоставляемый, Не определено и некорректный ввод — каждая из них требует своего владельца и следующего шага.

В синхронном ответе для нескольких адресов запись без завершенного результата — это не то же самое, что вердикт Недоставляемый. Рассматривайте это как «не проверено» и повторите попытку позже.

Распространенные ошибки при сочетании этих методов

• Использование слишком строгих Regex. Шаблоны, которые отклоняют теги + или длинные доменные зоны, отсеивают реальных пользователей. Отдавайте предпочтение разрешающим правилам формата в сочетании с проверкой доставляемости.
• Смешивание некорректного ввода и недоставляемых адресов. Они возникают на разных этапах и требуют разных исправлений: некорректный ввод обычно требует исправления человеком, в то время как Недоставляемый может означать, что почтовый ящик закрыт.
• Угадывание для доменов Catch-All. Пометка всех адресов со статусом Не определено как плохих удаляет реальные контакты; пометка их всех как хороших скрывает риски. Держите их в отдельном сегменте.
• Бессрочное повторное использование старых результатов. Повторно проверяйте адреса перед крупной рассылкой, если последнему результату уже несколько месяцев.
• Отношение к верификации как к получению согласия. Результат Доставляемый информирует только о качестве списка; обработка согласий и отказов от рассылки — это отдельные обязательства.

Часто задаваемые вопросы

Как командам решить, достаточно ли только валидации формата?

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

Как командам следует хранить результаты верификации в базе данных?

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

Как разработчикам обрабатывать результат «Не определено» при регистрации?

Позвольте регистрации продолжиться. Результат Не определено обычно исходит от домена Catch-All, где наличие конкретного почтового ящика подтвердить невозможно, поэтому блокировка таких адресов отсеет реальных пользователей. Пометьте запись во внутренней системе, отправьте обычное подтверждающее или приветственное письмо и используйте результат этого сообщения, например клик или возврат (bounce), чтобы определить следующий шаг.

Узнайте больше

Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.

• Просмотреть документацию по продукту →
• Связаться с командой →