Как работает валидатор email технически
Шесть этапов, которые email проходит от ввода до вердикта «good». Без абстракций - с DNS-запросами, SMTP-командами и реальными ответами серверов.
Большинство людей представляют валидацию email как проверку «есть ли собака в адресе». В реальности это цепочка из шести независимых этапов, каждый из которых может забраковать адрес. Причём самый первый - синтаксис - отсеивает всего 2-3% невалидных адресов. Остальные 97% ловятся глубже.
Я разберу каждый этап так, как он устроен внутри реальных валидаторов. Не «в теории», а с конкретными запросами и ответами. Если вы разработчик - сможете собрать свой валидатор. Если маркетолог - поймёте, почему проверка занимает время и за что вы платите.
Синтаксическая проверка
Первый фильтр - RFC 5322. Адрес разбивается на local-part и domain. Проверяется длина (до 254 символов), допустимые символы, отсутствие двух точек подряд, корректность кавычек.
Частая ошибка: думать, что regex справится. Формальная грамматика email-адреса - 6 343 символа регулярного выражения. На практике используют парсер, а не regex.
Примеры провалов:
user@.domain.com → ❌ точка сразу после @
user@domain → ❌ нет TLD (хотя формально валидно по RFC)
"user name"@domain.com → ✅ валидно, но подозрительноDNS: поиск MX-записей
Домен прошёл синтаксис - теперь проверяем, может ли он вообще принимать почту. Отправляем DNS-запрос типа MX для домена.
dig MX gmail.com
;; ANSWER: gmail-smtp-in.l.google.com. (приоритет 5)
;; alt1.gmail-smtp-in.l.google.com. (приоритет 10)Если MX-записей нет - пробуем A-запись (fallback по RFC 5321). Если и A нет - домен не принимает почту. Адрес невалиден, дальше проверять бессмысленно.
Нюанс: некоторые домены возвращают MX с приоритетом 0 и hostname «.» - это явный отказ принимать почту (null MX, RFC 7505). Такие адреса тоже отбраковываем.
SMTP Handshake
Главный этап. Подключаемся к MX-серверу и имитируем начало отправки письма - но не отправляем его. Это называется SMTP callback verification.
EHLO validator.example.com
250 mx.google.com at your service
MAIL FROM:<check@validator.example.com>
250 OK
RCPT TO:<test@gmail.com>
550 5.1.1 The email account does not exist.Код 250 на RCPT TO - ящик существует. Код 550 - не существует. Всё остальное - серая зона: 450 (попробуйте позже), 421 (сервер перегружен), 552 (ящик переполнен).
Важно: мы не отправляем DATA. Соединение обрывается после RCPT TO. Письмо не доставляется, нагрузка на сервер минимальна.
Здесь и кроется основная сложность. Google, Yahoo, Microsoft - все они умеют распознавать массовые SMTP-проверки и начинают отвечать 250 на любой адрес (даже несуществующий), чтобы защитить приватность пользователей. Хороший валидатор использует ротацию IP, троттлинг и знает особенности каждого провайдера.
Catch-all детекция
Некоторые домены настроены принимать почту на любой адрес - catch-all (или wildcard). Отправьте письмо на x7k9m2q@domain.com - и сервер ответит 250 OK. Это значит, что положительный ответ SMTP ничего не доказывает.
Как детектим: отправляем RCPT TO на заведомо несуществующий адрес (случайная строка). Если сервер говорит 250 - это catch-all. Помечаем адрес как «accept-all» и предупреждаем: валидность не гарантирована.
По нашим данным, около 18% корпоративных доменов используют catch-all. Для маркетологов это головная боль: такие адреса раздувают bounce rate, если реальный ящик не существует.
Disposable & temporary
Адрес существует, домен принимает почту - но домен одноразовый. Tempmail, Guerrilla Mail, Mailinator и ещё ~40 000 доменов, которые создают ящики на 10 минут и удаляют.
Проверка - по базе. Хорошие валидаторы обновляют список disposable-доменов ежедневно, потому что новые появляются каждый день. Это гонка: сервисы одноразовой почты регистрируют свежие домены, валидаторы их добавляют в чёрный список.
Дополнительно проверяем паттерны: если домен зарегистрирован вчера и MX указывает на известный disposable-хост - флаг «risk» даже без попадания в базу.
Финальный вердикт
Все этапы пройдены. Валидатор собирает результаты в единый ответ:
{
"email": "user@company.com",
"status": "valid",
"mx_found": true,
"smtp_check": true,
"catch_all": false,
"disposable": false,
"score": 0.95
}Score - это не бинарный ответ. Адрес на catch-all домене получит 0.6, на disposable - 0.1. Чистый valid с SMTP-подтверждением - 0.9+. Именно score помогает принимать решения: для транзакционных писем порог один, для маркетинговых рассылок - другой.
Почему нельзя просто отправить письмо?
Логичный вопрос: зачем весь этот SMTP-театр, если можно отправить реальное письмо и посмотреть на bounce? Три причины.
Первая: bounce приходит не мгновенно. Иногда через минуты, иногда через дни. Для проверки базы в 100 000 адресов это неприемлемо.
Вторая: каждый bounce портит репутацию вашего отправляющего домена. ISP считают bounce rate, и если он превышает 2-3% - ваши письма начинают попадать в спам. Вы буквально жжёте свой домен, проверяя адреса «боевыми» отправками.
Третья: это дорого. Каждое отправленное письмо - это ресурсы ESP, которые вы оплачиваете. Валидация дешевле отправки на порядок.
Что отличает хороший валидатор от плохого
Синтаксис и DNS проверяют все - это тривиально. Разница начинается на этапе SMTP. Дешёвые сервисы отправляют запросы с одного IP без троттлинга, получают ложные 250 от Google и выдают «good» на мёртвые адреса.
Хороший валидатор знает, что Gmail отвечает 550 только при определённых условиях. Что Yahoo иногда greylisting-ит первый запрос. Что Outlook возвращает 550 на несуществующие ящики, но иногда делает это с задержкой в 5 секунд.
В uChecker мы обрабатываем эти edge cases для каждого крупного провайдера отдельно. Это не регулярка на 10 строк - это инженерная работа, которая заняла месяцы.
Попробуйте сами
Загрузите базу и посмотрите, сколько адресов пройдут все 6 этапов. Первые 100 проверок - бесплатно.
Проверить email-базу →