Mover el correo a Google Workspace o Microsoft 365

Qué es un MX y por qué el sitio no se entera

Tu dominio no tiene un solo destino: tiene uno por tipo de servicio. El registro A dice en qué IP está el sitio. Los registros MX dicen a qué servidor entregarle el correo. Son entradas distintas de la misma zona DNS y no se miran entre ellas.

Cuando alguien escribe tudominio.com.ar en el navegador, su equipo consulta el registro A; cuando te manda un correo, consulta los MX. Cambiar los MX no modifica el A, así que el sitio sigue donde estaba y la mudanza se hace sin ventana de mantenimiento.

El orden que no pierde mensajes

1. Creá las casillas en el proveedor nuevo antes de tocar nada. Cada dirección que hoy existe tiene que existir allá: una que falte rebota apenas cambien los MX.
2. Verificá el dominio en el panel de Google o de Microsoft. Es un registro TXT que te dan ellos y se carga en "Administración DNS" (DNS Management). Hasta que no lo verifiques no te habilitan el correo.
3. Bajá el TTL de la zona a 300 segundos, al menos un día antes. Así el cambio propaga en minutos y podés volver atrás rápido.
4. Sincronizá el correo viejo hacia el nuevo. Las dos plataformas migran por IMAP con el servidor viejo todavía funcionando.
5. Cambiá los MX y destildá la entrega local, en la misma pantalla. Es el momento del cambio real.
6. Ajustá el SPF en el mismo rato. Si lo dejás para después, lo que mande el proveedor nuevo sale sin autorizar.
7. Mandá una prueba desde una casilla de afuera y confirmá que aparece en la bandeja nueva. Hasta que no aparezca, no avises a nadie.
8. Volvé a sincronizar cuando ya entre todo por el destino nuevo: esa pasada toma lo que llegó al servidor viejo mientras propagaba. Borrá las casillas viejas recién una o dos semanas después.

De dónde salen los valores

Los nombres y las prioridades los publica cada proveedor y cambian con el tiempo: copiarlos de un tutorial viejo es la forma más común de que el correo quede a medio andar.

Google Workspace hoy publica un único registro MX con prioridad 1, y aclara que cualquier cuenta puede usar ese valor aunque tenga cargado el juego viejo de cinco registros. El valor exacto está en su ayuda oficial, en la página de configuración de registros MX.

El de Microsoft 365 incluye una parte generada para tu dominio, así que no es el mismo para todos: sale del centro de administración de Microsoft 365, en la sección de dominios. No hay forma de deducirlo, y la prioridad que recomiendan es más baja que la de cualquier otro MX que tengas.

Cambiar los registros en el panel

1. Entrá al panel y abrí "Administrador de correo" (E-Mail Manager), y ahí "Registros MX" (MX Records). Vas a ver los MX actuales, que normalmente apuntan al propio servidor de hosting: anotalos con su prioridad antes de borrarlos, porque son tu vuelta atrás.
2. Tildá los registros que ya están y borralos. La lista tiene que quedar vacía: si quedan los viejos mezclados con los nuevos, una parte del correo sigue entrando al hosting y la otra al proveedor nuevo.
3. Escribí el primer destino terminado en punto. Sin el punto final, el panel lo interpreta como un subdominio tuyo y arma un destino que no existe.
4. Elegí la prioridad en la lista desplegable, la que indique el proveedor. El número más bajo se intenta primero.
5. Hacé clic en "Agregar" (Add) y repetí por cada destino. Cada registro aparece en la tabla apenas lo agregás.
6. Destildá la opción que indica que este servidor maneja el correo del dominio y guardá. Es el paso que más se olvida: si queda tildada, el servidor entrega en las casillas locales y nunca manda los mensajes afuera.
7. Revisá la lista: tiene que mostrar solamente los destinos nuevos, con las prioridades que cargaste.

El SPF hay que tocarlo sí o sí

Los MX dicen quién recibe; el SPF dice quién puede enviar, y es un registro distinto que no se actualiza solo. Si lo dejás como estaba, vas a recibir bien en la plataforma nueva pero lo que mandes desde ahí sale sin autorización del dominio. Es un registro TXT y tiene que haber uno solo: el error clásico al mudarse es agregar un segundo y dejar el viejo, y con dos registros la validación falla entera.

• Para Google Workspace, la documentación oficial publica v=spf1 include:_spf.google.com ~all.
• Para Microsoft 365, la documentación de Microsoft publica v=spf1 include:spf.protection.outlook.com -all cuando se usa solo Exchange Online.
• Si el sitio sigue en el hosting y manda correo —formularios, avisos de una tienda, recuperación de contraseña—, ese origen también va dentro del mismo registro. Es lo que provoca que los mensajes del formulario dejen de llegar justo después de la mudanza.
• Ojo con el límite de diez consultas de DNS del SPF: sumando el proveedor nuevo, el hosting y un servicio de boletines se llega más rápido de lo que parece, y pasado el límite la validación falla.
• La firma DKIM se activa aparte, en el panel del proveedor nuevo. Los MX no la traen incluida.

Cuánto tarda y cómo verificar que quedó

La documentación de DirectAdmin es explícita en que un cambio de DNS puede verse en unas horas pero el promedio va de 24 a 72 horas, y Google indica el mismo techo de 72 horas para sus MX nuevos. Durante esa ventana el correo puede entrar a cualquiera de los dos destinos según qué servidor haya consultado cada remitente: no es un error, es la propagación.

1. Consultá los MX de tu dominio con una herramienta de consulta DNS pública y confirmá que devuelve solo los destinos nuevos.
2. Mandá un mensaje desde una casilla de otro dominio. Un envío entre dos casillas del mismo dominio no sirve como prueba: puede resolverse internamente sin pasar por los MX.
3. Respondé desde la casilla nueva hacia afuera y revisá en el mensaje recibido que el SPF figure como aprobado.
4. Confirmá que el correo dejó de entrar en el webmail del hosting: mientras siga entrando algo ahí, la mudanza no terminó.
5. Probá los envíos automáticos del sitio, que son los que fallan en silencio: formulario, aviso de pedido, restablecimiento de contraseña.