Google Workspace acha que meu domínio é um provedor de e-mail (2025)
O Google Workspace está bloqueando o cadastro de certos domínios personalizados porque sua validação apenas no frontend os trata como se fossem provedores públicos de e-mail, com a lógica ofensiva aparentemente baseada em uma lista de regex excessivamente ampla. Comentadores destacam como isso expõe processos internos ruins, respostas de suporte opacas e inúteis que podem ter sido geradas por IA, e uma disposição de perder clientes pagantes em vez de corrigir casos extremos de baixa prioridade. O episódio alimenta preocupações mais amplas sobre decisões automatizadas e sem responsabilização em grandes plataformas SaaS e leva muitos a defender alternativas como auto-hospedagem, provedores menores ou escolhas de TLD mais convencionais.
Verificação de “Segurança” Apenas no Frontend e Lista de Regex
- Muitos se surpreendem que o bloqueio tenha sido implementado inteiramente no lado do cliente enquanto é descrito como uma “segurança importante”.
- Vários concluem que, na verdade, trata-se de um filtro antiabuso / antifraude tosco para impedir usuários de registrar Workspace para domínios que pareçam provedores de e-mail existentes.
- A regex parece corresponder a rótulos no estilo de provedores (por exemplo, “web”, “gmx”, “alice”) em muitos TLDs; comentaristas observam que esses ISPs/provedores de e-mail historicamente usavam vários TLDs de países diferentes.
- Alguns acham que a regex é muito antiga ou foi escrita por um desenvolvedor inexperiente; outros veem isso como uma “engenharia de produto” rápida que foi lançada e nunca revisitada.
Risco de Burlar a Verificação
- Alguns aprovam desativar o JS para prosseguir, observando que isso prova que é apenas cosmético.
- Outros alertam que isso é arriscado: o Google pode mais tarde impor a mesma regra no lado do servidor e bloquear o domínio ou a conta com pouca possibilidade de recurso.
Suporte, Prioridades e Desequilíbrio de Poder do Google
- Muitos relatam experiências semelhantes de suspensões opacas e fluxos de suporte inúteis, mesmo para clientes pagantes de Workspace / Google Cloud.
- Há uma forte sensação de que o Google só oferece suporte significativo para clientes muito grandes; empresas menores e indivíduos se sentem descartáveis.
- Este episódio reforça o receio de confiar a infraestrutura central do negócio (e-mail, identidade) a um provedor que pode cortar o acesso unilateralmente.
Peculiaridades de Domínio/TLD e Escolhas “Não Convencionais”
- Vários usuários descrevem seus próprios domínios sendo rejeitados (domínios curtos, números no início, TLDs incomuns como .one, .email).
- Alguns argumentam que esse é o custo previsível de usar TLDs “estranhos”; אחרים respondem que o próprio Google vende tais domínios e deveria lidar com eles corretamente.
- Há uma discussão paralela sobre novos gTLDs com preços premium, falta de proteção de preço e conselhos para preferir TLDs tradicionais (.com, .org, .net, ccTLDs).
Alternativas e Auto-hospedagem
- Comentadores mencionam migrar para outros provedores hospedados (por exemplo, plataformas menores de e-mail) ou auto-hospedar e-mail como forma de escapar do ecossistema e das políticas do Google.
Suporte Gerado por IA e Dystopia da Automação
- A estranha explicação do suporte (sobre “.web” e “domínios fictícios”) é amplamente suspeitada de ter sido gerada por LLM; outros alertam para não atribuir demais à IA.
- Surgem preocupações mais amplas sobre tomada de decisão automatizada, processos de apelação kafkianos e fornecedores de SaaS usando IA e scripts para controlar o acesso sem responsabilização.