Слои проверки почты помогают интерпретировать синтаксис, домен и сигналы почтового ящика, чтобы вы могли ясно отчитываться о результатах, не обещая доставку во входящие.
Проверка почты снижает явные ошибки и количество низкокачественных регистраций, но не может гарантировать доставку во входящие. «Пас» обычно означает, что адрес корректно отформатирован, домен существует и домен, по-видимому, может принимать почту.
Используйте проверку, чтобы блокировать явные ошибки и замедлять злоумышленников при регистрации, а затем полагайтесь на подтверждение по почте для доступа к аккаунту или чувствительных действий. Валидация лучше работает как фильтр риска, а не как доказательство владения почтовым ящиком.
Синтаксическая проверка ловит такие ошибки форматирования, как отсутствие @, пробелы, двойные точки или недопустимые символы. Она быстрая и полезная, но не даёт ответа, существует ли домен или реальный почтовый ящик.
Слишком строгие регулярные выражения часто отвергают реальные, допустимые адреса, особенно редкие, но разрешённые форматы. Проверка по спецификации RFC обычно безопаснее, потому что соответствует тому, что принимают реальные почтовые системы.
Проверка домена смотрит, присутствует ли домен в DNS и настроен ли он на приём почты, обычно через MX-записи. Это предотвращает отправку писем на несуществующие или непочтовые домены.
MX-запись лишь показывает, что для домена настроены почтовые серверы, но не подтверждает, что конкретный почтовый ящик существует. Адрес всё ещё может быть опечаткой, несуществующим пользователем или почтовым ящиком, который позже отклонит сообщения.
Некоторые почтовые серверы блокируют сканирование, замедляют подключения или отвечают так, чтобы скрыть действительное состояние почтовых ящиков. Другие сначала принимают сообщение, а затем отклоняют — поэтому проверки на уровне почтового ящика часто дают вероятность, а не стопроцентное подтверждение.
Catch-all (приём любых адресов) — это настройка, при которой домен принимает почту для любого получателя, даже если ящик не мониторится. Обрабатывайте результаты для catch-all как неизвестно или риск, а не автоматически «валидный».
Одноразовые домены рассчитаны на короткое использование и часто применяются для создания большого числа низкокачественных аккаунтов. Блокировка или пометка известных одноразовых провайдеров при регистрации помогает сократить фейковые регистрации и будущие отказы.
Сопоставляйте сырые проверки с небольшим набором исходов: Valid, Invalid, Risky, Unknown. По умолчанию разрешайте Unknown с мерами предосторожности (подтверждение, лимиты на повторную отправку, повторные проверки), чтобы не блокировать реальных пользователей из-за временных DNS‑ошибок или проблем сервера.
Многие команды слышат «проверенный адрес» и предполагают одно: сообщение попадёт во входящие. Слово «проверка» звучит окончательно. На самом деле валидация — это набор сигналов, который снижает риск. Она может сказать, что адрес выглядит достаточно безопасным для приёма, но не может обещать доставку каждый раз.
Думайте о проверке как о контрольных пунктах. Каждый пункт ловит разный тип плохого ввода: явные опечатки, нерабочие домены или одноразовые адреса. Прохождение этих пунктов означает «это выглядит приемлемым для сохранения и попытки отправки», а не «этот человек обязательно получит письмо».
Даже если адрес прошёл все проверки, доставка всё ещё может не состояться или пользователь не увидит письмо. Частые причины: переполненный или отключённый почтовый ящик, почтовый сервер, который сначала принимает, а потом отклоняет, спам‑фильтры, или адрес, который со временем становится недействительным (люди меняют работу, компании закрывают домены).
Переобещание создаёт лишние проблемы. Продуктовые команды строят потоки, которые блокируют регистрации или считают «pass» как подтверждённого пользователя. Поддержка затем получает тикеты «я не получил письмо», даже если ваша система сделала всё возможное.
Лучше цель проще: уменьшить фейковые регистрации и очевидные отказы, при этом не закрывая дверь для реальных пользователей. Если адрес проходит синтаксис и проверку домена, но всё ещё выглядит рискованно, разрешите создание учётной записи и полагайтесь на подтверждение для чувствительных действий. Сервисы вроде Verimail (verimail.co) полезны здесь, потому что возвращают быстрые, структурированные сигналы, которые можно сопоставить с простыми решениями без притворства, что кто‑то может гарантировать доставку во входящие.
Проверка почты — это не одна единая проверка. Обычно её делят на три слоя, каждый отвечает на разный вопрос. Вместе они повышают уверенность, но никогда не дают 100% гарантии.
Синтаксическая проверка смотрит на формат. Есть ли локальная часть, знак @ и домен? Есть ли запрещённые символы, двойные точки или отсутствующие части?
Синтаксис быстрый и отлично ловит очевидные ошибки вроде gamil.com или [email protected]. Но он не скажет, существует ли домен или реальный почтовый ящик.
Проверка домена спрашивает, реален ли домен и настроен ли он для почты. Обычно это означает проверки DNS, включая существование домена и наличие MX-записей (или другой корректной почтовой настройки).
Этот слой избегает тупиков вроде [email protected]. Однако домен, который может принимать почту, не гарантирует существование конкретного ящика.
Сигналы уровня почтового ящика пытаются оценить доступность, не отправляя письмо. Некоторые провайдеры выдают подсказки. Другие блокируют проверки, чтобы предотвратить злоупотребления. Многие домены используют catch-all правила, когда любой адрес выглядит валидным.
Это значит, что доступность почтового ящика часто — это вероятность, а не доказательство. Практичный способ отчитываться — использовать небольшой набор исходов, на которые продукт может среагировать:
Синтаксическая проверка отвечает на один узкий вопрос: похоже ли это на адрес, который принимают почтовые системы? Она ловит отсутствие @, лишние пробелы, двойные точки, недопустимые символы и ошибки при копировании/вставке (например, завершающая пунктуация или невидимые пробелы).
Сложность в строгости. Многие приложения используют простой regex и отклоняют всё необычное, что блокирует реальных пользователей. RFC‑совместимая проверка синтаксиса более терпима и ближе к тому, что принимают реальные почтовые серверы, даже если адрес выглядит нетипично.
Прохождение синтаксиса всё ещё не подтверждает то, что большинство команд действительно хотят знать. Она не подтверждает существование домена, что домен может принимать почту, или что почтовый ящик реальный. Например, [email protected] может быть идеальным по синтаксису.
Кроме того, использование плюсов и точек часто приводит к ложным отклонениям. Многие крупные провайдеры относятся к ним как к норме, и пользователи полагаются на это для фильтрации:
[email protected] обычно валиден и не должен блокироваться[email protected] может быть валиден; значение точек зависит от провайдераЕсли вы храните нормализованную версию, сохраняйте и оригинальный адрес. Пользователи ожидают, что он совпадает с тем, что они ввели.
Проверка домена отвечает простому вопросу: похоже ли, что домен может принимать почту? Она ловит очевидные проблемы заранее, прежде чем вы потратите время на отправку писем, которые вернутся.
В целом доменные проверки смотрят DNS. Сначала вы подтверждаете, что домен существует и у него рабочий DNS. Затем вы проверяете маршрутизацию почты, обычно через MX‑записи (иногда с резервом на A‑запись). Если у домена есть валидные MX‑записи, это сильный знак, что домен настроен принимать почту где‑то.
Даже у хороших доменов иногда случаются ошибки проверки домена. Обычные причины: задержки распространения DNS для новых доменов, временные таймауты DNS или неправильно настроенные MX‑записи.
Из‑за этого единичный неудачный запрос не всегда доказывает, что адрес плохой. Многие команды трактуют это как «неизвестно» или «высокий риск» и повторяют попытку, особенно если пользователь в остальном выглядит реальным.
MX‑запись не подтверждает существование почтового ящика. Она лишь говорит: «у этого домена есть почтовые серверы». Адрес всё ещё может быть опечаткой (например, [email protected]), несуществующим пользователем или ящиком, который отклоняет новую почту.
Думайте о проверке домена как о подтверждении того, что в здании есть почтовая комната, а не о том, что конкретный человек там работает.
Проверки на уровне почтового ящика — это то, что люди обычно имеют в виду, спрашивая: «Можете ли вы сказать, существует ли этот конкретный ящик?» Они выходят за рамки синтаксиса и проверки домена и пытаются сделать вывод о реальности ящика, наблюдая за поведением принимающего почтового сервера.
Распространённые сигналы включают подсказки SMTP, обнаружение catch-all, адреса роль‑типа (support@ или info@) и сигналы риска от известной вредоносной инфраструктуры.
Ключевое ограничение в том, что многие почтовые серверы специально скрывают правду. Чтобы остановить спам и скрейпинг, провайдеры могут блокировать проверки, ограничивать скорость подключений или отвечать «принято» даже для фейковых получателей. Некоторые конфигурации сначала принимают, а потом отклоняют, или молча отбрасывают почту. Два валидатора могут протестировать один и тот же адрес и получить разные результаты — и оба могут быть обоснованными, исходя из того, что сервер решил раскрыть.
Catch-all домены особенно хитрые. Если домен принимает любой ящик, проверка может пометить [email protected] как доставляемый, даже если никто его не читает. Относитесь к catch-all как к «неизвестно» или «рискованно», а не как к «валидно».
Также помните: «доставляемо» — не то же самое, что «попадёт во входящие». Попадание в папку Inbox зависит от репутации отправителя, содержимого, аутентификации, истории пользователя и фильтров.
Одноразовые почтовые провайдеры отличаются от обычных бесплатных почтовых сервисов. Gmail или Outlook могут быть реальными и долговечными. Одноразовый адрес рассчитан на краткосрочное использование, часто чтобы обойти ограничения или скрыть личность.
Это особенно важно при регистрации. Если в вашем приложении есть бесплатный план, реферальные бонусы, триал или закрытый контент, одноразовые адреса часто используются для массового создания низкокачественных аккаунтов. Блокировка или пометка таких адресов защищает вашу базу, снижает количество фейковых регистраций и не даёт кампаниям портиться из‑за возвратов.
Спам‑ловушки — другая задача. Как правило, вы не можете надёжно определить спам‑ловушку только по строке адреса, и ошибочная блокировка может отсеять реальных пользователей. Безопаснее рассматривать подозрительные шаблоны как сигналы риска и обрабатывать их осторожно.
Практичный подход — комбинировать сигналы в исходы, например: известный одноразовый домен (высокий риск), домен без MX‑записей (вероятно недоставляемо), или реальный домен, где проверить доступность ящика нельзя (неизвестно).
Реальное время-й сопоставление с блоклистами помогает, потому что оно проверяет домены по часто обновляемым спискам известных одноразовых провайдеров. Verimail, например, сопоставляет тысячи одноразовых сервисов в своей конвейерной проверке, что облегчает пометку рискованных регистраций, не приравнивая каждый бесплатный провайдер к одноразовому.
Большинство команд собирают сигналы, а затем застревают на одном вопросе: что продукт должен делать дальше?
Начните с преобразования сырых проверок (синтаксис, домен/MX, обнаружение одноразовых, подсказки по ящику) в небольшой набор исходов, на которые ваше приложение может реагировать. Четырёх категорий обычно достаточно:
«Risky» — где обычно находятся основные выигрыши. Если адрес от известного одноразового провайдера или соответствует другим сигналам злоупотребления, вы можете замедлить злоумышленников, не закрывая доступ реальным людям, которые просто ошиблись.
Для «unknown» решите, когда повторять попытку. Вторая попытка часто устраняет временные сбои DNS и таймауты, снижая ложные отклонения.
Делайте UX дружелюбным. Если нужно блокировать, предложите быстрое решение и сохраните введённые данные формы.
SaaS‑компания запустила бесплатный триал и столкнулась с двумя проблемами: многие «новые пользователи» так и не активировались, а маркетинговые письма возвращались. Поддержка получала тикеты «я не получил письмо», часто из‑за опечаток в адресе.
Они добавили проверку при регистрации с одной целью: отсеять очевидный мусор, не отпугивая реальных людей.
Простая политика, которая хорошо работает:
Сообщение для пользователя важно. Избегайте обвинений. Держите тон нейтральным и полезным:
"Пожалуйста, ещё раз проверьте адрес электронной почты. Мы не смогли подтвердить, что этот адрес может получать сообщения. Если он введён верно, вы можете продолжить, но, возможно, не получите письмо подтверждения."
На бэкенде они логируют исход проверки и направляют пользователей по разным путям. Очевидные неверные и одноразовые адреса отклоняются. Все остальные могут продолжить, но подтверждение по почте требуется перед включением чувствительных функций.
Большинство людей слышат «проверено» и думают «доставлено». Именно здесь теряется доверие.
Используйте формулировки, соответствующие тому, что вы действительно знаете: «вероятно валиден», «домен, по‑всему, может принимать почту», «высокий риск», и «не удалось подтвердить», когда данных по почтовому ящику недостаточно.
Держите внутренние ярлыки отдельно от пользовательского интерфейса. Внутри вы можете хранить подробные сигналы (синтаксис, MX, одноразовый провайдер, скор риска). Внешне показывайте небольшой набор понятных исходов, которые пользователи поймут и на которые смогут отреагировать.
Ложные срабатывания случаются, когда реальный пользователь использует редкий провайдер, пересылку или сервер, который блокирует проверки. Ложные пропуски случаются, когда адрес проходит проверки, но позже возвращается из‑за переполненного ящика, временных ошибок сервера или правил провайдера.
Большинство проблем с проверкой почты не в инструменте, а в обещаниях вокруг результата.
Одна распространённая ошибка — считать, что прохождение синтаксиса означает доставляемость. Синтаксис лишь говорит, что адрес корректно сформирован. Он не подтверждает существование домена и тем более не подтверждает наличие реального ящика.
Ещё одна ошибка — чрезмерная блокировка. Некоторые команды блокируют все бесплатные почтовые домены, а затем удивляются падению регистраций. Бесплатные провайдеры используются реальными клиентами, партнёрами и соискателями. Если нужны более строгие правила, основывайте их на сигналах риска (одноразовые шаблоны, известные плохие источники, повторяющиеся злоупотребления), а не на «бесплатный против платного».
К временным ошибкам нужно относиться терпимо. DNS‑запросы и почтовые серверы иногда кратковременно падают. Если вы будете трактовать каждый таймаут как жёсткое «недействительно», вы откажете хорошим пользователям. Пометьте как «неизвестно» и повторите попытку, или разрешите регистрацию и перепроверьте перед отправкой важных писем.
Другие ошибки, которые тихо ухудшают результаты:
Если вы хотите, чтобы валидация улучшала качество регистраций, держите всё просто: проверяйте то, что можете доказать, помечайте то, в чём не уверены, и решайте, что делать для каждого исхода.
Базовые проверки, которые покрыть:
@ или недопустимых символовНапишите точные сообщения, которые будете показывать пользователям. "Мы не смогли подтвердить этот домен" часто безопаснее, чем "Этот email неверный", когда на самом деле у вас просто нет доказательств.
Перед запуском задайте чёткие правила: разрешать, предупреждать и блокировать, чтобы не обсуждать крайние случаи во время наплыва регистраций. После запуска отслеживайте показатели: процент возвратов (жёстких и мягких), уровень жалоб, конверсию, уровень мошенничества и тикеты в поддержку.
Если хотите реализовать это быстро, API для проверки почты может объединить RFC‑совместимые синтаксические проверки, проверку домена, MX‑lookup и сопоставление с блоклистом одноразовых провайдеров в одном вызове. Verimail предлагает это в виде единого API, чтобы вы могли сопоставлять результаты с шагами: разрешить, предупредить или заблокировать, не обещая доставку во входящие.