Проверка домена электронной почты для продуктовых и маркетинговых команд

Почему проверки домена важны (даже если адрес выглядит корректно)

Адрес электронной почты может выглядеть идеально и всё равно “провалиться” в момент отправки подтверждения. «[email protected]» имеет правильную форму и проходит базовую проверку синтаксиса, но это не значит, что домен за ним действительно может принимать почту.

Разница проста:

• Адрес, который выглядит настоящим, следует привычному шаблону (имя + @ + домен).
• Рабочий адрес указывает на домен, который прямо сейчас способен получать почту и в будущем вряд ли создаст проблемы.

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

Типичная ситуация: запускается бесплатный период и регистрации резко растут, но часть пользователей никогда не кликает в письме подтверждения, потому что письмо не приходит. В саппорте скапливаются тикеты, маркетинг винит почтовый инструмент, продукт — «плохие лиды». Часто многие из этих адресов изначально были недоступны.

Проверка домена помогает поймать это заранее. Она проверяет, настроен ли домен после «@» для приёма почты и может пометить распространённые риски (например, провайдеры одноразовой почты), чтобы плохие адреса не загрязняли базу.

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

Что такое проверка домена электронной почты (и что это не)

Проверка домена электронной почты смотрит, способен ли фрагмент адреса после @ принимать почту. Это больше, чем «выглядит ли это как адрес», и меньше, чем «существует ли реальный человек с рабочим ящиком».

Три понятия часто путают:

• Проверка синтаксиса: написан ли адрес в допустимом формате (например, [email protected]), без запрещённых символов?
• Проверка домена: существует ли домен и настроен ли он на приём почты?
• Проверка почтового ящика: существует ли конкретный почтовый ящик (например, [email protected] реально принимает почту)?

Проверка домена — это средний уровень. Обычно она подтверждает, что домен реальный и что в его DNS есть записи маршрутизации почты (часто через проверку MX). Если у домена нет настроек для почты, отправка на него почти наверняка завершится отскоком.

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

Практичная формулировка: проверка домена отвечает на вопрос «можно ли в принципе доставить сюда письмо?», а не «реален ли этот пользователь?».

Какие проверки происходят: домен, DNS и MX

Когда кто‑то вводит адрес, часть после @ — это домен (например, example.com). Проверка домена задаёт один вопрос: выглядит ли домен так, будто он может сейчас принимать почту?

Домен существует (DNS простыми словами)

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

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

Почта принимается (что говорят MX‑записи)

MX‑записи — это записи DNS, которые говорят, куда доставлять почту для домена. Если у домена есть валидные MX‑записи, это обычно означает, что он настроен на приём почты.

Отсутствие MX‑записей не обязательно означает, что адрес фейковый, но это сильный сигнал, что домен не настроен для почты (или настроен неправильно). Для большинства сценариев регистрации отсутствие или некорректность MX — хорошая причина блокировать адрес или попросить указать другой.

Команды обычно согласуют такие исходы:

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

Временные и постоянные ошибки (повторы важны)

Не каждая ошибка окончательна. Иногда DNS‑серверы отвечают с тайм‑аутом или почтовый провайдер временно недоступен. Это временные сбои — их стоит повторить позже. Постоянные ошибки (например, «домен не существует» или «нет записей») обычно не стоит повторять.

Что нужно решить: правила приёма, с которыми согласятся команды

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

Большинство команд успешно работает с тремя действиями:

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

Определите «предупредить» в одном предложении, чтобы это не стало набором исключений.

Где провести границы

Простая отправная точка — сопоставить обычные случаи с одним действием:

• Домен одноразовой почты: обычно блокировать (или предупреждать, если у вас аудитория, ценящая приватность).
• Служебные адреса (support@, sales@, admin@): часто предупреждать, так как они могут быть общими и сложнее привязываются к человеку.
• Бесплатные провайдеры (Gmail, Outlook): обычно разрешать, если вы не строжайший B2B‑сервис.
• Корпоративные домены без рабочей почты (нет MX): блокировать или разрешать только после подтверждения по почте.
• Неизвестные или новые домены: разрешать, но мониторить, или предупреждать, если у вас проблемы с мошенничеством.

После того как вы проведёте эти линии, применяйте ту же логику везде, где адрес появляется (формы регистрации, приглашения, импорт CSV, порталы партнёров). Непоследовательные правила — тихий источник тикетов в саппорте.

Региональные и языковые реалии

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

