Google Workspace o Microsoft 365 con tu dominio: cuál y cómo configurarlo

Lo que se elige de verdad: cómo trabaja tu equipo

Para recibir y mandar correo con tu dominio, las dos cumplen igual. La diferencia está en todo lo que viene en el paquete y en la rutina de la gente que lo va a usar.

Si tu equipo vive en Excel con macros, planillas compartidas y Outlook de escritorio, Microsoft 365 le cambia menos las costumbres. Si trabaja desde el navegador y el celular, Workspace suele resultar más simple.

Los planes, el espacio por usuario y los precios los fija cada proveedor y cambian seguido: revisalos en su sitio antes de decidir.

La tercera opción: dejar el correo en el hosting

Antes de sumar una suscripción por usuario, fijate si la necesitás. Los planes de hosting de InHosting traen casillas ilimitadas con antispam y antivirus, que comparten el disco del plan y se usan desde el webmail, Outlook, Thunderbird o el celular. Para un equipo chico que necesita correo con su dominio y nada más, alcanza.

Workspace o 365 empiezan a tener sentido cuando querés calendario compartido, documentos colaborativos, videollamadas o casillas muy grandes. Las ventajas y los límites de cada camino están en correo corporativo con tu dominio.

El sitio sigue donde está: qué registros cambian

La zona DNS de tu dominio tiene un registro por servicio. El A dice en qué servidor está el sitio; los MX dicen a qué servidor entregarle el correo. Quien te manda un mensaje consulta solo los MX, y un navegador consulta solo el A.

Por eso podés pasar el correo a Google o a Microsoft con el sitio funcionando en el hosting, sin ventana de mantenimiento y sin que ningún visitante lo note. Lo que hay que cuidar son los mensajes que llegan durante el cambio y el correo que manda el propio sitio.

Los registros se cargan donde está el DNS del dominio. Si usa los DNS que te enviamos al activar el plan, se editan en DirectAdmin, en Administración DNS (DNS Management), y los MX también desde Administrador de correo › Registros MX. En DirectAdmin los nombres van sin el dominio (_dmarc, autodiscover) y los destinos completos terminan en punto (smtp.google.com.): sin ese punto, el panel les pega tu dominio al final.

Los registros de cada plataforma

Copiá los valores de la documentación o del panel de cada proveedor en el momento de configurar. Cambian con los años, y un tutorial viejo es la causa más común de un correo que anda a medias.

La mudanza en orden, sin perder un mensaje

1. Dá de alta en la plataforma nueva todas las direcciones que existen hoy, incluidas las que usás como alias o reenvío. Una dirección que falte rebota apenas cambie el MX.
2. Verificá el dominio con el TXT que te dan Google o Microsoft. Hasta que no quede verificado, no te habilitan el correo.
3. Un día antes, bajá el TTL de los MX a 300 segundos. Así el cambio se ve en minutos y, si algo sale mal, la vuelta atrás también.
4. Copiá el correo viejo por IMAP con la herramienta de cada plataforma: el servicio de migración de datos de la consola de Google, o la migración IMAP del centro de administración de Exchange. El hosting sigue recibiendo mientras tanto.
5. Reemplazá los MX: anotá los del hosting, que son tu vuelta atrás, borralos y cargá los nuevos. En DirectAdmin, destildá en esa misma pantalla la opción de servidor de correo local.
6. En el mismo momento, editá el SPF. No agregues un segundo registro: sumá el include del proveedor nuevo al que ya existe.
7. Activá DKIM desde la consola de Google o desde el portal de Microsoft Defender, y cargá los registros que te muestren.
8. Publicá el DMARC con p=none para empezar a recibir reportes sin bloquear nada.
9. Cuando el correo ya entre por el destino nuevo, repetí la copia IMAP para traer lo que llegó al hosting mientras propagaba. Borrá las casillas viejas una o dos semanas después.

El paso que más se olvida: el correo local de DirectAdmin

