Механика проверки email: от формата адреса до ответа сервера

Проверка почтового адреса — это многоуровневый процесс, который гарантирует, что письмо не вернется отправителю с ошибкой. Он начинается с анализа синтаксиса (правильности написания), продолжается поиском почтовых серверов домена в системе DNS и завершается установлением соединения по протоколу SMTP для подтверждения существования ящика. Если хотя бы один из этих этапов провален, доставка письма невозможна.

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

Уровни валидации: от простого к сложному

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

1. Синтаксическая проверка (Format Validation)

Это первый и самый быстрый фильтр. Проверяется соответствие адреса стандарту RFC 5322.

• Что ищут: Наличие символа @, отсутствие пробелов, допустимые символы в локальной части (до @) и домене.
• Частые ошибки: Опечатки в доменной зоне (.con вместо .com), лишние точки, использование запрещенных символов.
• Результат: Если формат неверен, проверка останавливается мгновенно.

2. Проверка домена и MX-записей (DNS Lookup)

Если формат верен, система обращается к глобальной базе DNS, чтобы узнать, существует ли домен и куда слать почту.

• Поиск MX-записей: Система запрашивает записи типа MX (Mail Exchange). Они указывают на конкретные серверы, отвечающие за прием почты для этого домена.
• Приоритет: У каждой записи есть числовой приоритет. Чем он меньше, тем выше приоритет сервера. Проверка обычно идет по серверу с наименьшим числом.
• Резервный вариант: Если MX-записей нет, некоторые системы пытаются использовать A-запись самого домена, но это считается устаревшей практикой и часто приводит к ошибкам.

3. Проверка доступности сервера (SMTP Connection)

На этом этапе валидатор пытается установить реальное сетевое соединение с почтовым сервером получателя (обычно через порт 25, 587 или 465).

• Handshake: Сервер должен ответить приветственным кодом (обычно 220).
• Блокировки: Многие современные сервисы блокируют входящие соединения от неизвестных IP-адресов или облачных валидаторов, чтобы защититься от сканирования спам-ботами. В таком случае проверка может быть помечена как «невозможно проверить» (unknown), а не «невалиден».

Детали SMTP-диалога: как сервер подтверждает ящик

Самый глубокий уровень проверки — имитация отправки письма без реальной пересылки контента. Это называется SMTP Handshake. Вот как выглядит этот диалог между проверяющим сервисом (клиентом) и почтовым сервером получателя:

1. Приветствие: Клиент отправляет команду EHLO (или HELO), представляясь.
2. Инициализация отправителя: Команда MAIL FROM:<[email protected]>. Сервер проверяет, готов ли он принимать почту от этого отправителя (проверка черных списков, SPF).
3. Запрос получателя: Команда RCPT TO:<[email protected]>. Это ключевой момент. Именно здесь сервер решает, существует ли такой пользователь.
4. Анализ ответа:
   • Код 250 OK — ящик существует и готов принять письмо.
   • Код 550 5.1.1 — пользователь не найден (ящик не существует).
   • Код 4xx — временная ошибка (сервер перегружен, повторите позже).
5. Завершение: Если получен код успеха, клиент отправляет RSET или QUIT, не передавая тело письма (DATA).

Расшифровка кодов ответов сервера

Понимание кодов состояния SMTP помогает правильно настроить очистку базы подписчиков.

Практические рекомендации для маркетологов и разработчиков

Для поддержания высокой репутации отправителя и низкой процента отказов (bounce rate) следуйте этим правилам:

1. Используйте двойной уровень очистки: Сначала жесткая фильтрация по синтаксису и наличию MX, затем — выборочная или полная проверка через SMTP для активных сегментов базы.
2. Не игнорируйте «серые» зоны: Адреса с временными ошибками (4xx) не нужно удалять сразу. Повторите проверку через 24–48 часов. Если ошибка сохраняется — удаляйте.
3. Double Opt-In (DOI): Лучшая защита от битых адресов — подтверждение подписки по ссылке в письме. Это гарантирует, что адрес не только существует, но и доступен владельцу.
4. Уважайте лимиты: При массовой проверке своей базы делайте паузы между запросами к одному домену, чтобы ваш IP не попал в блокировку за подозрительную активность.

Частые ошибки при проверке

• Слишком агрессивная частота запросов: Попытка проверить 1000 адресов одного домена за минуту приведет к бану вашего IP почтовым сервером.
• Игнорирование роли Catch-all: Помечать все адреса на доменах с политикой catch-all как «валидные» рискованно. Лучше помечать их как «risk» или «unknown» и тестировать отправкой пробного письма.
• Проверка только синтаксиса: Регулярные выражения не могут сказать, зарегистрирован ли домен или существует ли пользователь. Полагаться только на них — путь к высокому проценту возвратов.

FAQ

Можно ли со 100% гарантией узнать, существует ли ящик? Нет. Из-за настроек безопасности (catch-all, серые списки, блокировка соединений от валидаторов) некоторые серверы намеренно скрывают информацию о существовании конкретных пользователей.

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

Зачем проверять MX-записи, если сайт работает? Сайт размещается на веб-сервере (А-запись), а почта — на почтовом (MX-запись). Это могут быть совершенно разные машины и даже разные провайдеры. Работающий сайт не гарантирует работу почты.

Что такое Soft Bounce и Hard Bounce?

• Hard Bounce (5xx): Постоянная ошибка (несуществующий адрес). Требует немедленного удаления.
• Soft Bounce (4xx): Временная проблема (переполненный ящик, сбой сети). Требует повторной попытки позже.