Валидация catch-all адресов: как безопасно принимать e-mail

Что означает catch-all (и зачем это нужно)

Catch-all (accept-all) домен настроен на приём почты для любого имени ящика, даже если конкретного почтового ящика нет. Если вы отправите письмо на [email protected], почтовый сервер всё равно ответит «OK» и направит его куда-то (часто в общий ящик, систему поддержки или на почту администратора).

Именно поэтому валидация при catch-all может путать. Многие валидаторы пытаются подтвердить ящик, проверяя, как отвечает принимающий сервер. При catch-all сервер часто принимает адрес в любом случае, поэтому вы не получаете ясного сигнала «этот ящик существует».

Catch-all распространён в бизнес-почте по практическим причинам. Это помогает компаниям не пропускать сообщения из-за опечаток, смен ролей или новых адресов команд. Также это упрощает приём входящей почты для отделов вроде продаж или поддержки без предварительного создания каждого ящика.

Большинство валидаторов в итоге выдают такие результаты:

• Invalid: адрес сломан (плохой синтаксис, домен не существует, нет маршрутизации почты). Скорее всего вернёт bounce.
• Deliverable: домен и почтовая настройка выглядят здоровыми, и сервер даёт сигналы, что ящик, вероятно, существует.
• Unknown: домен принимает почту широко (catch-all) или сервер блокирует проверки ящиков. Может работать, но уверенности нет.

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

Даже при catch-all базовые проверки важны. Сервисы вроде Verimail могут выполнять RFC-совместимую проверку синтаксиса, проверку домена и MX, а также сверку с блоклистами, чтобы отделить «явно плохие» от «неопределённых, но возможных». Когда вы видите «unknown», реальная работа — решить, как ваш продукт будет обрабатывать эту неопределённость.

Как catch-all искажает результаты валидации

Валидация почты обычно работает как воронка. На ранних шагах убираются очевидные ошибки. На поздних шагах пытаются ответить на самый сложный вопрос: существует ли конкретный ящик?

Типичный поток проверок включает:

• Синтаксис: правильно ли оформлен адрес?
• Домен: существует ли домен в DNS?
• MX-записи: настроен ли домен на приём почты?
• Сигналы на уровне ящика: подсказывает ли сервер, что ящик настоящий?

Catch-all ломает последний шаг. При accept-all настройке сервер может «принимать» как реальные адреса ([email protected]), так и выдуманные ([email protected]). В результате ответ становится не однозначным «да/нет», а оценкой уверенности.

Разные инструменты по-разному называют эту серую зону. Часто вы увидите метки вроде «accept-all», «unknown» или «risky». Они указывают на одну проблему: домен выглядит нормально, но конкретный ящик не подтверждается.

Ещё одна тонкость: почтовые серверы меняют поведение. Домeн может быть catch-all в этом месяце и строгим в следующем (и наоборот). Некоторые серверы также отвечают по-разному в зависимости от объёма и репутации. Относитесь к catch-all как к подвижному сигналу риска, а не к окончательному вердикту.

Почему это важно для регистрации и доставляемости

Catch-all домены создают особый вид неопределённости: домен выглядит реальным, но вы не уверены, что ящик существует. Эта неопределённость особенно критична там, где почта должна работать немедленно.

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

Ложные допуски дорогие. Вы платите за bounce’ы, тратите объём рассылок впустую и наполняете базу контактами, которые никогда не взаимодействуют. Со временем это может повредить репутации отправителя и отправить больше писем в спам. В худших случаях либеральные настройки могут скрывать спам-трэпы, что приведёт к более жёсткой фильтрации.

Ложные отклонения тоже вредят. Блокировка реальных пользователей только потому, что их компания использует catch-all, приводит к потерянным регистрациям и тикетам вроде «я не получил письмо» или «почему я не могу зарегистрироваться с рабочим адресом?».

Разные команды ощущают эффект по-разному:

• Продукт видит падение активации
• Поддержка обрабатывает жалобы по верификации и сбросу паролей
• Маркетинг видит меньшую окупаемость и более грязные сегменты
• Ответственные за доставляемость борются с bounce’ами и риском репутации

Catch-all лучше использовать как сигнал риска, а не как абсолютный проход или запрет.

Простой подход на основе риска для обработки catch-all

Результаты catch-all редко бывают чисто «да» или «нет». Практическая цель — решить, какой риск вы готовы принять в конкретном сценарии.

Простая модель: разбить регистрации на несколько корзин и применять согласованные действия для каждой:

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

Один и тот же catch-all домен может попадать в разные корзины в зависимости от того, что вы продаёте и как выглядит злоупотребление.

Для B2B catch-all часто встречается у небольших компаний и доменов под управлением IT. Часто можно принимать его чаще, потому что реальные клиенты используют такие адреса.

