Проверка существования почтового ящика

Проверка существования почтового ящика (mailbox existence check) - процедура, при которой система определяет, есть ли на почтовом сервере конкретный ящик и готов ли он принимать входящие сообщения. Это ключевой этап валидации email-адреса: синтаксис может быть безупречным, домен - рабочим, MX-записи - на месте, но если ящика user@ не существует, письмо вернётся с ошибкой hard bounce.

Зачем проверять существование ящика

Когда вы отправляете рассылку на несуществующий адрес, почтовый сервер получателя возвращает уведомление о недоставке (bounce). Единичный bounce - мелочь. Сотни или тысячи bounces из одной рассылки - проблема. Почтовые провайдеры (Gmail, Mail.ru, Яндекс) отслеживают долю возвратов в рассылках каждого отправителя. Если bounce rate превышает 2-3%, репутация IP-адреса и домена начинает падать. Письма чаще уходят в спам, а в тяжёлых случаях отправитель попадает в блок-листы.

Проверка существования ящика до отправки устраняет эту проблему в источнике. Адреса, на которые невозможно доставить письмо, отсеиваются заранее. Рассылка уходит только на живые ящики, bounce rate остаётся низким, репутация отправителя не страдает.

Как это работает на техническом уровне

Основной метод - SMTP-диалог с почтовым сервером получателя. Валидатор подключается к серверу и имитирует начальный этап отправки письма, но обрывает соединение до фактической передачи данных. Этот процесс называют SMTP handshake. Последовательность:

1. Валидатор определяет MX-записи домена через DNS-запрос.
2. Открывает TCP-соединение на порт 25 к почтовому серверу с наивысшим приоритетом.
3. Отправляет команду EHLO для представления.
4. Отправляет MAIL FROM с техническим адресом отправителя.
5. Отправляет RCPT TO с проверяемым адресом. Это ключевой момент: сервер отвечает, готов ли он принять письмо для этого ящика.
6. Команда DATA не отправляется. Соединение закрывается через QUIT. Письмо не доставлено, но ответ получен.

Ответ сервера на RCPT TO определяет результат. Код 250 означает, что ящик существует и сервер готов принять письмо. Код 550 - ящик не найден или заблокирован. Код 450 - временный отказ, часто вызванный грейлистингом или превышением лимитов подключений.

Место проверки в цепочке валидации

Полноценная валидация email проходит несколько уровней. Сначала - синтаксическая проверка: правильный ли формат адреса, нет ли запрещённых символов, корректна ли доменная часть. Затем - DNS-проверка: существует ли домен и есть ли у него MX-записи, указывающие на почтовый сервер. Только после этого начинается SMTP-диалог для проверки конкретного ящика.

Такая последовательность экономит ресурсы. SMTP-подключение - самая долгая и ресурсоёмкая часть валидации. Нет смысла тратить на него время, если адрес содержит синтаксическую ошибку или домен не существует. Синтаксис отсекает грубые ошибки за микросекунды, DNS - за миллисекунды. На SMTP остаются только адреса, прошедшие первые два фильтра.

Ограничения метода

SMTP-проверка существования ящика не даёт стопроцентной гарантии. Есть несколько ситуаций, в которых результат оказывается неоднозначным:

• Catch-all домены. Сервер настроен принимать почту на любой адрес в домене, включая несуществующие. На команду RCPT TO он ответит 250 для абсолютно любого ящика. Валидатор видит положительный ответ, но фактически ящик может не существовать. Письмо будет принято сервером, однако пользователь его не прочитает.
• Грейлистинг. Антиспам-техника, при которой сервер отклоняет первое подключение от незнакомого IP с кодом 450 и ожидает повторной попытки через несколько минут. Легитимный почтовый сервер повторит попытку; спам-бот - нет. Для валидатора это проблема: одного запроса недостаточно, нужна повторная попытка с задержкой.
• Rate limiting. Крупные почтовые провайдеры ограничивают число SMTP-подключений с одного IP-адреса за единицу времени. При массовой проверке часть запросов получает отказ не потому, что ящика нет, а потому, что превышен лимит подключений.
• Отложенная проверка. Некоторые серверы принимают команду RCPT TO безусловно, а проверяют существование ящика позже, на этапе DATA. Поскольку валидатор не доходит до DATA, он получает ложное подтверждение.
• Блокировка по IP. Если IP-адрес валидатора попал в чёрный список или вызвал подозрение у антиспам-фильтра, сервер отклонит все запросы независимо от того, существуют ящики или нет.

Дополнительные сигналы для повышения точности

Из-за перечисленных ограничений профессиональные сервисы валидации не полагаются только на SMTP-ответ. Они собирают и анализируют дополнительные данные:

• Возраст домена. Домен, зарегистрированный вчера, с большей вероятностью используется для мусорных адресов, чем домен с десятилетней историей.
• Одноразовые почты. Сервисы вроде Guerrilla Mail или Mailinator создают временные ящики, которые существуют несколько часов. SMTP-проверка покажет, что ящик валиден, но для рассылки он бесполезен - через день его не станет.
• Ролевые адреса. Ящики вроде info@, support@, admin@ привязаны к функции, а не к человеку. Они существуют и принимают почту, но рассылки на ролевые адреса чаще получают жалобы на спам.
• Исторические данные. Если адрес при предыдущих проверках возвращал hard bounce, высока вероятность, что он не заработает снова. Сервис может хранить агрегированную статистику по доменам и паттернам.

Точность проверки

Для обычных доменов (не catch-all, без грейлистинга) точность SMTP-проверки существования ящика достигает 95-98%. Оставшиеся 2-5% - ложноположительные результаты (сервер ответил 250, но ящик не работает) и ложноотрицательные (сервер отклонил по побочной причине, хотя ящик существует).

Для catch-all доменов точность падает: все адреса получают статус «неопределённый». Для доменов с грейлистингом повторная проверка через 5-10 минут восстанавливает точность до нормального уровня. Именно поэтому серьёзные валидаторы не делают одну попытку - они возвращаются к адресам с неоднозначным результатом.

Пакетная и real-time проверка

Проверку существования ящика можно запускать в двух режимах. Пакетный - загрузка списка адресов, обработка всего списка, получение результата в файле. Подходит для очистки базы перед рассылкой. Real-time - проверка одного адреса через API в момент его ввода на сайте. Подходит для защиты от невалидных адресов на входе.

Пакетная проверка устраняет уже накопившиеся проблемы: мёртвые адреса, устаревшие контакты, опечатки. Real-time проверка не даёт этим проблемам возникнуть. Оба подхода работают в связке: сначала чистка базы, затем контроль качества каждого нового адреса.

Практический результат

Типичная email-база теряет 20-30% адресов ежегодно. Люди меняют работу, закрывают ящики, переезжают на другие сервисы. Адрес, который работал полгода назад, сегодня может возвращать bounce. Регулярная проверка существования ящиков - не разовая операция, а необходимая часть работы с email-базой.

После очистки через проверку существования ящиков bounce rate обычно снижается до 0.5-1%. Это значительно ниже порога в 2-3%, при котором провайдеры начинают снижать репутацию отправителя. Результат ощущается сразу: больше писем попадает во входящие, меньше уходит в спам, Open Rate растёт.