Создайте список разрешённых и запрещённых доменов для регистрации, который блокирует одноразовые домены, но не мешает реальным компаниям. Советы по владению и поддержке.
По умолчанию используйте denylist, которая блокирует известные одноразовые провайдеры и домены, связанные с повторным злоупотреблением. Добавляйте allowlist только когда доступ должен быть ограничен (например, внутренние инструменты или портал клиентов для конкретных компаний).
Начинайте с ваших данных о регистрациях за последние 30–90 дней. Ищите домены с большим числом регистраций и почти нулевой активацией, повторяющимися жесткими bounce или явными жалобами на злоупотребления — затем прежде чем блокировать, проверьте несколько примеров.
Сначала нормализуйте домен адреса: уберите пробелы, приведите к нижнему регистру и удалите конечную точку, если она есть. По умолчанию сопоставляйте точные домены, потому что широкие шаблоны — самый простой путь случайно заблокировать легитимных пользователей.
Хорошая практика — «побеждает allowlist», чтобы проверенное исключение могло быстро разблокировать реального пользователя, даже если существует более широкий запрет. Если выбрать «denylist побеждает», будьте готовы к большему числу обращений в поддержку и более медленному восстановлению.
Избегайте широких правил вроде блокировки всех национальных TLD или доменов с дефисом. Перед добавлением в denylist проверьте, не используется ли домен университетами, органами власти или крупными провайдерами, и посмотрите на недавние успешные регистрации с этого домена.
Показывайте простую причину и понятный следующий шаг. Например: «Этот провайдер электронной почты не разрешён. Пожалуйста, используйте рабочий email или свяжитесь со службой поддержки для запроса исключения», и убедитесь, что поддержка видит, какое именно правило сработало.
Сначала включите режим «только логирование», чтобы оценить влияние, затем вводите правила малыми партиями с возможностью быстрой отмены. Протестируйте на недавней выборке реальных регистраций, чтобы прикинуть, сколько реальных пользователей вы потенциально заблокируете.
Назначьте явного владельца для утверждений и апелляций, и логируйте каждое изменение с коротким обоснованием и датой проверки. Без владельца списки быстро деградируют и появляются вечные блокировки, которые никто не может объяснить или снять.
Практический ориентир: проверять denylist еженедельно, а allowlist — ежемесячно. Добавляйте даты истечения для временных блоков и исключений, чтобы правила автоматически падали, если их не продлить с новыми доказательствами.
Списки доменов — это уровень политики, а не доказательство того, что адрес реальный. Сочетайте их с валидацией email: проверкой синтаксиса, DNS и MX-записей и сигналами одноразовых провайдеров, чтобы меньше блокировать легитимных пользователей и при этом ловить плохие регистрации.
Правила по доменам существуют, чтобы защитить регистрацию от предсказуемых проблем: фейковых аккаунтов, возвратов писем и злоупотреблений. Если люди регистрируются с одноразовых адресов, вы получаете пользователей, с которыми не удаётся связаться, повышенный процент bounce и захламленную базу. Одноразовые домены также часто используются ботами и мошенниками, потому что с их помощью легко создать тысячи аккаунтов.
Список разрешённых и список запрещённых доменов при регистрации — грубый, но полезный контроль. Он работает лучше всего, когда вы чётко понимаете, что хотите остановить. Блокировка известных одноразовых провайдеров, например, может быстро снизить количество низкокачественных регистраций ещё до отправки проверочного письма.
Полезно разделять две идеи:
Эта разница важна, потому что компромисс реален. Более строгие правила обычно означают меньше плохих регистраций, но и больше ложных отказов. Если блокировать слишком широко, вы оттолкнёте реальных пользователей, которые регистрируются добросовестно.
Так что такое легитимный корпоративный домен в вашем контексте? Обычно это домен, принадлежащий реальной организации и способный надёжно получать сообщения. Это может быть основной домен компании (например, name.com), региональные домены (name.co.uk) или домен, которым управляет поставщик услуг и который используют сотрудники. Цель — блокировать рискованные домены, не наказывая нормальную деловую почту.
Список доменов — это не фича. Это политическое решение, которое влияет на доходы, нагрузку в поддержку и доверие. Прежде чем строить allowlist и denylist для регистраций, определите, что именно вы пытаетесь предотвратить.
У большинства команд есть одна основная цель (и пара вторичных): остановить одноразовые адреса, уменьшить мошенничество при регистрации или защитить доставляемость, не допуская плохие данные. Цель важна, потому что она меняет, что вы блокируете и насколько строго. Блокировка одноразовых доменов обычно безопасна. Блокировка всех «бесплатных email» рискованна и часто отсекает легитимных пользователей.
Также запишите, что вы не будете блокировать, даже если это выглядит подозрительно. Частые примеры: платящие клиенты, приглашённые пользователи, партнёры и внутренние аккаунты сотрудников. Простое правило вроде «Мы разрешаем эти сценарии, но можем пометить их на проверку» предотвращает много случайных блокировок.
Решите, где будет действовать принудительное применение правил, чтобы они оставались последовательными в продукте: формы самообслуживания, публичные API, админские создания пользователей в бэк-офисе, приглашения (часто более мягкие), и чувствительные операции вроде сброса пароля или смены почты (не удивляйте существующих пользователей).
Наконец, установите ожидания для поддержки. Если кто-то заблокирован, что он увидит и как исправить ситуацию? Хорошее сообщение при блокировке включает простую причину («Этот провайдер почты не разрешён»), безопасный следующий шаг (использовать рабочий email или связаться с поддержкой) и понятный путь обжалования.
Allowlist — это строгий вариант. Вы позволяете регистрироваться только если домен email совпадает с набором доверенных доменов. Это работает лучше, когда вы заранее знаете, кому должен быть доступ.
Типичные случаи для allowlist: внутренние инструменты для сотрудников, приватные бета-тесты, где приглашения приходят конкретным компаниям, или B2B-порталы клиентов, где каждый аккаунт соответствует известному бизнес-домену. В таких сценариях риск заблокировать реального человека невелик, потому что нужные домены предсказуемы и поддержка может добавить отсутствующие.
Denylist — это гибкий вариант. Вы пропускаете большинство доменов, но блокируете те, которые явно низкого качества или используются для злоупотреблений. Здесь обычно блокируют одноразовые домены, домены, связанные с повторным злоупотреблением, и очевидные шаблоны «мусорных» доменов.
Гибридный подход часто безопаснее для роста: используйте denylist как базу, а для важных исключений добавляйте целевые записи в allowlist. Например, крупный клиент может использовать непривычный корпоративный домен, или партнёр может зарегистрироваться с поддомена, который сначала кажется подозрительным.
Держите формулировки правил простыми, чтобы их было легко проверять и трудно неправильно понять. Сопоставляйте точные домены (например, example.com) когда это возможно. Решите заранее, считаются ли поддомены тем же самым (например, учитывать ли mail.example.com). Если вы используете временные исключения, назначьте владельца и дату истечения, и предпочитайте небольшие понятные правила вместо хитрых паттернов, которые могут блокировать не тех людей.
Хороший стартовый список — это не то, что вы скачали и вставили. Он должен основываться на том, что реально происходит в вашем потоке регистрации. Так вы получите allowlist/denylist, отражающие реальный риск, а не предположения.
Начните с ваших данных. Вытяните попытки регистрации за последние 30–90 дней, подтверждённых пользователей, bounce-письма, жалобы на спам и любые отчёты о мошенничестве. Группируйте по доменам и ищите шаблоны: высокий объём при очень низкой активации, повторяющиеся жёсткие bounce или один и тот же домен, создающий много аккаунтов за короткое время.
Если у вас есть внутренняя отчётность, ищите повторных нарушителей. Практическое правило: домены с большим объёмом и почти нулевой вовлечённостью заслуживают проверки, а не автоматической блокировки. Выберите небольшое число доменов, расследуйте несколько адресов и подтвердите поведение прежде чем добавлять домен в список.
Составьте «хорошую» сторону тоже на основе внутренней информации. Попросите отделы продаж и customer success дать короткий список основных клиентских доменов и активных перспектив. Они могут стать начальным allowlist (или по крайней мере списком «никогда не блокировать без проверки»), что поможет избежать трения для реальных компаний.
Что бы вы ни добавили, запишите причину. Короткая и полезная заметка: источник (отчёт, тикет, дело о мошенничестве, данные bounce), дата добавления, кто утвердил, что вы наблюдали и когда проведёте ревью.
Пример: вы видите 400 регистраций с одного домена за неделю, но ноль подтверждений и много одинаковых IP-диапазонов. Вы записываете доказательства, добавляете домен в denylist и ставите проверку через 30 дней на случай, если шаблон изменится.
Относитесь к домену в email как к ненадёжному вводу. Небольшие вариации форматирования могут ломать правила.
Нормализуйте каждый адрес одинаково перед сравнением со списками: убирайте пробелы, переводите в нижний регистр и удаляйте конечную точку (некоторые системы трактуют example.com. как валидный). Делайте это один раз, близко к моменту, когда email впервые попадает в систему, чтобы все последующие проверки видели одно и то же значение.
Далее решите, как будет происходить сопоставление, и пропишите это. «Только точный домен» безопаснее для большинства команд, потому что избегает сюрпризов. «Включать поддомены» может быть полезно (например, блокировать mail.disposable.com вместе с disposable.com), но это также может заблокировать легитимные случаи, если компания использует необычные поддомены.
Выберите одно правило приоритета и применяйте его везде. Многие продукты выбирают «побеждает allowlist», чтобы проверенное исключение сразу разблокировало реального пользователя, даже если есть более широкий deny-правило. Если выберете «denylist побеждает», ожидайте больше тикетов в поддержку и более медленное восстановление.
Безопасный rollout обычно выглядит так:
Самый быстрый способ потерять реальных пользователей — блокировать по широким шаблонам. Избегайте правил вроде «блокировать все country TLD» или «блокировать всё с дефисом». Многие реальные компании используют домены типа company.co.uk, company.com.au или региональные поддомены вроде eu.company.com.
Относитесь к поддоменам как к норме, а не к подозрению. Крупный бизнес может маршрутизировать почту через поддомены для разных команд, регионов или после поглощений. Если ваше правило проверяет только «основной» домен, убедитесь, что оно корректно обрабатывает случаи вроде company.co.uk vs company.com и не помечает mail.company.com как «неизвестный».
Будьте осторожны с провайдерами маршрутизации почты. Некоторые легитимные компании отправляют и получают почту через сервисы, которые выглядят общими, а их MX-записи могут напоминать используемые одноразовыми сервисами или маркетинговыми решениями. Только по домену нельзя однозначно определить намерение.
Простой чек-лист перед добавлением домена в denylist:
Наконец, создайте процесс исключений для важных аккаунтов. После слияний у одного клиента может быть пять–десять активных доменов. Сделайте поддержку или продажам простой способ запросить временное разрешение, пока вы проверяете владение и безопасно обновляете правила.
Правила по доменам чаще всего проваливаются по скучной причине: за ними никто не отвечает. Назначьте одну команду или роль, которая явно отвечает за утверждение изменений и обработку апелляций. Речь не о контроле, а о скорости и последовательности, когда реальный клиент блокируется.
Базовый рабочий процесс прост:
Каждое изменение должно логироваться, чтобы потом можно было его объяснить. Лог пусть будет коротким: кто запросил, кто утвердил, что изменилось (домен и тип правила), почему (доказательства), когда правило вступило в силу и когда его проверить.
Установите SLA для спорных блокировок, чтобы легитимные пользователи не застряли. Например: подтверждение получения запроса в течение 4 рабочих часов и решение в течение 1 рабочего дня, с аварийным путём для платных клиентов.
Перед добавлением домена в denylist требуйте доказательств, а не ощущений. Типичные доказательства: высокий объём регистраций с явными паттернами злоупотреблений, повторяющиеся жёсткие bounce, жалобы на спам или высокий процент совпадений с известными одноразовыми провайдерами.
Пример: поддержка сообщает, что пользователи с acme-partners.com не могут зарегистрироваться. Владелец проверяет лог, видит, что домен был заблокирован из-за 30 спам-регистраций за час, и переключает правило на временное вместе со строгой дополнительной проверкой, затем делает ревью через 48 часов.
Список доменов — это не единоразовая настройка. Как только вы перестаёте за ним следить, он начинает дрейфовать: старые схемы злоупотреблений исчезают, появляются новые одноразовые домены, и одна неправильная запись тихо блокирует хороших пользователей.
Установите ритм ревью, соответствующий риску. Еженедельная проверка denylist — распространённая отправная точка, поскольку злоумышленники действуют быстро. Allowlist обычно достаточно проверять ежемесячно, потому что легитимные домены меняются медленнее.
Чтобы предотвратить «гниение» списка, делайте временные решения с истечением по умолчанию. Если вы добавили домен из-за короткой вспышки спама, привяжите дату истечения и заметку о причине. То же самое для исключений («разрешить этот домен для Партнёра X до окончания контракта»). Когда срок истечёт, правило снимается, если кто-то не продлил его с новыми доказательствами.
Отслеживайте несколько метрик, чтобы видеть, помогает ли список или вредит: процент блокировок, процент апелляций, ложные срабатывания (подтверждённые легитимные пользователи, которых вы заблокировали), bounce rate и концентрацию по доменам (сколько трафика идёт с одного домена).
Следите за двумя сигналами в особенности: новыми одноразовыми доменами и резкими всплесками по одному домену. Если examplemail.co вырос с 2 регистраций в день до 400 за час, расследуйте прежде чем массово блокировать. Смотрите на географию, IP-шаблоны и действительно ли адреса синтаксически валидны и имеют реальную маршрутизацию почты.
Наконец, агрессивно удаляйте устаревшие записи. Если домен давно не давал злоупотреблений или постоянно вызывает ложные блокировки для реальных компаний, удалите его или замените жёсткий блок на мягкий контроль: лимиты по скорости, дополнительная верификация или ручная проверка.
Самый быстрый способ подорвать доверие реальных пользователей — блокировать домены по ощущениям. Список разрешённых и запрещённых доменов работает только если он основан на доказательствах, регулярно проверяется и применяется одинаково везде.
Одна из распространённых ловушек — слишком широкие блокировки. Команды иногда запрещают целые верхнеуровневые домены или большого провайдера из-за краткосрочной вспышки злоупотреблений. Это почти всегда задевает легитимных людей, особенно подрядчиков, студентов и международных пользователей.
Другая ловушка — маркировать домен как одноразовый только потому, что он новый, редкий или выглядит «случайным». Многие реальные компании используют мелкие хостинги, ребрендинги или региональные провайдеры. Если у вас нет доказательств (уровень мошенничества, bounce, жалобы), относитесь к «неизвестному» как к «неопределённому», а не как к «плохому».
Вот шаблоны, которые причиняют наибольший вред:
Даже корректная блокировка может создать проблемы, если UX неясен. Если кто-то попадает на блок, ему нужно понять, что произошло и что делать дальше. Логируйте точную причину и правило, которое сработало, показывайте простое сообщение (избегайте расплывчатого «недействительный email») и держите быстрый путь исключения для известных клиентов или партнёров.
Перед тем как деплоить обновление allowlist/denylist, сделайте проход безопасности. Большая часть вреда приходит от мелких несоответствий, отсутствия контекста или изменений без возможности отката.
Начните с правил сопоставления. Решите, сопоставляете ли вы только точные домены (example.com) или включаете поддомены (mail.example.com). Затем нормализуйте ввод одинаково каждый раз: приведение к нижнему регистру, обрезка пробелов и приведение международных доменов к единому формату. Если ваша система трактует Gmail.com и gmail.com по-разному, вы будете пропускать случаи и создавать путаницу.
Убедитесь, что каждое правило объяснимо. Для каждой записи должно быть короткое обоснование, дата добавления и явный владелец, который сможет ответить позже. «Плохой домен» — не причина. «Наблюдалось 1 200 мошеннических регистраций на прошлой неделе» — это причина.
Сделайте путь апелляции простым, но реальным. Поставьте временную проверку на спорные записи, чтобы ошибки не жили вечно. И не позволяйте временным исключениям стать постоянными случайно: если вы разрешили рискованный дом для партнёрского запуска или события, задайте дату истечения и снимите правило, если его не продлили.
После релиза следите за эффектом. Отслеживайте ложные срабатывания и оперативно реагируйте. Мониторьте bounce rate и изменения доставляемости для недавно разрешённых доменов. Выборочно проверяйте недавние регистрации, чтобы убедиться, что правила работают как задумано.
B2B SaaS замечает всплеск аккаунтов с похожими доменами (например, «acme-corp-support.com» вместо реального имени компании) и волну одноразовых провайдеров. Продажи жалуются на мусорные лиды, а поддержка видит попытки chargeback. У команды уже есть allowlist и denylist, но они не трогались несколько месяцев.
Они начинают с взвешенных действий, а не с массовой чистки. Сначала добавляют одно целевое deny правило для самого плохого одноразового домена из логов. Также устанавливают временный лимит скорости на рискованные регистрации (один IP-диапазон, высокая скорость, повторяющиеся похожие логины). Это снижает злоупотребления в процессе обучения, вместо того чтобы блокировать целые категории доменов.
Через два дня блок попадает на реального клиента. Крупное предприятие использует региональный поддомен для почты (например, [email protected]). Широкое правило, призванное поймать похожие поддомены, случайно срабатывает на него. Поддержка эскалирует с доказательствами: у клиента есть подписанный заказ, стабильная история IP и письма bounce, потому что аккаунт не завершил регистрацию.
Исправление не в удалении deny записи. Они добавляют узкое исключение в allowlist для верифицированного корпоративного домена, документируют причину и ставят дату истечения, чтобы позже пересмотреть.
Через две недели команда анализирует результаты: процент заблокированных регистраций вырос до 6% (с 1%), но количество обращений в поддержку остаётся низким — 0.2% от всех регистраций. Bounce на приветственных письмах упал с 3.4% до 1.1%, и продажи отмечают меньше фейковых демо. Ключевое достижение — уверенность: у каждого правила теперь есть владелец, причина и путь отката.
Списки доменов полезны, но это грубый инструмент. Сочетайте их с валидацией email, чтобы ловить плохие адреса даже когда домен выглядит нормально, и избегать блокировки реальных пользователей только из‑за непривычного корпоративного домена.
Начните с формулировки политики простым языком: что вы блокируете, что разрешаете и что идёт на ручную проверку. Это помогает поддержке, продукту и инженерии понимать, почему регистрация отклонена.
Практический поток: проверьте синтаксис, подтвердите, что домен может принимать почту (проверки DNS и MX), найдите совпадения с известными одноразовыми провайдерами и ловушками, затем примените ваши allowlist и denylist правила (включая исключения). Логируйте результат, чтобы можно было учиться и корректировать.
Если хотите упростить правила, но получить сильные сигналы на этапе регистрации, Verimail (verimail.co) — один из вариантов. Он предоставляет проверки синтаксиса по RFC, верификацию домена и MX, а также сопоставление с одноразовыми провайдерами в одном API-вызове. В таком подходе ваши списки остаются слоем политики, а валидация берёт на себя основную работу по оценке того, выглядит ли адрес реальным и достижимым.
