Catch-all (accept-all) домен: что это и чем он мешает проверке email

Марк АвриловОпубликовано 21 февраля 2026обновлено 17 сентября 2026

Catch-all (accept-all) домен — это домен, почтовый сервер которого принимает письма на любой адрес, в том числе на ящики, которых не существует.

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

Что происходит в SMTP-сессии

Отправитель называет получателя командой RCPT TO. Обычный сервер сверяется со списком ящиков: на существующий адрес отвечает 250, на несуществующий 550 (User unknown). Сервер с catch-all отвечает 250 на всё подряд, будь то asdfgh@domain.com или test123@domain.com. Дальше письмо падает в общий ящик, молча удаляется или через несколько часов возвращается отложенным отказом.

Включается это в настройках почтового сервера. В Postfix хватает строки вида @example.com inbox@example.com в таблице виртуальных алиасов: у такой записи самый низкий приоритет, и она ловит все адреса домена, которых нет в таблице выше. В Google Workspace то же делает правило маршрутизации для нераспознанных адресов.

Зачем домены так настраивают

Чаще всего из страха потерять письмо. Клиент пишет на slaes@company.com вместо sales@, или в адресной книге у него i.petrov@ вместо ivan.petrov@. Без catch-all письмо вернётся отправителю, с ним попадёт в общий ящик, и его кто-нибудь разберёт.

Вторая причина в простоте. В маленькой фирме всю почту сводят в один ящик, а под каждый канал (promo@, webinar@, partner@) не заводят отдельных адресов, их просто придумывают на ходу.

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

Ложноположительный ответ при проверке

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

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

Как валидатор распознаёт catch-all

Существование конкретного ящика на таком домене подтвердить нельзя, а саму настройку определить можно. Валидатор спрашивает сервер про заведомо случайный адрес вроде a7f3k9x@домен. Принят? Значит, домен принимает всё, и каждый адрес на нём получает отметку catch-all.

Бывают и промежуточные случаи. Одни серверы соглашаются на RCPT TO, а отказывают уже после передачи письма. Другие на первый запрос отвечают временной ошибкой 451 (грейлистинг). Такой результат честнее записать в неопределённый статус и перепроверить позже, чем гадать.

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

Рассылка по адресам на catch-all доменах

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

Рабочая схема такая. Адреса на catch-all доменах выносятся в отдельный сегмент, письма туда уходят небольшими партиями, а отказы считаются по факту, отдельно от остальной базы. За ориентир можно взять правила Amazon SES: держать долю отказов ниже 2%, при 5% аккаунт уходит на проверку, при 10% отправку могут приостановить. Если сегмент ползёт вверх, оставьте в нём только тех, кто открывал письма и кликал.

Многое решает происхождение адреса. Подписка через double opt-in значит, что человек подтвердил её из этого самого ящика, и отметка catch-all тут не страшна. Адрес из купленной базы или из формы без подтверждения лучше исключить. Две-три отправки с открытиями и кликами расскажут о сегменте больше любой разовой проверки.