Слои проверки электронной почты: синтаксис, домен и сигналы почтового ящика

Что проверка почты может и не может гарантировать

Многие команды слышат «проверенный адрес» и предполагают одно: сообщение попадёт во входящие. Слово «проверка» звучит окончательно. На самом деле валидация — это набор сигналов, который снижает риск. Она может сказать, что адрес выглядит достаточно безопасным для приёма, но не может обещать доставку каждый раз.

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

Даже если адрес прошёл все проверки, доставка всё ещё может не состояться или пользователь не увидит письмо. Частые причины: переполненный или отключённый почтовый ящик, почтовый сервер, который сначала принимает, а потом отклоняет, спам‑фильтры, или адрес, который со временем становится недействительным (люди меняют работу, компании закрывают домены).

Переобещание создаёт лишние проблемы. Продуктовые команды строят потоки, которые блокируют регистрации или считают «pass» как подтверждённого пользователя. Поддержка затем получает тикеты «я не получил письмо», даже если ваша система сделала всё возможное.

Лучше цель проще: уменьшить фейковые регистрации и очевидные отказы, при этом не закрывая дверь для реальных пользователей. Если адрес проходит синтаксис и проверку домена, но всё ещё выглядит рискованно, разрешите создание учётной записи и полагайтесь на подтверждение для чувствительных действий. Сервисы вроде Verimail (verimail.co) полезны здесь, потому что возвращают быстрые, структурированные сигналы, которые можно сопоставить с простыми решениями без притворства, что кто‑то может гарантировать доставку во входящие.

Три основных слоя валидации

Проверка почты — это не одна единая проверка. Обычно её делят на три слоя, каждый отвечает на разный вопрос. Вместе они повышают уверенность, но никогда не дают 100% гарантии.

1) Синтаксис: «Похоже ли это на реальный адрес?»

Синтаксическая проверка смотрит на формат. Есть ли локальная часть, знак @ и домен? Есть ли запрещённые символы, двойные точки или отсутствующие части?

Синтаксис быстрый и отлично ловит очевидные ошибки вроде gamil.com или [email protected]. Но он не скажет, существует ли домен или реальный почтовый ящик.

2) Домен: «Может ли этот домен принимать почту?»

Проверка домена спрашивает, реален ли домен и настроен ли он для почты. Обычно это означает проверки DNS, включая существование домена и наличие MX-записей (или другой корректной почтовой настройки).

Этот слой избегает тупиков вроде [email protected]. Однако домен, который может принимать почту, не гарантирует существование конкретного ящика.

3) Сигналы на уровне почтового ящика: «Вероятно ли доступен этот ящик?»

Сигналы уровня почтового ящика пытаются оценить доступность, не отправляя письмо. Некоторые провайдеры выдают подсказки. Другие блокируют проверки, чтобы предотвратить злоупотребления. Многие домены используют catch-all правила, когда любой адрес выглядит валидным.

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

• Pass: выглядит валидным по проверкам
• Fail: явно неверный (плохой синтаксис, домен не способен принимать почту)
• Risky: признаки низкого качества (например, шаблоны одноразовых адресов)
• Unknown: недостаточно сигналов, чтобы быть уверенным

Синтаксическая валидация: полезна, быстра и ограничена

Синтаксическая проверка отвечает на один узкий вопрос: похоже ли это на адрес, который принимают почтовые системы? Она ловит отсутствие @, лишние пробелы, двойные точки, недопустимые символы и ошибки при копировании/вставке (например, завершающая пунктуация или невидимые пробелы).

Сложность в строгости. Многие приложения используют простой regex и отклоняют всё необычное, что блокирует реальных пользователей. RFC‑совместимая проверка синтаксиса более терпима и ближе к тому, что принимают реальные почтовые серверы, даже если адрес выглядит нетипично.

Прохождение синтаксиса всё ещё не подтверждает то, что большинство команд действительно хотят знать. Она не подтверждает существование домена, что домен может принимать почту, или что почтовый ящик реальный. Например, [email protected] может быть идеальным по синтаксису.

Кроме того, использование плюсов и точек часто приводит к ложным отклонениям. Многие крупные провайдеры относятся к ним как к норме, и пользователи полагаются на это для фильтрации:

• [email protected] обычно валиден и не должен блокироваться
• [email protected] может быть валиден; значение точек зависит от провайдера

Если вы храните нормализованную версию, сохраняйте и оригинальный адрес. Пользователи ожидают, что он совпадает с тем, что они ввели.

Проверка домена: домен существует и способен принимать почту

Проверка домена отвечает простому вопросу: похоже ли, что домен может принимать почту? Она ловит очевидные проблемы заранее, прежде чем вы потратите время на отправку писем, которые вернутся.