Для B2C catch-all реже встречается и чаще скрывает фейковые ящики. Если злоупотребления часты или маржа невелика, по умолчанию добавляйте трение, если прочие сигналы не чисты.

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

Пошагово: как обрабатывать catch-all в потоке валидации

Catch-all делает проверки на уровне ящика менее определёнными, но сам поток может остаться простым. Отделите явные допуски и явные отказы от серой зоны, затем применяйте для неё согласованную политику.

1) Начните с синтаксиса и здоровья домена

Сначала выполните RFC-совместимую проверку синтаксиса. Это ловит опечатки вроде отсутствия @, недопустимых символов или двойных точек, прежде чем тратить ресурсы на более глубокие проверки.

Затем проверьте, может ли домен принимать почту. На практике это означает подтверждение существования домена и наличия рабочей MX-записи (или другой корректной почтовой настройки). Если домен не может принимать почту — трейтируйте это как жёсткий отказ.

2) Раннее отфильтровывайте адреса с высоким риском

Прежде чем заботиться о catch-all, отсеивайте disposable-провайдеров и известные плохие шаблоны. Disposable-домены — частый источник одноразовых регистраций, bounce’ов и злоупотреблений.

Здесь помогает валидатор с API, который объединяет проверки в одном запросе. Verimail, например, фокусируется на синтаксисе, проверке домена, MX и реальном времени по блоклистам.

3) Обнаружьте catch-all и назначьте уровень риска

Если домен выглядит корректным, но сигналы на уровне ящика неубедительны, скорее всего это catch-all. Проще говоря, система говорит: «Этот домен принимает много адресов, поэтому я не могу подтвердить конкретный ящик».

Вместо того чтобы требовать да/нет, назначьте уровень риска на основе контекста:

• Низкий риск: бизнес-домен, обычные паттерны, нет признаков злоупотребления
• Средний риск: необычный local-part, совсем новый домен, слабые сигналы риска
• Высокий риск: повторные попытки, подозрительные паттерны, поведение похожее на disposable

4) Соответствуйте UX уровню риска

Решение должно отражать стоимость ошибки:

• Низкий риск: принять, затем следить за вовлечением (клик по подтверждению, первый вход)
• Средний риск: принять с трением (требование верификации, ограничение действий до подтверждения)
• Высокий риск: блокировать или требовать более сильных доказательств перед созданием аккаунта

Пример: B2B регистрация с [email protected] на catch-all домене. Вы принимаете регистрацию, но требуете клик по подтверждению перед включением функций с высоким риском. Это сохраняет плавность регистрации и одновременно защищает доставляемость и снижает bounce.

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

Catch-all делает проверки на уровне ящика шумными, потому что сервер может принимать почти любой адрес. Когда вы не можете получить явное «да», смотрите на соседние сигналы и трактуйте результат как скор риска.

Они по‑прежнему полезны даже при заблокированных проверках ящика:

• Обнаружение disposable или временных почт: сильный негативный сигнал.
• Опечатки и похожие домены: catch-all может скрыть ошибки вроде gmial.com или gmail.con. Отмечайте их до принятия.
• Показатели из блоклистов и риск спам-трэпов: если домен связан со злоупотреблениями или повторными bounce’ами, снижайте доверие.
• Ролевые почтовые ящики (info@, sales@, support@): обрабатывайте по политике. В B2B они могут быть легитимны, но часто это общие ящики с низкой вовлечённостью.
• Возраст домена и репутация: используйте как небольшой косвенный сигнал, а не как решающий фактор.

Практический пример: регистрация с [email protected], и домен — catch-all. Вы можете принять регистрацию, но требовать подтверждение почты перед включением функций с высокой ценностью. Если же тот же адрес — disposable или домен выглядит как опечатка, можно блокировать или просить другой адрес.

UX-стратегии для снижения риска

Catch-all обычно значит «неопределённо», а не «плохо». Самый безопасный подход — упростить форму и добавить несколько тихих защит.

Избегайте резких формулировок вроде «мы не принимаем этот адрес». Вы потеряете реальных пользователей из компаний, которые маршрутизируют почту через catch-all.

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

Рабочие защитные меры:

• Показывайте мягкую подсказку «проверьте ещё раз» только при повышенном риске.
• Требуйте подтверждение почты для регистраций с риском — одно нажатие или код.
• Ограничивайте частые регистрации с одного источника (IP, устройство, домен).
• Отсрочивайте чувствительные действия до верификации (ключи API, выгрузки, акции).
• Если пользователь так и не подтвердил почту, держите аккаунт ограниченным и отправьте одно–два напоминания, затем остановитесь.

Смысл — пропорциональное трение. Новому B2B-пользователю на catch-all может хватить простого подтверждения. Всплеск из 20 регистраций с одного catch-all за 5 минут должен вызвать более жёсткие меры.

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

Самая большая ловушка — считать catch-all однозначно «да» или «нет». Это не так. Чаще всего правильный ответ — «зависит от риска».

