Узнайте, как выявлять регистрации с недавно созданных доменов с помощью сигналов возраста домена, результатов проверки почты и прогрессивных правил верификации, чтобы снизить мошенничество и количество отскоков.
Потому что они дешёвы и их легко заменить. Если один домен заблокировали, злоумышленник может зарегистрировать другой и продолжить атаки, поэтому при волнах злоупотреблений часто видны всплески регистраций с «свежих» доменов.
Нет. Многие добросовестные пользователи регистрируют домен и сразу же создают аккаунт для нового бизнеса, проекта, события или ребрендинга. Используйте возраст домена как подсказку риска и подтверждайте её по настройке почты и поведению.
Обычно это либо дата регистрации домена у регистратора, либо время «первого обнаружения» в телеметрии (DNS, почтовый трафик, ваши внутренние логи). Эти два показателя могут отличаться — домен мог долго лежать неиспользуемым или сменить владельца.
Начните с проверки синтаксиса по RFC, чтобы отсеять явный мусор, затем проверьте, существует ли домен в DNS, потом MX-запись, и в конце — одноразовые провайдеры и известную плохую инфраструктуру. Эти проверки быстро отвечают на вопросы «это реальный адрес?» и «может ли домен принимать почту?».
Отсутствие MX часто означает, что домен пока не может принимать почту, а значит верификация и онбординг будут ненадёжными. Для очень новых доменов это практичная причина замедлить регистрацию или попросить другой адрес, вместо немедленного предоставления доступа к важным функциям.
Разбейте возраст домена на широкие диапазоны, например 0–7 дней, 8–30 дней, 31–180 дней и 180+ дней. Сочетайте этот бакет с результатами валидации и выбирайте одно последовательное действие: разрешить, требовать верификацию, ограничить или блокировать.
Жёсткий fail блокирует регистрацию сразу при очевидной недействительности или высоком риске (например, неверный синтаксис, несуществующий домен или совпадение с одноразовым провайдером). Мягкий fail позволяет создать аккаунт, но добавляет трение: верификация по электронной почте, CAPTCHA, лимиты запросов или ограничение доступа до подтверждения.
Создавайте аккаунт по умолчанию, но ограничивайте чувствительные действия до прохождения верификации. Например, разрешите установить пароль и посмотреть панель, но отложите запуск пробного периода, выдачу API-ключей или приглашения до подтверждения почты и дополнительных проверок.
Считайте неизвестный возраст недостоверным данными, а не автоматически плохим признаком. Используйте это как повод для дополнительных проверок или повышения уровня верификации и больше полагайтесь на сигналы доставляемости: валидность DNS, наличие MX и совпадение с одноразовыми или блоклистами.
Запустите правила в режиме мониторинга и логируйте: бакет возраста, результат валидации и выбранное действие. Позже сопоставьте с исходами (отскоки, жалобы на спам, chargeback’и или здоровое использование). Для быстрой единой проверки можно использовать API проверки почты, например Verimail, который возвращает синтаксис, проверку домена, MX и совпадение с одноразовыми/блоклистами.
Совсем новые домены привлекательны для злоумышленников: их легко зарегистрировать, это дешёво и их просто выбрасывать. Если один домен заблокировали, можно зарегистрировать другой и продолжать. Поэтому регистрации с «новых» доменов часто идут волнами фальшивых аккаунтов.
У новых доменов также мало истории. По ним меньше публичных сигналов, и они реже попадают в блоклисты. Это «чистая история» помогает злоупотреблениям пройти через простые фильтры и даёт злоумышленникам время, прежде чем домен получит плохую репутацию.
Когда это происходит, обычно возникают те же проблемы для бизнеса: аккаунты, созданные ботами, тратят ресурсы поддержки; через ваш продукт рассылают спам и падает доставляемость; фальшивые триалы используют для скрейпинга или зондирования; мошенничество с оплатой превращается в chargeback’и; качество лидов падает, и отчёты портятся.
Это не значит, что каждый новый домен — плохой. Люди регистрируют домены ежедневно: новый бизнес, побочный проект, событие, ребрендинг или переход с бесплатного почтового ящика на брендированный адрес. Блокировать все новые домены — значит наказывать тех самых пользователей, которые вам нужны.
Практическая цель — уменьшать злоупотребления, не блокируя реальных пользователей. Рассматривайте возраст домена как подсказку риска, а не как приговор. Сопоставляйте её с сигналами валидации электронной почты (синтаксис, настройка домена, признаки доставляемости) и используйте прогрессивную верификацию: для более рискованных регистраций добавляйте небольшое трение, а для обычных пользователей сохраняйте плавный путь.
Законная новая компания может зарегистрировать домен на прошлой неделе, но у неё корректно настроена почта и поведение выглядит по‑человечески. Злоумышленники часто показывают обратное: свежий домен, ненадёжная настройка и массовое автоматическое поведение.
Под «возрастом домена» обычно понимают одно из двух:
Возраст регистрации полезен, потому что многие кампании злоупотреблений регистрируют домен сразу перед использованием. «Первое обнаружение» может быть ещё полезнее на практике: домен мог месяцами лежать неиспользуемым и «проснуться» сегодня, или поменять владельца.
Команды обычно получают данные о возрасте домена из WHOIS/RDAP, фидов регистраторов или реестров (если доступны), пассивного DNS или датасетов «первое наблюдение», а также из собственной истории продукта (когда вы впервые увидели домен).
Частая проблема — отсутствие или неясность данных. Некоторые регистраторы редактируют записи, сервисы приватности скрывают поля, а у некоторых TLD записи непоследовательны. Когда возраст домена неизвестен, считайте это ненадёжным сигналом, а не автоматически плохим. Не блокируйте по умолчанию. Используйте это, чтобы решить, какие дополнительные проверки применить.
Возраст домена — это сигнал, а не приговор. Многие реальные пользователи создают домен и регистрируются в тот же день. В то же время злоумышленники часто полагаются на свежие домены, чтобы быстро менять идентичности. Ценность в сочетании возраста с другими сигналами.
Возраст домена полезен, но он не говорит, достижим ли адрес. Для регистраций с новыми доменами сочетайте возраст с проверками, которые отвечают на простые вопросы: «это вообще адрес?» и «может ли этот домен принимать почту?».
Начните с проверки синтаксиса по RFC. Это быстро и ловит явный мусор: отсутствующие части, недопустимые символы или вставленные не‑почтовые строки. Сам по себе синтаксис не доказывает существование почтового ящика, но убирает много шума.
Далее проверьте, существует ли домен в DNS. Многие злоумышленники используют опечатки, случайные строки или домены, которые вообще не зарегистрированы. Это хорошо сочетается с возрастом домена, так как оба являются сигналами на уровне домена.
Потом выполните проверку MX‑записей. Может ли домен принимать почту? Некоторые новые домены зарегистрированы, но ещё не настроены для почты. Если вы полагаетесь на почту для кодов входа, счетов или онбординга, отсутствие MX — практичная причина замедлить регистрацию или потребовать дополнительное подтверждение.
Наконец, сверяйтесь с одноразовыми провайдерами и известной плохой инфраструктурой. Возраст домена не поймает давний одноразовый сервис, а блоклисты не всегда содержат совсем новый домен. Вместе эти проверки закрывают пробелы друг друга.
Проще думать так:
Вам не нужен идеальный скор для старта. Простая модель работает хорошо: поместите домен в бакет по возрасту, объедините это с результатами валидации и выполните согласованное действие.
Держите бакеты широкими, чтобы потом их можно было тонко настраивать:
Далее комбинируйте бакет с простыми результатами валидации: valid, invalid, disposable, risky и unknown (например, временные проблемы DNS).
Определите два типа ответных действий, чтобы команда не импровизировала:
Например: домену 2 дня и совпадение с одноразовым провайдером — обычно жёсткий фейл. Домену 2 дня, который чисто прошёл валидацию — мягкий фейл: создайте аккаунт, но потребуйте верификацию до начала пробного периода.
Насколько строги правила — зависит от вашего продукта. B2B часто видит законные новые домены (стартапы, домены под проекты), поэтому мягкие фейлы безопаснее при сильной валидации. В потребительских приложениях чаще встречается одноразовое поведение, поэтому можно жёстче относиться к доменам 0–30 дней.
Новые домены не автоматически плохие, но злоумышленники используют их, чтобы быстро менять личности. Рассматривайте возраст домена как один сигнал и подтверждайте его тем, что можно узнать по самой почте.
Проверяйте email при регистрации (не только синтаксис). Подтвердите, что домен существует, есть MX‑записи, и адрес не из списка одноразовых провайдеров.
Посмотрите возраст домена (например через WHOIS/RDAP или вашего провайдера). Не храните полные WHOIS‑блоб‑данные. Оставляйте только необходимое: дату создания (если доступна), статус поиска и бакет возраста.
Комбинируйте сигналы в ясный уровень риска. Держите правила достаточно простыми, чтобы поддержка и продукт потом могли их понять.
Примите действие: разрешить, требовать верификацию, ограничить скорость или блокировать.
Логируйте входные данные и исходы. Хорошие логи превращают сегодняшние догадки в надёжную политику через месяц.
Действия должны соответствовать и риску, и стоимости. Домену 2 дня с валидным MX, но отмеченному как disposable — высокий риск: блокировать. Домену 5 дней с чистой валидацией — средний риск: разрешить создание аккаунта, но потребовать верификацию перед пробным доступом.
Большинство регистраций законные, даже если домен компании совсем новый. Начните с тихих, низкофрикционных проверок и добавляйте шаги только при повышенном риске.
Валидация почты — сильный первый слой: она быстрая, невидимая для пользователя и ловит типичные ошибки, опечатки, неверные домены, отсутствие MX и одноразовые провайдеры.
Когда сигналы складываются (например очень новый домен + провал доменных проверок), эскалируйте с помощью прогрессивной верификации. Держите схему простой:
Дружественный пользователю подход — разделять создание аккаунта и возможности аккаунта. Вместо немедленной блокировки создавайте аккаунт, но ограничивайте его возможности до завершения верификации. Позвольте установить пароль и посмотреть дашборд, но ограничьте чувствительные действия: приглашения, создание API‑ключей, экспорт данных или запуск пробного периода.
Повторные попытки заслуживают отдельного подхода, потому что злоумышленники быстро итератят. Отслеживайте регистрации по IP, по устройству (если используете) и по домену. При множественных попытках за короткое время ускоряйте эскалацию.
Вводите правила поэтапно, чтобы не шокировать реальных пользователей:
Правила работают лучше, когда они простые, объяснимые и легко меняемые. Начните с нескольких исходов (разрешить, верифицировать, блокировать), затем настраивайте по трафику.
Несколько стартовых правил:
Конкретный пример: кто‑то регистрируется как [email protected], домен создан вчера. Адрес проходит валидацию, у домена есть MX. Вместо блокировки вы даёте создать аккаунт, но требуете верификацию почты перед выдачей пробных средств. Если бы тот же адрес совпал с одноразовым списком — вы бы заблокировали немедленно.
Самый быстрый путь сделать защиту непопулярной — наказывать честных пользователей. Новые домены не автоматически плохие. Безопаснее отделять «неизвестное" от "вредоносного" и добавлять трение только когда несколько сигналов указывают в одну сторону.
Наиболее болезненные ошибки предсказуемы:
Чтобы этого избежать, используйте возраст домена как мягкий сигнал. Когда данные о возрасте отсутствуют или конфликтны, больше полагайтесь на проверки доставляемости: верификацию домена, MX‑lookup и совпадение с одноразовыми провайдерами. Предполагайте, что правила будут тестироваться, добавьте лимиты по скорости и логирование, и просматривайте результаты еженедельно (сколько реальных пользователей было заблокировано и какие проверки были наилучшим предиктором).
Перед тем как применять правила для новых доменов, пройдите быстрый список, чтобы ловить очевидное злоупотребление, но давать реальным пользователям понятный путь дальнейших действий.
Если вы можете объяснить правила коллеге за две минуты, готово к первому релизу. Затем настраивайте по реальным данным.
На Product Hunt запустили бесплатный триал, и пришёл всплеск регистраций с новыми доменами. Поддержка завалена пользователями, которые не активируют триал, и команда продаж видит рост отказов. Нужно остановить очевидные злоупотребления, не мешая реальным командам, зарегистрировавшим домен вчера.
Простые правила:
Сравним две регистрации.
Priya регистрируется как [email protected]. Домену 2 дня. Валидация показывает валидный синтаксис, домен разрешается, MX есть, и он не одноразовый.
Исход: ей не запрещают регистрацию, но просят подтвердить почту перед получением полного доступа к триалу. Это заняло секунды, а не минуту.
Бот регистрируется как [email protected]. Домену 3 часа. Валидация показывает отсутствие MX (или совпадение с одноразовым провайдером), и похожие паттерны повторяются в множестве регистраций.
Исход: регистрация блокируется сразу.
После запуска измеряйте, оправдан ли компромисс:
Настраивайте пороги медленно. Цель — блокировать очевидный мусор и не мешать реальным новым командам.
Считайте ранние правила гипотезой. Запустите их в режиме мониторинга на неделю‑две и запишите, что бы произошло: кого бы вы вызвали на проверку, кого бы заблокировали и сколько этих регистраций позже выглядели рискованными.
Логируйте три вещи для каждой попытки регистрации:
Потом подгоняйте по наблюдаемым данным. Если реальные пользователи с новыми доменами попадают под блокировку, переведите этот бакет из «блокировать» в «повысить верификацию». Если злоупотребления всё ещё проходят — ужесточайте сочетания правил, а не повышайте трение для всех.
Когда будете готовы формализовать почтовую сторону, API проверки почты даёт ключевые сигналы быстро при регистрации. Например, Verimail (verimail.co) возвращает проверки синтаксиса по RFC, верификацию домена, проверку MX и реальное совпадение с одноразовыми провайдерами и блоклистами в одном вызове, что упрощает применение жёстких правил только когда домен очень новый или результаты выглядят подозрительно.
Пересматривайте пороги ежемесячно. Злоупотребления меняются, как и ваш продукт. Цель — постоянное давление на плохой трафик без наказания хороших пользователей.