В целом доменные проверки смотрят DNS. Сначала вы подтверждаете, что домен существует и у него рабочий DNS. Затем вы проверяете маршрутизацию почты, обычно через MX‑записи (иногда с резервом на A‑запись). Если у домена есть валидные MX‑записи, это сильный знак, что домен настроен принимать почту где‑то.

Распространённые крайние случаи

Даже у хороших доменов иногда случаются ошибки проверки домена. Обычные причины: задержки распространения DNS для новых доменов, временные таймауты DNS или неправильно настроенные MX‑записи.

Из‑за этого единичный неудачный запрос не всегда доказывает, что адрес плохой. Многие команды трактуют это как «неизвестно» или «высокий риск» и повторяют попытку, особенно если пользователь в остальном выглядит реальным.

Что не доказывает валидная MX‑запись

MX‑запись не подтверждает существование почтового ящика. Она лишь говорит: «у этого домена есть почтовые серверы». Адрес всё ещё может быть опечаткой (например, [email protected]), несуществующим пользователем или ящиком, который отклоняет новую почту.

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

Сигналы уровня почтового ящика: самая трудная часть

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

Распространённые сигналы включают подсказки SMTP, обнаружение catch-all, адреса роль‑типа (support@ или info@) и сигналы риска от известной вредоносной инфраструктуры.

Ключевое ограничение в том, что многие почтовые серверы специально скрывают правду. Чтобы остановить спам и скрейпинг, провайдеры могут блокировать проверки, ограничивать скорость подключений или отвечать «принято» даже для фейковых получателей. Некоторые конфигурации сначала принимают, а потом отклоняют, или молча отбрасывают почту. Два валидатора могут протестировать один и тот же адрес и получить разные результаты — и оба могут быть обоснованными, исходя из того, что сервер решил раскрыть.

Catch-all домены особенно хитрые. Если домен принимает любой ящик, проверка может пометить [email protected] как доставляемый, даже если никто его не читает. Относитесь к catch-all как к «неизвестно» или «рискованно», а не как к «валидно».

Также помните: «доставляемо» — не то же самое, что «попадёт во входящие». Попадание в папку Inbox зависит от репутации отправителя, содержимого, аутентификации, истории пользователя и фильтров.

Одноразовые адреса, спам‑ловушки и сигналы риска

Одноразовые почтовые провайдеры отличаются от обычных бесплатных почтовых сервисов. Gmail или Outlook могут быть реальными и долговечными. Одноразовый адрес рассчитан на краткосрочное использование, часто чтобы обойти ограничения или скрыть личность.

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

Спам‑ловушки — другая задача. Как правило, вы не можете надёжно определить спам‑ловушку только по строке адреса, и ошибочная блокировка может отсеять реальных пользователей. Безопаснее рассматривать подозрительные шаблоны как сигналы риска и обрабатывать их осторожно.

Практичный подход — комбинировать сигналы в исходы, например: известный одноразовый домен (высокий риск), домен без MX‑записей (вероятно недоставляемо), или реальный домен, где проверить доступность ящика нельзя (неизвестно).

Реальное время-й сопоставление с блоклистами помогает, потому что оно проверяет домены по часто обновляемым спискам известных одноразовых провайдеров. Verimail, например, сопоставляет тысячи одноразовых сервисов в своей конвейерной проверке, что облегчает пометку рискованных регистраций, не приравнивая каждый бесплатный провайдер к одноразовому.

Как переводить сигналы в понятные исходы

Большинство команд собирают сигналы, а затем застревают на одном вопросе: что продукт должен делать дальше?

Начните с преобразования сырых проверок (синтаксис, домен/MX, обнаружение одноразовых, подсказки по ящику) в небольшой набор исходов, на которые ваше приложение может реагировать. Четырёх категорий обычно достаточно:

• Valid: разрешить регистрацию. Всё равно требуйте подтверждения адреса для доступа или чувствительных действий.
• Invalid: блокировать с нейтральным, понятным сообщением ("Этот адрес электронной почты выглядит неверно. Пожалуйста, проверьте опечатки.").
• Risky: разрешить, но добавить трение (мягкое предупреждение, требовать подтверждение, ограниченные привилегии до подтверждения).
• Unknown: разрешить с мерами предосторожности, потому что сети и DNS могут временно падать.

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

Для «unknown» решите, когда повторять попытку. Вторая попытка часто устраняет временные сбои DNS и таймауты, снижая ложные отклонения.

Делайте UX дружелюбным. Если нужно блокировать, предложите быстрое решение и сохраните введённые данные формы.

Пример: улучшение качества регистраций без блокировки реальных пользователей

SaaS‑компания запустила бесплатный триал и столкнулась с двумя проблемами: многие «новые пользователи» так и не активировались, а маркетинговые письма возвращались. Поддержка получала тикеты «я не получил письмо», часто из‑за опечаток в адресе.

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