Ошибка №1: блокировать все catch-all домены. Это кажется безопасным, но отказывает реальным клиентам, особенно в B2B, где маленькие компании часто используют такую маршрутизацию.

Ошибка №2: считать catch-all полностью подтверждающим. Catch-all может скрыть опечатки и фейковые регистрации, потому что домен принимает почту для ящиков, которые никому не принадлежат.

Другие ошибки, ведущие к плохим решениям:

• Принимать окончательное решение по одному сигналу (например, «есть MX, значит всё в порядке»)
• Пропускать базовые проверки из‑за того, что домен catch-all (синтаксис, здоровье домена, disposable, блоклисты)
• Никогда не сверять категории валидации с реальными результатами (bounce’ы, клики подтверждения, возвраты денег, тикеты в поддержку)
• Использовать одно правило для всех типов сообщений (регистрация vs маркетинг vs сброс пароля)
• Не обновлять политику по мере адаптации злоумышленников

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

Пример сценария: B2B регистрация с catch-all доменом

Команда продаж запускает форму для самостоятельной регистрации на бесплатный пробный период. Новый лид вводит [email protected]. Валидатор подтверждает базу: чистый синтаксис, нет типичных опечаток, домен может принимать почту (MX есть). Домeн не disposable.

Затем домен помечается как catch-all. Почтовый сервер может принимать сообщения для почти любого имени ящика, даже если человек не реальный. Здесь «валидный» часто означает «неопределённый».

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

Подходящая последовательность действий:

• Создать аккаунт, но пометить его как неподтверждённый.
• Отправить письмо с подтверждением, прежде чем добавлять адрес в маркетинг.
• Ограничить чувствительные действия (приглашения, выгрузки, API-ключи, большой объём использования) до подтверждения.
• Если подтверждение не прошло или письмо отскочило, приостановить аккаунт и попросить обновить адрес.

В первую неделю наблюдайте за bounce’ами, жалобами на спам и базовыми показателями вовлечения. Если видите повторяющиеся bounce’ы или шаблоны по похожим регистрациям, ужесточите правила для catch-all доменов.

Быстрый чек‑лист для работы с catch-all

Catch-all добавляет неопределённость. Цель не в совершенстве — а в повторяемой политике, которая снижает плохие регистрации, не блокируя реальных людей.

• Примите одну политику catch-all для каждой формы: принимать, принимать с подтверждением или блокировать.
• Рассматривайте catch-all как флаг риска, а не как пропуск. Сочетайте его с другими сигналами.
• Требуйте верификацию для регистраций со средним и высоким риском.
• Блокируйте явно плохое: disposable-провайдеры, неработающие домены, неправильный синтаксис.
• Сохраняйте результаты по категориям и пересматривайте их ежемесячно.

Чтобы это было измеримо, храните категорию валидации, которую вы увидели при регистрации, а не только «разрешено/заблокировано». Если вы используете валидатор вроде Verimail, сохранение ответа рядом с записью пользователя упростит аудит позже.

Сначала следите за:

• Bounce rate и уровнем жалоб для catch-all регистраций
• Процентом завершённых подтверждений по почте (сколько реальных пользователей вы теряете)
• Уровнем мошенничества или злоупотреблений, связанным с catch-all регистрациями

Если catch-all адреса ведут себя как обычные в вашей аналитике — ослабляйте ограничения. Если они приводят к bounce’ам или злоупотреблениям — ужесточайте, требуя подтверждения или ручного рассмотрения для рискованных случаев.

Следующие шаги: сделайте из неопределённости catch-all понятную политику

Результаты catch-all полезны только тогда, когда по ним принимаются последовательные решения. Замерьте базовую картину в течение недели: пометьте регистрации как catch-all и non-catch-all и сравните результаты (процент подтверждений, вовлечённость за первую неделю, возвраты и bounce’ы). Вы быстро увидите, являются ли catch-all домены нормальной бизнес‑почтой или источником низкокачественного трафика.

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

Простая шаблонная политика:

• Регистрация: разрешать catch-all, но требовать подтверждение почты перед ключевыми действиями.
• Приглашения: разрешать только если приглашающий верифицирован и домен не disposable.
• Платёж и важные действия: требовать подтверждение и более строгие проверки риска.
• Сбросы пароля: всегда отправлять подтверждение и не полагаться только на catch-all.

Если вы добавляете трение, рассматривайте это как эксперимент. Меняйте по одному небольшому параметру и отслеживайте качество не только по конверсии форм, но и по downstream‑показателям.

Если нужен единый API‑запрос, покрывающий базовые проверки (синтаксис, проверка домена, MX и сигналы disposable/блоклистов), Verimail (verimail.co) — один из вариантов. Ключевой момент не в инструменте, а в том, что вы делаете с корзиной «unknown»: определите её, измерьте её и применяйте политику последовательно.