Когда домен считают почтовым сервисом

Вы купили домен, настроили почту и готовы работать, а Google Workspace внезапно заявляет: это не домен, а почтовый сервис. И самое странное — проблему не смогли нормально объяснить даже в поддержке.

Разбор статьи

Автор пытался подключить Google Workspace для своей компании, но на этапе ввода домена получил ошибку: «Введите допустимое доменное имя, а не почтовый сервис».

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

Ход решения

Автор не остановился и открыл консоль разработчика на странице регистрации. Оказалось, что ошибка была на клиентской стороне: срабатывала локальная проверка ввода через регулярное выражение.

Google сверял домен со списком паттернов почтовых сервисов. Среди них был шаблон web\..* — любое доменное имя, начинающееся с web.. Поэтому домен web.one автоматически попадал в «чёрный список».

По той же логике не проходил, например, домен Министерства экономики Украины me.gov.ua, потому что он совпадал бы с паттерном me\..*.

ПРОВЕРКА ДОМЕНА В GOOGLE WORKSPACE
───────────────────────────────────
Ввод домена: web.one
       │
       ▼
┌─────────────────────────────────┐
│  Фронтенд-валидация             │
│  (видимая часть сайта —         │
│   всё, что вы видите в браузере)│
│  Сверка с чёрным списком        │
│  regex-паттернов                │
└─────────────────────────────────┘
       │
       ▼
   Совпадение? ──▶ web\..*
       │
      Да
       │
       ▼
┌─────────────────────────────────┐
│  ❌ "Введите допустимое         │
│     доменное имя,               │
│     а не почтовый сервис"       │
└─────────────────────────────────┘

Что было в чёрном списке

Список оказался неожиданно странным. Помимо очевидных Gmail, Hotmail, Yahoo и Outlook там были паттерны вроде alice\..* и appspeople\.dk. Внутри нашли и домены из разных стран, и совсем неочевидные записи.

Затем автор просто отключил проверку в консоли браузера и завершил регистрацию. Это показало, что сервер не делал ту же проверку — ограничение существовало только на клиенте. Такая архитектура не только создаёт баг, но и даёт простой обходной путь.

РЕШЕНИЕ ПРОБЛЕМЫ
────────────────
Симптом: ошибка "domain is an email provider"
         │
         ▼
┌─────────────────────────────────┐
│  1. Открыть DevTools (F12)      │
│  2. Вкладка Console             │
│  3. Найти функцию валидации     │
│  4. Отключить проверку          │
└─────────────────────────────────┘
         │
         ▼
   Повторить ввод домена
         │
         ▼
   ✅ Регистрация продолжается

Выводы

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

История хорошо показывает, что умение открыть DevTools, понять логику фронтенд-проверки и увидеть ошибку изнутри до сих пор может спасти от бессмысленных кругов поддержки.

Если упрётесь в такую же ошибку, имеет смысл проверить клиентскую валидацию в браузере. Но даже если обход сработает, сервер всё равно может проверять домен по-своему.

Ссылки

• Оригинальная статья на blog.elis.cc — разбор бага в Google Workspace и поиска причины