Узнайте о валидации catch-all адресов: что такое catch-all домены, почему результаты могут быть неясны и как безопасно принимать почту с помощью правил на основе риска.
Catch-all домен настроен так, чтобы принимать почту на любое имя ящика в этом домене, даже если конкретного почтового ящика не существует. Это значит, что сервер может ответить «принято» как для реальных, так и для выдуманных адресов, поэтому на уровне проверки конкретного почтового ящика получить уверенный ответ трудно.
Многие валидаторы пытаются подтвердить существование конкретного почтового ящика, глядя на ответ принимающего сервера при проверке на уровне ящика. Catch-all домены часто отвечают положительно для почти любых адресов, поэтому результат становится неопределённым, а не однозначным «да» или «нет».
Большинство команд трактуют это как метку риска «unknown» или «accept-all». Домен может быть реальным и принимать почту, но вы не можете уверенно подтвердить, что конкретный ящик существует, поэтому решение принимают на основе уровня риска, а не принудительного пропуска/блока.
Нет. Валидация уменьшает очевидные причины сбоев (неправильный синтаксис, отсутствующий домен, отсутствие MX) и помечает риски, но не может гарантировать доставку: серверы меняют поведение, могут блокировать проверки или принимать почту, не подтверждая существование ящика.
Используйте модель на основе риска: принимайте регистрацию, но требуйте подтверждение по электронной почте перед включением действий с высоким риском. Так вы пропускаете реальных пользователей и одновременно защищаетесь от опечаток, фейковых регистраций и недоступных ящиков, скрытых catch-all поведением.
Да. Если ошибка обходится дорого, добавьте дополнительные шаги. Сброс пароля, приглашения в команду, чеки и другие чувствительные действия должны требовать подтверждения, потому что catch-all домен может перенаправить почту непредсказуемо при опечатке.
Всегда важно: сначала проверка синтаксиса в соответствии с RFC, затем убедиться, что домен существует и имеет рабочие MX-записи. Далее отфильтруйте disposable-домены и известные плохие шаблоны; инструменты вроде Verimail комбинируют синтаксис, проверку домена, MX и блоклисты, чтобы отделить явно плохие адреса от неопределённых.
Обычно так: низкий риск (обычный бизнес-домен, нормальные паттерны) получает плавный поток с требованием подтверждения; средний риск — «принимать с трением» (верификация, ограничения); высокий риск (всплески регистраций, повторные попытки, подозрительные паттерны) — блокировать или отправлять на ручную проверку.
Это частая ошибка: блокировать все catch-all домены — такое решение отсекает реальных бизнес-пользователей. Безопаснее принимать и проверять, блокируя только при явных признаках злоупотребления: disposable-домены, некорректная настройка домена или повторяющиеся подозрительные попытки.
Сохраняйте категорию валидации при регистрации (deliverable, invalid, unknown/catch-all) и сравнивайте такие метрики, как процент подтверждений, bounce rate и уровень злоупотреблений. Если catch-all регистрации похожи на обычных пользователей — ослабляйте фильтр; если приводят к ошибкам и мошенничеству — ужесточайте требования и верификацию.
Catch-all (accept-all) домен настроен на приём почты для любого имени ящика, даже если конкретного почтового ящика нет. Если вы отправите письмо на [email protected], почтовый сервер всё равно ответит «OK» и направит его куда-то (часто в общий ящик, систему поддержки или на почту администратора).
Именно поэтому валидация при catch-all может путать. Многие валидаторы пытаются подтвердить ящик, проверяя, как отвечает принимающий сервер. При catch-all сервер часто принимает адрес в любом случае, поэтому вы не получаете ясного сигнала «этот ящик существует».
Catch-all распространён в бизнес-почте по практическим причинам. Это помогает компаниям не пропускать сообщения из-за опечаток, смен ролей или новых адресов команд. Также это упрощает приём входящей почты для отделов вроде продаж или поддержки без предварительного создания каждого ящика.
Большинство валидаторов в итоге выдают такие результаты:
Ожидание внутри команды должно быть таким: валидация снижает риск. Она не доказывает доставку на 100%. Поведение почтовых серверов меняется, случаются сбои, и некоторые провайдеры намеренно скрывают детали ящиков.
Даже при catch-all базовые проверки важны. Сервисы вроде Verimail могут выполнять RFC-совместимую проверку синтаксиса, проверку домена и MX, а также сверку с блоклистами, чтобы отделить «явно плохие» от «неопределённых, но возможных». Когда вы видите «unknown», реальная работа — решить, как ваш продукт будет обрабатывать эту неопределённость.
Валидация почты обычно работает как воронка. На ранних шагах убираются очевидные ошибки. На поздних шагах пытаются ответить на самый сложный вопрос: существует ли конкретный ящик?
Типичный поток проверок включает:
Catch-all ломает последний шаг. При accept-all настройке сервер может «принимать» как реальные адреса ([email protected]), так и выдуманные ([email protected]). В результате ответ становится не однозначным «да/нет», а оценкой уверенности.
Разные инструменты по-разному называют эту серую зону. Часто вы увидите метки вроде «accept-all», «unknown» или «risky». Они указывают на одну проблему: домен выглядит нормально, но конкретный ящик не подтверждается.
Ещё одна тонкость: почтовые серверы меняют поведение. Домeн может быть catch-all в этом месяце и строгим в следующем (и наоборот). Некоторые серверы также отвечают по-разному в зависимости от объёма и репутации. Относитесь к catch-all как к подвижному сигналу риска, а не к окончательному вердикту.
Catch-all домены создают особый вид неопределённости: домен выглядит реальным, но вы не уверены, что ящик существует. Эта неопределённость особенно критична там, где почта должна работать немедленно.
Вы ощутите это в таких сценариях, как подтверждение регистрации, сброс пароля, приглашения в команду, а также чеки и уведомления о заказах. Если даже небольшая доля таких писем не доходит до пользователей, люди застревают и повторяют попытки. Продукт начинает казаться ненадёжным, даже если всё остальное работает.
Ложные допуски дорогие. Вы платите за bounce’ы, тратите объём рассылок впустую и наполняете базу контактами, которые никогда не взаимодействуют. Со временем это может повредить репутации отправителя и отправить больше писем в спам. В худших случаях либеральные настройки могут скрывать спам-трэпы, что приведёт к более жёсткой фильтрации.
Ложные отклонения тоже вредят. Блокировка реальных пользователей только потому, что их компания использует catch-all, приводит к потерянным регистрациям и тикетам вроде «я не получил письмо» или «почему я не могу зарегистрироваться с рабочим адресом?».
Разные команды ощущают эффект по-разному:
Catch-all лучше использовать как сигнал риска, а не как абсолютный проход или запрет.
Результаты catch-all редко бывают чисто «да» или «нет». Практическая цель — решить, какой риск вы готовы принять в конкретном сценарии.
Простая модель: разбить регистрации на несколько корзин и применять согласованные действия для каждой:
Один и тот же catch-all домен может попадать в разные корзины в зависимости от того, что вы продаёте и как выглядит злоупотребление.
Для B2B catch-all часто встречается у небольших компаний и доменов под управлением IT. Часто можно принимать его чаще, потому что реальные клиенты используют такие адреса.
Для B2C catch-all реже встречается и чаще скрывает фейковые ящики. Если злоупотребления часты или маржа невелика, по умолчанию добавляйте трение, если прочие сигналы не чисты.
Помогает прогрессирующее доверие. Сначала строго относитесь к неопределённым адресам, затем ослабляйте требования, когда пользователь доказывает доступность почты (клик по подтверждению, завершение онбординга или успешное получение транзакционного письма).
Catch-all делает проверки на уровне ящика менее определёнными, но сам поток может остаться простым. Отделите явные допуски и явные отказы от серой зоны, затем применяйте для неё согласованную политику.
Сначала выполните RFC-совместимую проверку синтаксиса. Это ловит опечатки вроде отсутствия @, недопустимых символов или двойных точек, прежде чем тратить ресурсы на более глубокие проверки.
Затем проверьте, может ли домен принимать почту. На практике это означает подтверждение существования домена и наличия рабочей MX-записи (или другой корректной почтовой настройки). Если домен не может принимать почту — трейтируйте это как жёсткий отказ.
Прежде чем заботиться о catch-all, отсеивайте disposable-провайдеров и известные плохие шаблоны. Disposable-домены — частый источник одноразовых регистраций, bounce’ов и злоупотреблений.
Здесь помогает валидатор с API, который объединяет проверки в одном запросе. Verimail, например, фокусируется на синтаксисе, проверке домена, MX и реальном времени по блоклистам.
Если домен выглядит корректным, но сигналы на уровне ящика неубедительны, скорее всего это catch-all. Проще говоря, система говорит: «Этот домен принимает много адресов, поэтому я не могу подтвердить конкретный ящик».
Вместо того чтобы требовать да/нет, назначьте уровень риска на основе контекста:
Решение должно отражать стоимость ошибки:
Пример: B2B регистрация с [email protected] на catch-all домене. Вы принимаете регистрацию, но требуете клик по подтверждению перед включением функций с высоким риском. Это сохраняет плавность регистрации и одновременно защищает доставляемость и снижает bounce.
Catch-all делает проверки на уровне ящика шумными, потому что сервер может принимать почти любой адрес. Когда вы не можете получить явное «да», смотрите на соседние сигналы и трактуйте результат как скор риска.
Они по‑прежнему полезны даже при заблокированных проверках ящика:
gmial.com или gmail.con. Отмечайте их до принятия.info@, sales@, support@): обрабатывайте по политике. В B2B они могут быть легитимны, но часто это общие ящики с низкой вовлечённостью.Практический пример: регистрация с [email protected], и домен — catch-all. Вы можете принять регистрацию, но требовать подтверждение почты перед включением функций с высокой ценностью. Если же тот же адрес — disposable или домен выглядит как опечатка, можно блокировать или просить другой адрес.
Catch-all обычно значит «неопределённо», а не «плохо». Самый безопасный подход — упростить форму и добавить несколько тихих защит.
Избегайте резких формулировок вроде «мы не принимаем этот адрес». Вы потеряете реальных пользователей из компаний, которые маршрутизируют почту через catch-all.
Лучше мягкая подсказка и понятный следующий шаг: «Проверьте адрес на опечатки. Мы отправим письмо с подтверждением, чтобы завершить настройку.»
Рабочие защитные меры:
Смысл — пропорциональное трение. Новому B2B-пользователю на catch-all может хватить простого подтверждения. Всплеск из 20 регистраций с одного catch-all за 5 минут должен вызвать более жёсткие меры.
Самая большая ловушка — считать catch-all однозначно «да» или «нет». Это не так. Чаще всего правильный ответ — «зависит от риска».
Ошибка №1: блокировать все catch-all домены. Это кажется безопасным, но отказывает реальным клиентам, особенно в B2B, где маленькие компании часто используют такую маршрутизацию.
Ошибка №2: считать catch-all полностью подтверждающим. Catch-all может скрыть опечатки и фейковые регистрации, потому что домен принимает почту для ящиков, которые никому не принадлежат.
Другие ошибки, ведущие к плохим решениям:
Пример: вы пропускаете catch-all адрес при регистрации без последующих шагов, а затем отправляете письмо для сброса пароля. Если пользователь допустил опечатку на catch-all домене, сброс уйдёт в ящик, которого вы не ожидали.
Команда продаж запускает форму для самостоятельной регистрации на бесплатный пробный период. Новый лид вводит [email protected]. Валидатор подтверждает базу: чистый синтаксис, нет типичных опечаток, домен может принимать почту (MX есть). Домeн не disposable.
Затем домен помечается как catch-all. Почтовый сервер может принимать сообщения для почти любого имени ящика, даже если человек не реальный. Здесь «валидный» часто означает «неопределённый».
Вместо блокировки вы разрешаете создание аккаунта, но ограничиваете риск. Пользователь может изучать продукт, но всё, что стоит денег или может быть использовано во вред, остаётся заблокировано до подтверждения почты.
Подходящая последовательность действий:
В первую неделю наблюдайте за bounce’ами, жалобами на спам и базовыми показателями вовлечения. Если видите повторяющиеся bounce’ы или шаблоны по похожим регистрациям, ужесточите правила для catch-all доменов.
Catch-all добавляет неопределённость. Цель не в совершенстве — а в повторяемой политике, которая снижает плохие регистрации, не блокируя реальных людей.
Чтобы это было измеримо, храните категорию валидации, которую вы увидели при регистрации, а не только «разрешено/заблокировано». Если вы используете валидатор вроде Verimail, сохранение ответа рядом с записью пользователя упростит аудит позже.
Сначала следите за:
Если catch-all адреса ведут себя как обычные в вашей аналитике — ослабляйте ограничения. Если они приводят к bounce’ам или злоупотреблениям — ужесточайте, требуя подтверждения или ручного рассмотрения для рискованных случаев.
Результаты catch-all полезны только тогда, когда по ним принимаются последовательные решения. Замерьте базовую картину в течение недели: пометьте регистрации как catch-all и non-catch-all и сравните результаты (процент подтверждений, вовлечённость за первую неделю, возвраты и bounce’ы). Вы быстро увидите, являются ли catch-all домены нормальной бизнес‑почтой или источником низкокачественного трафика.
Затем пропишите правила для каждой стадии воронки. Подписка на рассылку может терпеть больше неопределённости, чем создание аккаунта. Платёжные действия должны быть самыми строгими.
Простая шаблонная политика:
Если вы добавляете трение, рассматривайте это как эксперимент. Меняйте по одному небольшому параметру и отслеживайте качество не только по конверсии форм, но и по downstream‑показателям.
Если нужен единый API‑запрос, покрывающий базовые проверки (синтаксис, проверка домена, MX и сигналы disposable/блоклистов), Verimail (verimail.co) — один из вариантов. Ключевой момент не в инструменте, а в том, что вы делаете с корзиной «unknown»: определите её, измерьте её и применяйте политику последовательно.