Проверка email-адреса собирает технические свидетельства до того, как вы начнете пользоваться адресом. Сначала проверяются его структура, домен и почтовый маршрут. Затем, если принимающий сервер это допускает, можно узнать его реакцию на конкретного получателя. Каждый этап добавляет сведения, но не гарантирует доставку будущего письма.
Это различие важно при регистрации, работе с отдельным контактом и проверке списка. Адрес может выглядеть правдоподобно, а вопрос о его ящике все равно останется открытым.
Формат, проверка и подтверждение — разные вопросы
Словом «валидация» иногда называют всю техническую проверку. Но проверка одного лишь формата решает гораздо более узкую задачу:
| Вопрос | Способ | Что становится известно |
|---|---|---|
| Адрес правильно записан? | Проверка синтаксиса | Локальная часть и домен соответствуют правилам записи. Существование домена и ящика не подтверждено. |
| Может ли адрес принимать почту? | Проверка до отправки | Что показывают DNS, маршрут и, если доступно, ответ почтового сервера. |
| Контролирует ли человек этот ящик? | Подтверждение письмом | Кто-то открыл ссылку или ввел код из письма в этот момент. |
Чтобы решить, может ли проверка заменить ссылку из письма, прочитайте сравнение проверки email и подтверждения адреса.
Если инструмент смотрит только на формат, ответить на второй вопрос он не может. Сравнение SMTP-проверки и проверки синтаксиса поможет выбрать нужную глубину.
Из каких этапов состоит проверка
Emvero продолжает проверку, пока это нужно и возможно. Явная ошибка может остановить ее еще до связи с почтовым сервером. Но даже полная проверка иногда заканчивается статусом unknown.
1. Синтаксис: можно ли так записать адрес?
Система разбирает локальную часть до @, домен после него и адрес целиком. Ошибку записи можно обнаружить без сетевых запросов. Прошедший этот этап адрес пока ничего не говорит о существовании домена или ящика. Подробности есть в статье о синтаксисе email-адресов.
Пример проверки email-адреса в JavaScript показывает, как добавить этот первый этап в форму.
2. Домен: известен ли он DNS?
Если DNS однозначно сообщает, что домена нет, это сильное отрицательное свидетельство. Но существующий домен может обслуживать сайт и не принимать почту. Положительный ответ DNS позволяет продолжить проверку, не доказывая существование получателя.
3. Маршрут: куда направлять письмо?
Обычно серверы для приема почты указаны в MX-записях. Null MX прямо объявляет, что домен почту не принимает. Отсутствие MX само по себе не означает ошибку: SMTP допускает неявный маршрут через узел домена. Эти случаи разобраны в материале об MX-записях. Даже рабочий маршрут относится ко всему домену, а не к конкретному ящику. Неявный маршрут описан в RFC 5321, разделе 5.1, а Null MX — в RFC 7505.
Проверка домена заканчивается здесь: SMTP-соединение не открывается. Для ответа о получателе нужна полная проверка.
4. Получатель: что отвечает почтовый сервер?
Если принимающая сторона разрешает такой запрос, полная проверка называет серверу конкретный адрес. Сервер может принять его, отклонить, отложить решение или скрыть правила обработки получателей. Даже ответ, классифицированный как «ящик не найден», по текущим правилам Emvero оставляет unknown: адрес автоматически не отклоняется. Достоверное отсутствие домена или явная null MX-запись могут обосновать undeliverable ещё до SMTP. Принятие адреса полезно, но иногда отражает лишь правила catch-all домена.
SMTP-проба останавливается на конверте письма:
EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<person@example.com>
RSET
QUIT
Команда DATA начала бы передачу содержимого. При проверке Emvero до нее не доходит и не отправляет проверочное письмо. Последовательность описана в RFC 5321, разделе 3.3. Там же поясняется, что некоторые серверы откладывают решение о получателе. Отдельно можно прочитать о SMTP-рукопожатии.
5. Оценка: какой вывод допускают свидетельства?
Emvero учитывает собранные ответы и дополнительные признаки: catch-all поведение, провайдера временной почты, вероятную опечатку в домене, ролевой адрес вроде support@. Временный или ролевой ящик может действительно принимать письма. Подходит ли он для вашей задачи, определяют ваши правила. А принятие адреса на catch-all домене может характеризовать общую политику сервера, а не этот ящик.
Когда точного ответа нет
Сервер может замедлить запрос, временно отложить ответ или не раскрывать сведения о получателях. Иногда истекает время соединения. Ни один из этих случаев не доказывает, что адрес недоставляемый. Если сервер принимает произвольные имена, положительный ответ на RCPT TO тоже не подтверждает отдельный ящик. Поэтому завершенная проверка может дать risky или unknown.
Как читать результат
У status есть четыре итоговых значения:
status |
Смысл |
|---|---|
deliverable |
Маршрут и доступные свидетельства о получателе говорят в пользу приема письма, но не гарантируют будущую доставку. |
risky |
Почта может дойти, однако есть конкретный признак риска. |
undeliverable |
Постоянная техническая причина поддерживает отказ от адреса. |
unknown |
Собранных свидетельств недостаточно для вывода. |
pending означает, что работа еще идет или ждет очереди. Это состояние обработки, а не пятый вердикт. Результат нужно запросить снова через указанный интервал.
Остальные поля помогают понять основание вывода. checks показывает результаты этапов, reason_codes перечисляет причины, freshness указывает время наблюдений DNS и SMTP. confidence — оценка силы свидетельств, а не вероятность доставки. Поле action рекомендует allow, allow_with_email_confirmation или reject. Рекомендация не выводится автоматически из status: для risky возможны и allow, и allow_with_email_confirmation в зависимости от причины. Подробности есть в статье о чтении результата проверки и на странице API проверки email-адресов.
Как использовать эти сведения
Для одного адреса смотрите не только на статус, но и на причины. unknown не означает «недействительный». Можно проверить отдельный адрес и увидеть свидетельства рядом с выводом.
При регистрации или оформлении заказа явная техническая ошибка позволяет попросить исправить адрес. Вероятную опечатку человек может устранить сразу. Если важно доказать контроль над ящиком, после risky или unknown уместно подтверждение письмом. Руководство по форме регистрации помогает связать результат с решением в форме.
Для существующего списка разделяйте доказанные ошибки, признаки риска и неясные случаи. Смотрите на freshness: старые ответы DNS и почтового сервера не остаются верными навсегда. Временный или ролевой адрес требует отдельного решения по вашим правилам, даже если технически доступен.
Проверка не доказывает личность, согласие на рассылку, будущий интерес, попадание во входящие или доставку следующего письма. Подтверждение показывает лишь контроль над ящиком в момент действия с письмом. Используйте каждый вид свидетельств для тех решений, которые он действительно может обосновать.