Простая политика, которая хорошо работает:

• Блокировать: явные синтаксические ошибки, несуществующие домены и домены без валидных MX-записей
• Блокировать: известные одноразовые провайдеры (когда триалы злоупотребляются)
• Разрешать, но предупреждать: случаи, когда домен реальный, но доступность ящика не подтверждается
• Разрешать, но требовать верификацию: адреса с высоким риском, с лимитами на повторную отправку

Сообщение для пользователя важно. Избегайте обвинений. Держите тон нейтральным и полезным:

"Пожалуйста, ещё раз проверьте адрес электронной почты. Мы не смогли подтвердить, что этот адрес может получать сообщения. Если он введён верно, вы можете продолжить, но, возможно, не получите письмо подтверждения."

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

Как сообщать результаты, не переобещая

Большинство людей слышат «проверено» и думают «доставлено». Именно здесь теряется доверие.

Используйте формулировки, соответствующие тому, что вы действительно знаете: «вероятно валиден», «домен, по‑всему, может принимать почту», «высокий риск», и «не удалось подтвердить», когда данных по почтовому ящику недостаточно.

Держите внутренние ярлыки отдельно от пользовательского интерфейса. Внутри вы можете хранить подробные сигналы (синтаксис, MX, одноразовый провайдер, скор риска). Внешне показывайте небольшой набор понятных исходов, которые пользователи поймут и на которые смогут отреагировать.

Простые фразы для повторного использования

• UI продукта: "Выглядит валидным. Домен может принимать почту, но мы не можем подтвердить приём конкретного ящика."
• UI продукта: "Высокий риск. Этот адрес может быть одноразовым или недоступным. Пожалуйста, используйте другой адрес."
• Ответ поддержки: "Мы проверяем формат и почтовую настройку домена. Некоторые провайдеры не позволяют реальные проверки ящиков в реальном времени, поэтому доставка не гарантируется."
• Маркетинг: "Снижает возвраты и фейковые регистрации, фильтруя неверные, одноразовые и рискованные адреса."
• Примечание для инженеров: "Относитесь к результатам как к сигналам, а не обещанию. Используйте их, чтобы управлять трением (предупреждать, блокировать или разрешать)."

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

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

Большинство проблем с проверкой почты не в инструменте, а в обещаниях вокруг результата.

Одна распространённая ошибка — считать, что прохождение синтаксиса означает доставляемость. Синтаксис лишь говорит, что адрес корректно сформирован. Он не подтверждает существование домена и тем более не подтверждает наличие реального ящика.

Ещё одна ошибка — чрезмерная блокировка. Некоторые команды блокируют все бесплатные почтовые домены, а затем удивляются падению регистраций. Бесплатные провайдеры используются реальными клиентами, партнёрами и соискателями. Если нужны более строгие правила, основывайте их на сигналах риска (одноразовые шаблоны, известные плохие источники, повторяющиеся злоупотребления), а не на «бесплатный против платного».

К временным ошибкам нужно относиться терпимо. DNS‑запросы и почтовые серверы иногда кратковременно падают. Если вы будете трактовать каждый таймаут как жёсткое «недействительно», вы откажете хорошим пользователям. Пометьте как «неизвестно» и повторите попытку, или разрешите регистрацию и перепроверьте перед отправкой важных писем.

Другие ошибки, которые тихо ухудшают результаты:

• Игнорирование catch-all доменов, которые принимают любые адреса
• Трактовка role‑адресов (support@, info@) как всегда плохих вместо мягкого предупреждения
• Показ пугающего текста ("Ваш адрес мошеннический"), из‑за которого честные пользователи бросают форму
• Путаница между «риск» и «неверный», что сбивает с толку команду и пользователей

Быстрый чек‑лист и дальнейшие шаги

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

Базовые проверки, которые покрыть:

• Синтаксис: корректный (по RFC), без пробелов, отсутствия @ или недопустимых символов
• Домен и MX: домен существует и настроен на приём почты
• Сигналы по ящику: используйте подсказки, когда они доступны, но не считайте их доказательством
• Сигналы риска: одноразовые домены и другие шаблоны, связанные с низкокачественными регистрациями

Напишите точные сообщения, которые будете показывать пользователям. "Мы не смогли подтвердить этот домен" часто безопаснее, чем "Этот email неверный", когда на самом деле у вас просто нет доказательств.

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

Если хотите реализовать это быстро, API для проверки почты может объединить RFC‑совместимые синтаксические проверки, проверку домена, MX‑lookup и сопоставление с блоклистом одноразовых провайдеров в одном вызове. Verimail предлагает это в виде единого API, чтобы вы могли сопоставлять результаты с шагами: разрешить, предупредить или заблокировать, не обещая доставку во входящие.