Cambio de dominio en Microsoft 365 sin caída: Entra ID y DNS (guía 2025)

Resumen rápido: cambio de dominio sin caída

1. Reduce TTL (MX/SPF/Autodiscover) a 300–600 s con 48–72 h de antelación.
2. Clona la zona DNS en el proveedor destino y valida MX/SPF/DKIM/DMARC y CNAMEs de Entra/Intune.
3. Prepara coexistencia (conectores A↔B o dual delivery) para absorber la propagación.
4. Corta rápido: quita el dominio en A, verifica y agrega en B, actualiza MX/SPF/DKIM/DMARC.
5. Asigna UPN/SMTP, restaura alias y verifica fin a fin (correo, calendarios, Teams, SharePoint, Intune).

Escenarios de cambio o migración de dominio

• Cambio de proveedor DNS (p. ej., de GoDaddy a Cloudflare o Azure DNS) sin tocar el tenant.
• Migración entre tenants (fusiones, escisiones): retirar el dominio del Tenant A y agregarlo en el Tenant B con coexistencia temporal.
• Renombrado de identidad: cambiar User Principal Name (UPN) y Primary SMTP manteniendo alias históricos.
• Consolidación multi-dominio: reducir dominios corporativos sin perder reputación ni entregabilidad.

Recuerda: un dominio personalizado solo puede estar asociado a un tenant a la vez. Por eso el orden y la coexistencia marcan la diferencia.

Plan sin caída: estrategia y tácticas clave

1. Inventario de dependencias: dominios, registros DNS (MX, SPF, DKIM, DMARC, Autodiscover), apps con SSO, conectores de Exchange, reenvíos, buzones compartidos/recursos, sistemas terceros (CRM/marketing/SIP).
2. Reducir TTL: baja TTL de MX/Autodiscover/SPF a 300–600 s, al menos 48–72 h antes del cambio.
3. Pre-staging DNS en destino: clona la zona, crea CNAMEs DKIM y deja p=none en DMARC para observar reportes.
4. Coexistencia: conectores A↔B o dual delivery para que ningún correo se pierda durante la propagación.
5. Ventana de cambio: hora valle, congelación de cambios, monitorización (colas de correo, NDRs, latencia).
6. Rollback: plan documentado (restaurar NS/MX/UPN/SMTP y conectores) con responsables y tiempos.

Plan temporal recomendado (runbook)

T−72 h

• Reducir TTL de MX/SPF/Autodiscover a 300–600 s.
• Inventariar objetos con el dominio (usuarios, grupos, buzones, apps Entra, reglas).

T−24 h

• Clonar zona DNS en destino y validar registros (MX/SPF/DKIM/DMARC, CNAMEs Entra/Intune).
• Configurar conectores temporales y reglas de reenvío (coexistencia).

T−0 (ventana de cambio)

• Quitar dominio en Tenant A ⇒ Verificar y agregar en Tenant B.
• Actualizar MX/SPF y habilitar DKIM; DMARC en p=none.
• Asignar UPN/SMTP en B y restaurar alias históricos.

T+24 h

• Revisar colas/NDRs, calendarios y reuniones.
• Subir TTL a valores normales; retirar conectores temporales.

Pre-flight checks y scripts de validación

Exchange Online: objetos que usan el dominio

Connect-ExchangeOnline
$domain = "contoso.com"
Get-Recipient -ResultSize Unlimited | Where-Object {
  $_.EmailAddresses -match $domain -or $_.PrimarySmtpAddress -match $domain
} | Select Name,RecipientType,PrimarySmtpAddress | Export-Csv .\recipients-$domain.csv -NoTypeInformation

Entra ID: dominios y UPN

Connect-MgGraph -Scopes "Domain.Read.All","User.Read.All"
Get-MgDomain | Select Id,IsVerified,IsDefault,IsInitial
Get-MgUser -All | Select Id,UserPrincipalName | Export-Csv .\upn-inventory.csv -NoTypeInformation

DKIM: habilitar y comprobar (Exchange Online)

Connect-ExchangeOnline
$domain="contoso.com"
Set-DkimSigningConfig -Identity $domain -Enabled $true
Get-DkimSigningConfig -Identity $domain | fl Domain,Enabled,Selector1CNAME,Selector2CNAME

Plantillas SPF/DMARC

SPF:  v=spf1 include:spf.protection.outlook.com include:mailgun.org include:sendgrid.net -all
DMARC (inicial): v=DMARC1; p=none; rua=mailto:dmarc@contoso.com; ruf=mailto:dmarc-aforensics@contoso.com; fo=1
DMARC (endurecido): v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@contoso.com

Cambio de proveedor DNS sin caída (paso a paso)

1. Exporta la zona DNS actual (A/AAAA, CNAME, TXT, MX, SRV, CAA).
2. Replica la zona en el nuevo proveedor (incluye autodiscover, enterpriseregistration, enterpriseenrollment si usas Entra/Intune).
3. Baja TTL de registros críticos a 300–600 s y espera una vida completa de caché.
4. Valida que MX/SPF/DKIM/DMARC coinciden en ambos proveedores antes de cambiar nameservers.
5. Cambia los NS en el registrador y monitoriza la resolución global con nslookup/dig.
6. Congela 24 h sin cambios; después sube TTL a 1–4 h.

Si migras a Azure DNS, considera Traffic Manager o Front Door y registros alias para resiliencia.

Migración de dominio entre tenants (A → B) con continuidad

Ruta segura: limpiar uso en A → quitar dominio en A → verificar y agregar en B → actualizar MX/SPF/DKIM/DMARC → asignar UPN/SMTP.

Antes del corte

