Cómo configurar Google Workspace paso a paso
Guía real de migración: qué hace el cliente, qué hacemos nosotros, y los tres errores que aparecen siempre y que ninguna guía oficial menciona.
Por Cristian Rebolledo — MasterNet Chile. Llevo 20 años desarrollando sitios web y administrando el servidor donde alojo cerca de 150 dominios de clientes: municipalidades, colegios y empresas. Esta guía está escrita desde migraciones que hago yo mismo, no desde la documentación.
Google Workspace permite usar Gmail, Drive, Calendar y Meet con direcciones propias del tipo contacto@tuempresa.cl. El correo deja de estar en el servidor de hosting y pasa a los servidores de Google.
La documentación oficial de Google explica bien los pasos aislados, pero no cuenta lo que pasa cuando el dominio ya tiene correo funcionando en otro servidor. Ahí es donde se cae el proceso. Esta guía cubre las dos cosas.
El último caso que me tocó fue una clínica veterinaria de Concepción. El proceso completo tomó unas cuatro horas, y tres de esas se fueron en problemas que no estaban en ninguna documentación. Los dejo todos anotados más abajo.
Antes de los pasos conviene entender qué se está moviendo. Lo único que cambia es el recorrido que hace un correo entrante. El sitio web no se toca.
| Plan | Por usuario al mes | Almacenamiento |
|---|---|---|
| Business Starter | USD 7 con pago anual | 30 GB |
| Business Standard | USD 14 con pago anual | 2 TB |
| Business Plus | USD 22 con pago anual | 5 TB |
Precios por usuario, antes de impuestos. Sin compromiso anual suben alrededor de un 20%. El cobro es automático todos los meses. Valores actualizados en la página de precios de Google Workspace.
admin@tuempresa.cl.
Error 1: "Los miembros del grupo familiar no pueden usar direcciones de correo personalizadas".
Me apareció apenas la clienta entró con su Gmail de siempre. Pasa cuando esa cuenta pertenece a un grupo familiar de Google, por ejemplo por un plan Google One o YouTube Premium compartido.
Google ofrece el botón "abandonar el grupo familiar". No lo usen. Si sale del grupo, no puede entrar a otro durante 12 meses y pierde el almacenamiento y las suscripciones compartidas. La solución es abrir una ventana de incógnito y hacer el registro sin esa sesión activa.
Error 2: la tarjeta que se ingresa queda cobrando para siempre.
El perfil de pago queda asociado a la cuenta de Google con la que se hizo el registro, y el cobro es automático y mensual. Si la pone el proveedor de hosting o un tercero, queda pagando indefinidamente una suscripción a nombre de otra empresa.
El campo "Titular de la tarjeta" además se autocompleta con el nombre de quien está logueado. Hay que corregirlo al nombre que aparece en la tarjeta o el cobro se rechaza.
Google pide el régimen fiscal y si la empresa está exenta del Impuesto Adicional. En la ayuda oficial sobre impuestos por región está el detalle de cada campo.
Los dos impuestos son excluyentes: si el pago queda afecto a impuesto adicional, no lleva IVA. Si se declara exenta, el pago queda afecto a IVA y la empresa debe emitir factura de compra y retener el IVA, que después usa como crédito fiscal. Confirmar con el contador antes de marcar la opción.
Google entrega un código que hay que publicar en la zona DNS para demostrar que la empresa es dueña del dominio:
google-site-verification=xxxxxxxxLa gestión de dominios queda en admin.google.com/ac/domains/manage.
Hay que eliminar todos los MX existentes y dejar solo el de Google:
| Tipo | Nombre | Prioridad | Destino | TTL |
|---|---|---|---|---|
| MX | dominio raíz | 1 | smtp.google.com. |
300 |
Google unificó la configuración en un solo registro. Las guías antiguas que muestran cinco MX con aspmx.l.google.com y sus alternativos siguen funcionando, pero ya no hacen falta. Los valores vigentes están en la ayuda oficial de registros MX.
Bajar el TTL a 300 segundos antes del cambio acorta mucho la propagación. Si el registro anterior tenía TTL de 14400, los servidores externos lo mantienen cacheado hasta 4 horas.
Error 3: el enrutamiento de correo del servidor. Este es el que más tiempo hace perder.
No basta con cambiar el MX. Si el dominio sigue marcado como local en el servidor de hosting, el programa de correo entrega los mensajes internamente y nunca consulta los registros MX. El correo desaparece: no llega a Gmail y tampoco rebota.
En servidores cPanel hay que dejar el dominio como servidor de intercambio de correo remoto. Y hay que revisarlo en WHM, no solo en cPanel, porque a veces el cambio desde cPanel no saca el dominio de la lista de dominios locales.
Es la causa número uno de "cambié el MX y el correo no llega".
Sin estos tres registros, el correo que envíe la empresa puede terminar en spam. Google aumentó bastante la exigencia: los mensajes que no pasan SPF ni DKIM reciben límites de frecuencia y errores de entrega documentados en la lista de errores SMTP de Gmail.
Declara qué servidores pueden enviar correo en nombre del dominio. Solo puede existir un registro SPF:
v=spf1 include:_spf.google.com ~all
Detalle que se escapa seguido: si el sitio web manda correos por formularios de contacto desde el servidor de hosting, esos correos van a fallar SPF. Hay que agregar la IP del servidor:
v=spf1 include:_spf.google.com ip4:IP.DEL.SERVIDOR ~all
O bien configurar el sitio para que envíe autenticado contra Google. Referencia: definir el registro SPF.
Firma digitalmente cada correo saliente. La clave se genera dentro de la consola de administración, y este es el link directo, que cuesta encontrar navegando por los menús:
admin.google.com/ac/apps/gmail/authenticateemail
Ahí se genera un registro de 2048 bits y se publica en el DNS:
google._domainkeyv=DKIM1; k=rsa; p=...Después hay que volver a esa misma pantalla y presionar Iniciar autenticación. Si no se hace ese último clic, el DKIM queda publicado pero inactivo.
Si el dominio tenía correo en un servidor cPanel, va a existir un DKIM anterior en default._domainkey. Ese se elimina. Referencia: configurar DKIM.
Indica qué hacer con los correos que no pasan SPF ni DKIM. Este registro no se configura en Google, se publica directo en el DNS:
_dmarcv=DMARC1; p=none; rua=mailto:contacto@tuempresa.clSe parte con la política en none para observar sin bloquear, y después de unas semanas se endurece a quarantine o reject.
La lista de verificación oficial de Gmail para administradores ordena estos mismos pasos desde el lado de Google.
¿Prefieres no tocar el DNS? Si el dominio está alojado con nosotros, los pasos 2, 3, 4 y 6 los hacemos nosotros sin costo adicional dentro del servicio de hosting. Escríbenos.
En admin.google.com/ac/users se crea una cuenta por persona. Cada usuario paga licencia.
Para direcciones genéricas que lee alguien que ya tiene cuenta, conviene usar alias en vez de usuarios nuevos. Los alias no tienen costo. Por ejemplo, ventas@ puede ser alias de la cuenta de la persona encargada.
Importante: si una dirección no existe como usuario ni como alias, Google rechaza los correos dirigidos a ella. Es el segundo motivo más común de "no me llegan los correos" después del enrutamiento.
Los correos antiguos quedan en el servidor de hosting, no se transfieren solos. Dos caminos:
Recién después de verificar la migración se eliminan las casillas del servidor antiguo. Nosotros además dejamos un respaldo antes de borrar nada.
Los programas de correo siguen apuntando al servidor antiguo y dejan de recibir mensajes nuevos. Cada persona debe:
Si el servidor antiguo tenía un subdominio tipo mail.tuempresa.cl, ese sigue apuntando al hosting. Mientras no se reconfiguren los dispositivos, van a seguir conectándose ahí y no van a ver nada nuevo.
smtp.google.com.Sigue funcionando sin cambios, es una cuenta aparte con su propio acceso. Lo que conviene es poner un reenvío automático desde esa cuenta hacia la nueva dirección del dominio, y avisar a clientes y proveedores el cambio.
No. Queda en el servidor de hosting hasta que se migre y se eliminen las casillas. No hay que borrar nada antes de verificar.
Entre 15 minutos y 4 horas según el TTL que tenían los registros anteriores. Durante ese rato algunos correos pueden llegar al servidor antiguo y otros a Google.
No. El sitio sigue igual en el mismo servidor. Solo se traslada el correo.
Sí, restituyendo los MX originales. Pero el correo recibido en Google durante ese tiempo queda allá y hay que migrarlo de vuelta.
Depende del uso. Para una empresa de pocas casillas que solo necesita recibir y enviar, el correo del hosting cumple y va incluido en el plan. Google Workspace conviene cuando se necesita Drive compartido, Meet, calendarios de equipo, acceso desde varios dispositivos sin problemas de sincronización, o cuando el volumen de correo saliente es alto y la entregabilidad es crítica. Lo conversamos según el caso.
| Etapa | Responsable |
|---|---|
| Contratación y pago | La empresa |
| Verificación del dominio | Soporte técnico |
| Registros MX | Soporte técnico |
| SPF, DKIM y DMARC | Soporte técnico |
| Enrutamiento remoto en el servidor | Soporte técnico |
| Creación de usuarios y alias | La empresa |
| Migración del correo antiguo | Soporte técnico |
| Reconfiguración de dispositivos | Cada usuario |
En MasterNet Chile administramos el dominio, los registros DNS y la migración completa del correo. Tú contratas el plan y del resto nos encargamos nosotros. Trabajamos con empresas, municipalidades y colegios en todo Chile.
Solicitar asesoría