DirectAdmin trata cada dominio como de correo local mientras los MX apuntan al propio servidor. Si cambiás los MX y esa opción queda tildada, el servidor sigue entregando en sus casillas todo lo que se genera adentro de él: el formulario de contacto del sitio, los avisos de pedido de la tienda, la recuperación de contraseñas. Esos mensajes nunca salen hacia Google ni hacia Microsoft y parecen perdidos.

Al destildarla, el hosting deja de recibir correo para ese dominio. Casillas, reenvíos, respuestas automáticas y listas quedan en el panel pero sin uso: hay que rehacerlos en la plataforma nueva.

SPF: un único registro que nombre a todos los que envían

El SPF enumera quién puede mandar correo en nombre de tu dominio, y tiene que haber uno solo: con dos registros v=spf1, la validación da error para todos los mensajes. Al mudarte, lo habitual es que el sitio siga en el hosting y mande sus formularios desde ahí, así que el registro tiene que autorizar a los dos. Hay más detalle en SPF, DKIM y DMARC.

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all

• La primera línea es un ejemplo para Workspace y la segunda para 365: va una u otra, nunca las dos. 203.0.113.10 representa la IP de tu hosting.
• DirectAdmin arma el SPF con a, mx y la IP del servidor. Después de la mudanza, mx pasa a señalar a los servidores de entrada de Google o de Microsoft, que no envían tu correo: lo podés sacar. La IP del hosting se queda mientras el sitio mande desde ahí.
• Hay un límite de diez consultas DNS por evaluación. Cada include, a y mx cuenta, y un include puede traer otros adentro. Con el proveedor de correo, una herramienta de boletines y una plataforma de ventas se llega rápido.
• Si el sitio manda sus formularios por SMTP autenticado con una casilla de Workspace o de 365, por ejemplo con un plugin de SMTP en WordPress, la IP del hosting ya no hace falta.

DKIM y DMARC, en ese orden

DKIM firma cada mensaje con una clave de tu dominio. En Google se genera en Apps › Google Workspace › Gmail › Autenticar correo electrónico, con 2048 bits y el prefijo google, y puede tardar hasta 72 horas en estar disponible después de activar Gmail. En Microsoft se activa desde el portal de Defender, en la configuración de autenticación de correo, y pide los dos CNAME. La firma que DirectAdmin usa para el hosting, en x._domainkey, puede quedarse: cada una tiene su nombre y no se pisan.

DMARC le indica al que recibe qué hacer con lo que no pasa SPF ni DKIM, y te manda reportes diarios en XML. Empezá con p=none para mirar sin bloquear. Cuando los reportes muestren que todo tu correo legítimo pasa, subí a p=quarantine y después a p=reject. Desde 2024 Gmail y Yahoo exigen DMARC a quienes envían en volumen, así que postergarlo ya no conviene.

Cómo comprobar que quedó bien

Consultá los registros con dig (en Windows, nslookup). Si el TTL todavía no venció, tu conexión puede mostrar lo viejo; preguntarle a un DNS público te saca la duda.

dig +short MX tudominio.com.ar @8.8.8.8
dig +short TXT tudominio.com.ar @8.8.8.8
dig +short TXT google._domainkey.tudominio.com.ar @8.8.8.8
dig +short CNAME selector1._domainkey.tudominio.com.ar @8.8.8.8
dig +short TXT _dmarc.tudominio.com.ar @8.8.8.8

1. El MX tiene que devolver solo el destino nuevo. Si aparece también el del hosting, parte del correo sigue entrando ahí.
2. Mandá un mensaje desde una casilla de otro dominio, por ejemplo una cuenta personal. Una prueba entre dos casillas del mismo dominio no pasa por los MX y no demuestra nada.
3. Respondé desde la casilla nueva a esa cuenta externa. En Gmail, el menú de tres puntos › Mostrar original tiene que indicar PASS en SPF, DKIM y DMARC.
4. Probá el formulario de contacto del sitio y cualquier aviso automático: son los que fallan sin que nadie se dé cuenta.