1. Inventario en A: usuarios con ese UPN, grupos, buzones compartidos/recursos, direcciones proxy, apps Entra, políticas de Acceso Condicional.
2. Normaliza UPN en A a un dominio temporal (p. ej., contoso.onmicrosoft.com) y deja el dominio anterior como alias SMTP.
3. Quita el dominio de todos los objetos en A. Si sigue en uso, el portal no permitirá eliminarlo.
4. Prepara B: crea usuarios/buzones con UPN temporal, asigna licencias, configura reglas/conectores si habrá coexistencia.
5. Baja TTL de MX/Autodiscover y espera propagación.

Corte

1. Quita el dominio en A (Centro de administración → Configuración → Dominios → Quitar).
2. Añádelo y verifícalo en B con el registro TXT; el asistente propone MX/CNAME/SPF.
3. Actualiza MX a *.mail.protection.outlook.com de B y ajusta SPF (include:spf.protection.outlook.com + remitentes externos).
4. Habilita DKIM en B (CNAMEs selector1/selector2); deja DMARC en p=none unos días.
5. Asigna el dominio en B como UPN y Primary SMTP y restaura alias históricos.

Después del corte

• Revisa colas/NDRs, reemite invitaciones críticas si fuese necesario y sube TTL a valores normales.
• Retira conectores temporales cuando ya no haya tráfico inter-tenant.

Cambio de UPN y direcciones de correo sin interrumpir el acceso

Mejor práctica: alias primero, primario después. Crea la nueva dirección como alias en Exchange Online, valida entregas y, cuando esté estable, promuévela a primaria. Para UPN, sincroniza el cambio en Entra ID y verifica aplicaciones críticas (SSO, Intune, SharePoint, apps con reply URL).

Script de ejemplo (Exchange Online)

Connect-ExchangeOnline
Import-Csv .\primary-change.csv | ForEach-Object {
  $upn = $_.UserPrincipalName
  $new = $_.NewPrimarySmtpAddress
  Set-Mailbox -Identity $upn -EmailAddresses @{Add=$new}
  Set-Mailbox -Identity $upn -PrimarySmtpAddress $new
}

Valida apps que dependan del UPN (SSO con terceros, MDM, apps registradas en Entra ID) para evitar sesiones rotas.

Registros DNS imprescindibles (MX, SPF, DKIM, DMARC, Autodiscover, Intune)

Continuidad del correo: conectores, reglas y dual delivery

• Dual delivery: apunta MX a B y crea conector B→A para buzones aún activos en A (temporal).
• Reenvíos/transport rules: red de seguridad si emisores externos siguen usando el dominio anterior.
• Verificación: pruebas E2E de envío/recepción, NDRs, Reply-To, calendarios e invitaciones.

Impacto en Teams, SharePoint/OneDrive e Intune

• Teams: el nombre visible puede no cambiar inmediatamente tras modificar SMTP; revisa invitaciones y pestañas con URLs absolutas.
• SharePoint/OneDrive: si renombraste UPN, revisa permisos y vínculos compartidos; si cambiaste solo SMTP, el impacto suele ser mínimo.
• Intune: con enterpriseregistration/enterpriseenrollment correctos, las inscripciones se mantienen; valida perfiles de correo/VPN/Wi-Fi.

Seguridad y cumplimiento (Acceso Condicional, MFA, DKIM/DMARC)

• MFA y Acceso Condicional: revisa políticas basadas en UPN o grupos; ajusta exclusiones para la ventana de cambio.
• Aplicaciones Entra: actualiza reply URLs/redirect URIs que incluyan el dominio antiguo; vuelve a consentir si es necesario.
• DKIM/DMARC: habilita DKIM por dominio y eleva DMARC de p=none a quarantine y, luego, a reject con datos de telemetría.
• Auditoría: monitoriza autenticaciones anómalas, spoofing y entregabilidad.

KPIs y verificación post-corte

• NDRs ≤ 0,2% del volumen diario.
• Entrega aceptada por EOP ≥ 99,5%.
• Quejas de usuario (acceso/Teams/SharePoint) ≤ 0,5% de usuarios activos.
• DMARC: de p=none a quarantine en ≤ 14 días.

NDRs frecuentes y cómo resolverlos

Checklist imprimible (Go-Live)

Errores frecuentes (y cómo evitarlos)

• No bajar TTL con antelación: la propagación lenta multiplica NDRs.
• Quitar el dominio sin “limpiar” objetos: el portal no permite eliminarlo si algún UPN/Primary SMTP lo usa.
• Olvidar DKIM/DMARC: empeora la entregabilidad y aumenta el spoofing.
• Dejar conectores abiertos: ciérralos tras estabilizar la migración.
• No probar calendarios/reuniones: invitados externos pueden requerir reemisión.

Preguntas frecuentes

Enlaces oficiales

• Agregar y verificar un dominio en Microsoft 365
• Registros DNS de Microsoft 365 (MX, SPF, CNAME, SRV)
• Configurar DKIM en Microsoft 365
• Implementar DMARC y buenas prácticas
• Conectores de Exchange Online (coexistencia)
• Cambiar nombre de usuario y dirección de correo
• Inscripción de dispositivos en Intune

Conclusión y siguientes pasos

Un cambio o migración de dominio en Microsoft 365 sin caída es totalmente viable con planificación, coexistencia y verificación rigurosas. Baja TTL, clona DNS, limpia dependencias en Entra/Exchange, corta rápido, valida MX/SPF/DKIM/DMARC y revisa Teams/SharePoint/Intune. Si quieres garantizar el éxito a la primera, podemos acompañarte en todo el proceso.