Запишите также компромисс. Более строгие правила снижают мошенничество и отскоки, но могут блокировать реальных пользователей и увеличить нагрузку в саппорте. Более мягкие правила повышают конверсию, но могут увеличить количество фейков и повредить доставляемости. Если компромисс задокументирован, продукт и маркетинг будут оценивать успех одинаково.

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

Начните с согласования, что для вашего бизнеса означает «хорошая» регистрация. Что важнее: быстрая активация, меньше отскоков, лучшее качество лидов или снижение мошенничества? Если продукт хочет меньше тикетов, а маркетинг — лучшую доставляемость, зафиксируйте эти цели письменно. Иначе правила будут меняться в зависимости от того, кто громче жалуется.

Затем выберите исходы, которые соответствуют реальному риску, а не интуиции. Простая схема:

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

Чтобы внедрение было управляемым, сфокусируйтесь на нескольких конкретных шагах:

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

Держите сообщения практичными. Если домен провалил проверку MX, не показывайте «ошибка DNS». Напишите: «Этот домен не может принимать почту. Попробуйте другой адрес.» Если вы предупреждаете, предложите путь вперёд: «Вы можете продолжить, но для активации потребуется подтвердить почту.»

Наконец, постройте обратную связь. Отслеживайте, как часто срабатывает каждый исход и что делают пользователи дальше. Если пользователи из группы «предупреждать» конвертируют хорошо и не отскакивают — ослабьте правило. Если заблокированные пользователи часто появляются в отчётах о мошенничестве — ужесточите.

Как продукт и маркетинг должны измерять успех

Успех — это не просто «больше регистраций». Цель — не усложнять жизнь реальным людям и при этом уменьшать дорогие последствия: отскоки, жалобы и фейковые аккаунты.

Следите за двумя блоками показателей параллельно: объём сверху воронки и качество дальше по воронке. Если конверсия растёт, но отскоки и жалобы тоже, победы нет.

Метрики, которые команды могут смотреть еженедельно:

• Конверсия регистрации (посетитель → созданный аккаунт)
• Уровень активации (новые пользователи, достигшие ключевого первого шага)
• Доля жёстких отскоков для писем онбординга и кампаний
• Доля жалоб на спам и отписок
• Сигналы мошенничества и злоупотреблений (дубли аккаунтов, злоупотребление купонами, необычные всплески регистраций)

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

Чтобы выбрать строгие или мягкие правила, проведите простой A/B‑тест минимум за один полный бизнес‑цикл (обычно 1–2 недели). Сравните конверсию и метрики качества, а затем решайте по чистому эффекту, а не по одному значимому показателю.

Частые ошибки и ловушки

Большинство проблем с проверками почты — не технические, а политические. Правило, которое звучит безопасно, может блокировать реальных клиентов или пропустить мусор.

Классическая ошибка — путать проверку формата с реальной валидацией. Регулярное выражение скажет, выглядит ли адрес как [email protected]. Оно не скажет, может ли домен принимать почту или склонен ли адрес отскакивать. Проверка домена сосредоточена на том, что идёт после @, а не только на форме текста.

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

• Блокировка всех бесплатных почтовых провайдеров по умолчанию (часто убивает регистрации студентов, малых бизнесов и тестировщиков).
• Рассмотрение временных проблем DNS как постоянных ошибок (создаёт ложные отказы).
• Остановка на проверках синтаксиса (вы всё равно примете опечатанные домены и домены без настроенной почты).
• Довольно быстро устаревающиеся списки одноразовых доменов (они меняются часто).
• Неинформативные ошибки типа «Неверный email» (пользователи не знают, что исправлять).

Простой пример: пользователь регистрируется из кофейни, и один DNS‑запрос завершается тайм‑аутом. Если система блокирует сразу — вы потеряли реальный лид из‑за временного сбоя сети.

Лучшие настройки по умолчанию, которые не наказывают хороших пользователей:

• Повторять запросы при тайм‑аутах или делать мягкий отказ; жёсткий отказ — только при явных сигналах (например, домен не существует или нет маршрутизации почты).
• Разрешать бесплатные провайдеры, если нет данных, что они вредят, и делать исключения простыми для пользователей.
• Держать обнаружение одноразовых доменов в актуальном состоянии.
• Писать понятные ошибки с шагом, что делать дальше (например: «Сейчас мы не можем проверить домен. Попробуйте снова или используйте другой адрес.»).

Краевые случаи, которые вы увидите в реальной работе

Большинство регистраций просты. Сложность — в тех случаях, когда проверка домена не даёт однозначного ответа, даже если пользователь реальный.

