Migración de correo a Microsoft 365

Síntoma y contexto

Migrar correo a Office 365 o Microsoft 365 parece una tarea de copiar registros DNS, pero el riesgo real está en el corte. Si el MX cambia antes de crear buzones, algunos mensajes rebotan. Si quedan MX antiguos, parte del correo entra en el proveedor anterior. Si SPF, DKIM o DMARC se publican sin alinear, los mensajes salen pero acaban en spam o son rechazados por destinatarios estrictos.

La migración debe separar preparación y activación. Primero se verifican dominio, buzones, aliases, grupos, reenvíos y clientes que envían en nombre del dominio. Después se bajan TTL y se preparan registros. Solo al final se cambia el MX para que el correo entrante llegue a Exchange Online. Durante unas horas o días puede haber coexistencia: algunos remitentes siguen usando caché DNS antigua y entregan al proveedor anterior.

Esta guía cubre dominios pequeños y medianos que pasan de hosting con correo, Google Workspace, Zoho, IMAP genérico o proveedor local a Microsoft 365. No requiere compartir contraseñas de administrador. Para diagnosticar correo que ya no llega, usa correo no llega. Si el problema posterior es reputación o bandeja de spam, consulta correo va a spam.

Causas probables

1. MX cambiado antes de crear buzones. Exchange Online recibe mensajes para usuarios que aún no existen y devuelve rebotes tipo recipient not found.
2. MX antiguos coexistiendo con Microsoft. Registros de hosting, Google o Zoho con prioridad todavía activa hacen que algunos remitentes entreguen en el sitio equivocado.
3. TTL alto antes del corte. Si el TTL era de varias horas o días, muchos servidores tardan en ver el nuevo MX aunque el panel ya muestre el valor correcto.
4. SPF duplicado. Publicar dos TXT con v=spf1 invalida SPF. Debe existir un solo registro que incluya Microsoft y otros remitentes legítimos.
5. DKIM sin activar en Microsoft 365. Añadir CNAME no basta. Microsoft debe detectar los selectores y luego se habilita DKIM en el dominio.
6. DMARC estricto demasiado pronto. Un p=reject antes de alinear SPF y DKIM puede bloquear formularios web, facturación o CRM.
7. Autodiscover mal configurado. Outlook puede pedir credenciales repetidamente o crear perfiles contra el proveedor anterior si el CNAME no apunta a Microsoft.
8. Servicios externos olvidados. Webs, newsletters, facturación, ERP o tickets pueden enviar desde el dominio y quedar fuera de SPF o DKIM tras el cambio.

Checklist copiable

MIGRACIÓN CORREO MICROSOFT 365 - [dominio]
Fecha prevista de corte: ___________  Hora (zona): ___________

1. INVENTARIO
   [ ] Buzones principales listados
   [ ] Aliases listados
   [ ] Grupos y buzones compartidos listados
   [ ] Reenvíos revisados
   [ ] Servicios que envían correo: web / CRM / facturación / newsletter

2. PREPARACIÓN MICROSOFT 365
   [ ] Dominio verificado por TXT
   [ ] Licencias asignadas
   [ ] Buzones creados
   [ ] Migración IMAP o importación planificada
   [ ] Autodiscover preparado

3. DNS ANTES DEL CORTE
   TTL actual MX: ___________
   TTL bajado a: ___________
   [ ] Copia de registros antiguos guardada
   [ ] MX nuevo de Microsoft apuntado y listo

4. AUTENTICACIÓN
   SPF actual: ___________
   SPF previsto: ___________
   [ ] DKIM selector1 publicado
   [ ] DKIM selector2 publicado
   [ ] DMARC en p=none o política revisada

5. PRUEBAS TRAS CORTE
   [ ] Gmail a dominio
   [ ] Outlook.com a dominio
   [ ] Dominio a Gmail
   [ ] Dominio a Outlook.com
   [ ] Formulario web envía correctamente

6. NO ENVIAR
   [ ] Sin contraseña de administrador Microsoft
   [ ] Sin contraseña de buzones
   [ ] Sin tokens de DNS ni exports con claves

Qué capturar antes de escribir

Antes de pedir ayuda, reúne el dominio, proveedor DNS, proveedor de correo antiguo, proveedor nuevo y fecha prevista de corte. Captura los registros DNS actuales, especialmente MX y TXT. Guarda también una copia de aliases, grupos y reenvíos, porque muchos cortes fallan no por el MX, sino por direcciones secundarias olvidadas.

Del Centro de administración de Microsoft 365, captura la pantalla de dominios donde se ve si el dominio está verificado y qué registros recomienda Microsoft. No compartas contraseñas de administrador, contraseñas de buzones ni códigos MFA. Si alguien necesita revisar contigo, se puede trabajar con capturas, pantalla compartida aprobada por ti o indicaciones paso a paso, no con secretos enviados por formulario.

