Google Workspace cree que mi dominio es un proveedor de correo electrónico (2025)

Artículo original ↗ Discusión en Hacker News ↗

Google Workspace está bloqueando ciertos dominios personalizados durante el registro porque su validación solo en el frontend los trata como si fueran proveedores públicos de correo, con la lógica problemática aparentemente basada en una lista de regex demasiado amplia. Los comentaristas destacan cómo esto expone procesos internos deficientes, respuestas de soporte opacas y poco útiles que podrían estar generadas por IA, y una disposición a perder clientes de pago antes que corregir casos límite de baja prioridad. El incidente alimenta preocupaciones más amplias sobre la toma de decisiones automatizada y sin rendición de cuentas en grandes plataformas SaaS, y empuja a muchos a defender alternativas como el autoalojamiento, proveedores más pequeños o elecciones de TLD más convencionales.

Comprobación de “seguridad” solo en el frontend y lista de expresiones regulares

  • A muchos les sorprende que el bloqueo se implementara بالكامل del lado del cliente mientras se describía como una “seguridad importante”.
  • Varios deducen que en realidad es un filtro rudimentario antiabuso / antifraude para impedir que los usuarios registren Workspace con dominios que parezcan proveedores de correo existentes.
  • Parece que la regex coincide con etiquetas de estilo proveedor (p. ej., “web”, “gmx”, “alice”) a través de muchos TLD; los comentaristas señalan que estos ISP/proveedores de correo históricamente usaban múltiples TLD de país.
  • Algunos creen que la regex es muy antigua o fue escrita por un desarrollador inexperto; otros ven esto como una rápida “ingeniería de producto” que se lanzó y nunca se revisó.

Riesgo de eludir la comprobación

  • Algunos aplauden desactivar JavaScript para continuar, señalando que esto demuestra que solo es cosmético.
  • Otros advierten que es arriesgado: Google podría imponer más tarde la misma regla del lado del servidor y bloquear el dominio o la cuenta con poco margen de recurso.

Soporte, prioridades y desequilibrio de poder de Google

  • Muchos relatan experiencias similares de suspensiones opacas y flujos de soporte inútiles, incluso como clientes de pago de Workspace / Google Cloud.
  • Hay una fuerte sensación de que Google solo brinda soporte significativo a clientes muy grandes; las empresas pequeñas y las personas se sienten desechables.
  • Este episodio refuerza el miedo a confiar infraestructura empresarial central (correo, identidad) a un proveedor que puede cortar el acceso unilateralmente.

Particularidades de dominios/TLD y elecciones “poco convencionales”

  • Varios usuarios describen cómo se rechazaron sus propios dominios (dominios cortos, que empiezan por números, TLD inusuales como .one, .email).
  • Algunos sostienen que este es el costo predecible de usar TLD “raros”; otros responden que Google vende esos dominios y debería gestionarlos correctamente.
  • Hay una discusión paralela sobre los nuevos gTLD con precio premium, la falta de protección de precios y el consejo de preferir TLD tradicionales (.com, .org, .net, ccTLDs).

Alternativas y autoalojamiento

  • Los comentaristas mencionan mudarse a otros proveedores alojados (p. ej., plataformas de correo más pequeñas) o autoalojar el correo como forma de escapar del ecosistema y las políticas de Google.

Soporte generado por IA y distopía de automatización

  • La extraña explicación del soporte (sobre “.web” y “dominios ficticios”) se sospecha ampliamente que fue generada por un LLM; otros advierten contra atribuirlo en exceso a la IA.
  • Surgen preocupaciones más amplias sobre la toma de decisiones automatizada, procesos de apelación kafkianos y proveedores SaaS que usan IA y scripts para controlar el acceso sin rendición de cuentas.