Международные и редкие домены могут удивлять. Клиенты пользуются национальными доменами (.de, .br) или новыми суффиксами. Некоторые домены используют нелатинские символы (международные домены, IDN), которые могут выглядеть странно в логах, но оставаться валидными.

Новые домены — ещё один краевой случай. Компания может купить домен сегодня и начать собирать регистрации до полного распространения DNS‑записей. В течение нескольких часов один и тот же домен может выглядеть валидным из одного региона и отсутствовать из другого.

Корпоративные домены тоже могут быть нестандартными. Крупные компании используют split DNS (разные ответы в зависимости от расположения) или жёсткие настройки, которые выглядят необычно.

Также будут прерывистые ошибки запросов. Пользователи за VPN, в корпоративных сетях или под агрессивными средствами защиты могут вызвать временные тайм‑ауты. Это не то же самое, что «плохой» домен.

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

• Повторите проверку один‑два раза в коротком окне.
• Разрешите регистрацию, но потребуйте подтверждение почты перед активацией.
• Блокируйте только при явно неверных результатах.
• Помечайте рискованные случаи (например, вероятные одноразовые провайдеры) для доп. проверки.
• Логируйте «неизвестные» отдельно, чтобы находить паттерны.

Контрольный список перед выпуском новых правил

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

Проверки перед запуском

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

• Подтвердите, что домен может принимать почту (домен существует и есть рабочая маршрутизация почты, часто проверяемая через MX‑запись).
• Решите, как обращаться с одноразовыми и высокорисковыми доменами (блок, предупреждение, ограничения или доп. подтверждение).
• Определите, как обрабатывать служебные адреса вроде info@, sales@, support@.
• Определите политику для неопределённых результатов (тайм‑ауты и временные проблемы DNS).
• Убедитесь, что вы можете измерить влияние (доля отскоков, жалобы на спам, активация триала, жалобы о «неправильно заблокировано»).

Сделайте план запасного варианта явным

Большинство споров происходит в серой зоне, а не с очевидными фейками. Запишите fallback‑путь для неопределённых случаев и кто принимает решение, когда метрики конфликтуют (маркетинг хочет меньше отскоков, продукт — меньше блокировок реальных пользователей).

Простой пример: согласование правил для регистрации на триал

B2B‑SaaS команда видит рост регистраций на 18% в месяц, но продажи жалуются, что «новые лиды» не отвечают. Маркетинг видит рост отскоков, а продукт — много аккаунтов с одноразовыми адресами.

Они ужесточают правила, не убивая при этом реальных регистраций.

Сначала выбирают ясную политику: одноразовые домены блокируются при регистрации. Служебные адреса (info@, sales@, support@) разрешаются, но форма показывает мягкое предупреждение: «Для быстрого настроя и восстановления доступа используйте рабочую почту.» Продукт отвечает за UX и формулировку, маркетинг — за тон, а продажи определяют, что считать полезным лидом.

Через две недели они совместно анализируют результаты. Конверсия слегка упала, но доля отскоков значительно снизилась. Число фейковых аккаунтов в первые 24 часа уменьшилось, и у продаж стало меньше «мертвых» лидов, хотя общий объём немного снизился.

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

Следующие шаги: документировать, выкатывать и поддерживать правила актуальными

Относитесь к вашим правилам как к продуктному решению, а не как к разовой правке. Когда продукт и маркетинг согласуют исходы (меньше фейков, меньше отскоков, меньше тикетов), принимать решения о блокировках становится проще.

Напишите один общий документ, понятный всем:

• Что значит «пройти» и «провалиться» для проверки домена
• Что происходит при провале (блок, предупреждение или разрешение с трением)
• Известные исключения (партнёры, крупные клиенты, внутренние домены)
• Кто может утверждать изменения и кто отвечает за метрики
• Несколько конкретных примеров и ожидаемый результат

Разворачивайте поэтапно, чтобы не отрезать реальных пользователей:

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

Если вы хотите прогнать эти проверки через один сервис, Verimail (verimail.co) — это API валидации почты, которое сочетает синтаксические проверки по RFC, проверку домена, поиск MX‑записей и сопоставление с черными списками одноразовой почты, чтобы вы могли применять одни и те же правила на форме и в бэкенде.

Назначьте простое напоминание (ежемесячно подходит большинству команд) для просмотра доли отскоков, завершения регистрации и числа предупреждений/блокировок, затем корректируйте правила по данным.