Si hay correo histórico que migrar, anota el método: migración IMAP, importación PST, herramienta de proveedor o solo buzones nuevos desde cero. No mezcles el corte MX con una migración masiva sin plan de vuelta. El correo nuevo y el histórico son tareas relacionadas, pero no idénticas.

Comandos y paneles útiles

Los registros exactos deben salir del panel de Microsoft para tu tenant, pero las comprobaciones públicas se pueden hacer con dig:

# MX actual del dominio
dig MX tudominio.com +short

# SPF y otros TXT en raíz
dig TXT tudominio.com +short

# DMARC
dig TXT _dmarc.tudominio.com +short

# DKIM de Microsoft 365, cambia el dominio por el real
dig CNAME selector1._domainkey.tudominio.com +short
dig CNAME selector2._domainkey.tudominio.com +short

# Autodiscover para Outlook
dig CNAME autodiscover.tudominio.com +short

Paneles principales: Microsoft 365 Admin Center en Configuración, Dominios; Exchange Admin Center para flujo de correo y DKIM; panel DNS del registrador o Cloudflare; panel del proveedor antiguo para dejar buzones accesibles durante la coexistencia. Si el DNS está en Cloudflare, los registros de correo deben estar en modo DNS only cuando aplique. No se proxifican MX.

Pasos por escenario

Preparación antes del corte MX

Verifica el dominio en Microsoft mediante el TXT que pide el asistente. Crea buzones, aliases y grupos antes de cambiar el MX. Baja el TTL de MX y TXT con suficiente antelación, por ejemplo el día anterior si tu panel lo permite. Guarda una captura de los valores antiguos para poder volver atrás. Revisa que los usuarios saben qué cliente usar después del cambio y que Outlook podrá descubrir Exchange Online con autodiscover.

Cambio de MX a Microsoft 365

En el momento del corte, elimina MX antiguos y deja solo el MX de Microsoft con la prioridad recomendada. No mantengas el MX del hosting como respaldo si el hosting ya no tendrá buzones sincronizados: ese respaldo puede recibir correo que nadie mira. Después comprueba con dig MX desde varios resolvers y envía pruebas desde cuentas externas. Durante la propagación, mantén acceso al proveedor antiguo por si entran mensajes allí.

SPF, DKIM y DMARC

Debe haber un solo registro SPF en la raíz del dominio. Para Microsoft suele incluir include:spf.protection.outlook.com, además de los servicios legítimos que envían por ti. Evita acumular proveedores antiguos si ya no envían. DKIM en Microsoft usa dos CNAME, selector1 y selector2, y después se activa en Exchange. DMARC conviene empezar con p=none mientras revisas informes y pruebas, y endurecer solo cuando todo el correo legítimo pase autenticación.

Coexistencia con proveedor anterior

Durante un tiempo, algunos remitentes pueden entregar al MX antiguo por caché DNS. Por eso conviene no cancelar el proveedor anterior el mismo día del corte. Revisa bandejas antiguas durante la ventana de propagación y evita crear reenvíos improvisados que rompan SPF. Si necesitas coexistencia larga entre dos plataformas, documenta qué dominio acepta entrada, qué servidor envía y dónde viven aliases y grupos.

Formularios web y aplicaciones que envían correo

Una web en WordPress, un CRM o una herramienta de facturación puede seguir enviando desde el hosting. Si ese servidor ya no está en SPF, los mensajes pueden ir a spam o rebotar. Decide si esos envíos saldrán por SMTP autenticado de Microsoft, por un servicio transaccional o por el hosting. No pegues contraseñas SMTP en el formulario: describe el método y comparte solo mensajes de error censurados.

Outlook pide contraseña o conecta al buzón antiguo

Revisa autodiscover, perfiles antiguos y caché de credenciales. Outlook puede mantener un perfil conectado al proveedor anterior aunque el MX ya apunte a Microsoft. Crea un perfil nuevo para probar antes de tocar todos los equipos. Si el dominio también tiene registros antiguos de autodiscover en el hosting, elimínalos o alinéelos con Microsoft según el asistente.

Cuándo escalar

Escala usando el formulario con categoría Dominio, DNS o correo si el MX ya apunta a Microsoft pero no llega correo, si hay coexistencia confusa con el proveedor anterior, si SPF tiene demasiados includes, si DKIM no valida o si DMARC está bloqueando mensajes legítimos. Adjunta la checklist, capturas de DNS, dominio verificado en Microsoft y ejemplos de rebote sin datos personales innecesarios.

Enlaces relacionados: El correo no llega, El correo va a spam, El dominio no resuelve.