Accept-all домен: что это и чем опасен для рассылок
Accept-all домен (он же catch-all) - домен, почтовый сервер которого принимает входящие письма на любой адрес, включая несуществующие ящики. Отправьте письмо на abcdef12345@такой-домен.com, и сервер ответит «ОК, принято». Ящика abcdef12345 не существует, но сервер не отклонит письмо.
How it works technically
A standard mail server checks the RCPT TO command during the SMTP handshake. If the recipient exists, it responds with 250 OK. If the recipient does not exist, it responds with 550 User unknown. This allows a validator to determine whether a specific mailbox is alive.
An accept-all server responds with 250 OK to every RCPT TO. The validator asks: “Will you accept mail for test123@domain.com?” The server says yes. “How about xyzrandom@domain.com?” Yes again. It is impossible to distinguish a real mailbox from a nonexistent one through SMTP alone.
The configuration is set at the MTA (Mail Transfer Agent) level. In Postfix it is the virtual_mailbox_maps directive or a catch-all alias. In Exchange, transport rules handle it. Administrators enable it deliberately, usually to avoid losing messages due to address typos.
Почему компании включают accept-all
Главная причина - страх потерять важное письмо. Клиент отправил заказ на slaes@company.com вместо sales@company.com. Без accept-all письмо отскочит. С accept-all попадёт в общий ящик, и его обработают.
Вторая причина - простота настройки. Маленькая компания настраивает accept-all на единственный ящик вместо создания отдельного адреса для каждого сотрудника. Вся почта приходит туда, владелец разбирает вручную.
Третья причина - маркетинговое отслеживание. Некоторые компании используют уникальные адреса для каждого канала: promo@, webinar@, partner@. Accept-all позволяет создавать такие адреса на лету без настройки каждого вручную.
The problem for email validation
Accept-all is the primary headache for email validators. SMTP verification, which works reliably on standard servers, is useless here. The server says “yes” to everything, and the validator cannot determine whether a specific mailbox exists.
Validators detect accept-all configurations by sending an RCPT TO for a deliberately random address (e.g., qwerty-random-test-12345@domain.com). If the server responds 250 OK to that garbage, it is accept-all. All addresses on that domain are then flagged as “accept-all” or “unverifiable.”
This does not mean all addresses on accept-all domains are bad. Real mailboxes belonging to real people exist among them. But the validator cannot separate them from nonexistent ones. The decision to send to accept-all addresses is yours.
Как работать с accept-all адресами в рассылках
Полностью исключать accept-all адреса - перестраховка. Среди них могут быть ваши лучшие клиенты. Но отправлять без оглядки - тоже риск: часть адресов не существует и даст bounce.
Разумный подход: выделить accept-all адреса в отдельный сегмент. Мониторьте bounce rate для этого сегмента отдельно. Если он ниже 2% - продолжайте. Если выше - сужайте сегмент, оставляя только адреса с историей взаимодействия (открывали письма, кликали).
Если адрес на accept-all домене попал через double opt-in, он надёжен: человек подтвердил подписку из этого ящика. Accept-all статус в этом случае не проблема.
Если адрес из купленной базы или через single opt-in без валидации - риск высокий. Такие адреса лучше исключить или проверить дополнительно.
Масштаб проблемы
По разным оценкам, 10-20% корпоративных доменов настроены как accept-all. Среди крупных почтовых провайдеров (Gmail, Outlook.com, Yahoo) accept-all не используется, но они и не дают прямой SMTP-ответ о существовании ящика.
В B2B-базах доля accept-all адресов может достигать 25-30%, потому что корпоративные домены чаще используют эту конфигурацию. Для B2C-баз, где преобладают Gmail и Яндекс.Почта, проблема менее актуальна.
uChecker определяет accept-all домены и помечает такие адреса отдельным статусом. Вы видите, какая часть базы находится на accept-all серверах, и принимаете решение: отправлять, сегментировать или исключить.
