Mover un dominio de Microsoft 365 entre tenants: guía completa para liberar, cambiar y configurar el dominio sin improvisar
El movimiento de un dominio entre tenants de Microsoft 365 es uno de los momentos más delicados de una migración tenant-to-tenant. No porque cambiar un registro DNS sea especialmente complejo, sino porque un dominio corporativo puede estar relacionado al mismo tiempo con el inicio de sesión de los usuarios, Exchange Online, aliases, grupos, aplicaciones, dispositivos y sistemas externos.
Un dominio como empresa.com puede ser el UPN de cientos de usuarios, la dirección SMTP de buzones y grupos, el dominio desde el que envían aplicaciones empresariales, la identidad que utiliza un proveedor para SSO y, al mismo tiempo, el dominio cuyos registros MX, SPF, DKIM y DMARC determinan cómo se entrega y autentica el correo.
Por eso, durante una migración tenant to tenant de Microsoft 365, el dominio no debería tratarse como una tarea administrativa aislada. Debe considerarse una fase propia del proyecto, con inventario, dependencias, preparación del tenant origen, preparación del tenant destino, ventana de cutover y validaciones claramente definidas.
En esta guía explicamos cómo liberar un dominio de un tenant Microsoft 365 y moverlo a otro, qué objetos pueden impedir su eliminación, qué ocurre con UPN y correo, cómo preparar DNS, qué hacer con SPF, DKIM y DMARC, qué cambia en entornos híbridos y qué errores suelen bloquear el cutover.
Lo esencial antes de empezar
| Pregunta | Respuesta corta |
|---|---|
| ¿Puede estar el mismo dominio en dos tenants? | El mismo dominio personalizado exacto no puede estar verificado simultáneamente en dos tenants Microsoft Entra. |
| ¿Puedo preparar el tenant destino antes? | Sí. Usuarios, licencias, workloads y configuraciones pueden prepararse usando dominios temporales, normalmente onmicrosoft.com. |
| ¿Qué bloquea la eliminación? | Usuarios, administradores, mailboxes, grupos, Teams, contactos, proxy addresses y determinadas aplicaciones que todavía referencian el dominio. |
| ¿Hay que cambiar el MX inmediatamente? | No. El momento del cambio depende de la estrategia de mail flow y debe coordinarse con la preparación de Exchange en destino. |
| ¿Puedo reutilizar el DKIM del tenant origen? | No conviene. Los CNAME necesarios deben obtenerse del tenant destino una vez que el dominio esté disponible allí. |
| ¿Cuánto tarda? | La liberación puede completarse rápidamente si no existen referencias, pero Microsoft indica que con muchas dependencias puede tardar varias horas e incluso hasta un día. |
¿Vas a mover un dominio entre tenants?
El mejor momento para comprobar las dependencias no es durante el cutover. Un assessment previo permite localizar usuarios, grupos, aliases, aplicaciones y servicios que todavía utilizan el dominio antes de iniciar la ventana de cambio.
Revisar mi dominio antes de la migraciónÍndice
- Qué significa mover un dominio entre tenants
- Mover el dominio no es transferir el registrador ni el DNS
- La regla principal: un dominio, un tenant
- La excepción que debes conocer: los subdominios
- UPN, SMTP y dominio: tres conceptos que no deben confundirse
- Cuándo es necesario mover un dominio
- Qué puede impedir eliminar el dominio
- Cómo utilizar onmicrosoft.com durante la transición
- Entornos híbridos y Microsoft Entra Connect
- DNS durante el cambio de tenant
- MX y flujo de correo
- SPF: no crees dos registros
- DKIM: hay que prepararlo de nuevo en destino
- DMARC y alineación del correo
- Aplicaciones y servicios externos
- Assessment previo del dominio
- Estrategias de cutover
- Proceso recomendado paso a paso
- ForceDelete: qué es y cuándo no utilizarlo
- Runbook de la ventana de corte
- Validación después del cambio
- Errores frecuentes
- Preguntas frecuentes
Qué significa mover un dominio entre tenants de Microsoft 365
Cuando hablamos de mover un dominio de Microsoft 365, normalmente queremos decir que un dominio personalizado utilizado en un tenant de origen debe dejar de estar asociado a ese entorno para poder añadirse y verificarse en otro tenant.
Por ejemplo:
empresa.com está actualmente asociado al Tenant A y queremos que, después de una migración, pase a ser utilizado por los usuarios del Tenant B.
El proceso no consiste simplemente en entrar en Settings > Domains, pulsar eliminar y añadirlo en el segundo tenant. Antes de Microsoft permitir su retirada, el dominio debe dejar de ser utilizado por los recursos que dependen de él.
Microsoft documenta expresamente que un dominio personalizado no puede eliminarse si todavía existen usuarios, grupos o determinadas aplicaciones que lo referencian.
Además, Microsoft 365 añade otras dependencias relacionadas con Exchange Online y colaboración que deben eliminarse o modificarse previamente.
Referencia oficial: Microsoft – Remove a domain from Microsoft 365.
Mover el dominio entre tenants no es transferir el registrador ni cambiar el DNS
Este es uno de los conceptos que más confusión genera.
Una empresa puede tener el dominio registrado en Cloudflare, GoDaddy, IONOS, Arsys o cualquier otro registrador y utilizar Microsoft 365 para el correo. También puede tener el registrador en una empresa y la zona DNS alojada en otra.
Mover el dominio entre tenants Microsoft 365 no implica necesariamente cambiar el registrador ni los nameservers.
| Elemento | Qué hace | ¿Debe cambiar necesariamente? |
|---|---|---|
| Registrador | Mantiene la propiedad y registro del dominio. | No. |
| DNS hosting | Publica los registros DNS. | No. |
| Tenant Microsoft 365 | Asocia el dominio con identidades y servicios Microsoft. | Sí, si el dominio cambia de tenant. |
| MX | Determina dónde se entrega el correo. | Puede necesitar actualizarse en el cutover. |
| SPF / DKIM / DMARC | Autentican el correo enviado con el dominio. | Deben revisarse y, en el caso de DKIM, reconfigurarse para el nuevo tenant. |
Microsoft también distingue expresamente entre registrador y DNS hosting provider en su documentación. Pueden ser la misma empresa, pero no tienen por qué serlo.
Antes de una migración debería estar documentado quién controla ambas cosas y quién tiene las credenciales necesarias para realizar cambios.
La regla principal: el mismo dominio personalizado no puede estar verificado en dos tenants
Microsoft es explícito en este punto: el mismo dominio personalizado exacto no puede añadirse y verificarse en más de un tenant Microsoft Entra al mismo tiempo.
Si empresa.com está verificado en el Tenant A, el Tenant B no podrá utilizar ese mismo dominio como dominio personalizado verificado hasta que haya sido retirado del primero.
Esto es lo que crea el momento crítico de una migración tenant-to-tenant. El destino puede prepararse con antelación, pero hay un momento en el que el dominio debe:
dejar de pertenecer al origen → quedar libre → añadirse al destino → verificarse → asignarse a objetos y servicios.
No existe una etapa normal en la que el mismo empresa.com esté completamente operativo y verificado en los dos tenants.
Referencia oficial: Microsoft – Microsoft Entra Connect supported topologies.
La excepción que debes conocer: los subdominios
Hay un matiz interesante que no conviene perder.
Aunque el mismo dominio exacto no puede verificarse en dos tenants, Microsoft documenta que un subdominio puede verificarse en un tenant distinto al que contiene el dominio raíz.
Por ejemplo, Microsoft permite un escenario en el que:
| Tenant A | Tenant B |
|---|---|
empresa.com | europe.empresa.com |
El subdominio debe verificarse mediante el correspondiente registro TXT.
Esto puede ser útil en determinados diseños de identidad o transición, aunque no convierte los subdominios en un sustituto automático de una estrategia de migración. Hay que analizar correo, branding, aplicaciones y experiencia de usuario antes de utilizarlos como solución temporal.
Referencia oficial: Microsoft – Manage custom domain names in Microsoft Entra ID.
UPN, SMTP y dominio: tres conceptos que suelen confundirse
Uno de los errores más habituales al hablar de un cambio de dominio es utilizar indistintamente “usuario”, “correo” y “dominio”. Son elementos relacionados, pero no son lo mismo.
| Concepto | Ejemplo | Función principal |
|---|---|---|
| UPN | ana@empresa.com | Nombre de inicio de sesión del usuario en Microsoft Entra ID. |
| SMTP principal | ana@empresa.com | Dirección principal desde la que normalmente envía y recibe correo. |
| Alias / proxyAddress | a.garcia@empresa.com | Direcciones adicionales asociadas al destinatario. |
| Dominio personalizado | empresa.com | Namespace verificado dentro del tenant. |
En muchas organizaciones UPN y correo son iguales, pero técnicamente pueden ser diferentes.
Por eso, mover el dominio obliga a decidir qué ocurrirá con ambos.
Un usuario puede pasar temporalmente de:
ana@empresa.com
a:
ana@tenantorigen.onmicrosoft.com
mientras se libera el dominio, para después recibir en destino:
ana@empresa.com
El proceso debe diseñarse para que el usuario sepa en todo momento con qué identidad debe iniciar sesión y qué dirección de correo está utilizando.
Cuándo suele ser necesario mover o liberar un dominio
El caso más frecuente aparece durante una adquisición. Una compañía compra otra y decide integrar sus usuarios en el tenant corporativo. El dominio de la empresa adquirida puede mantenerse como dirección de correo, aunque los usuarios y datos pasen al tenant de la matriz.
En una escisión sucede exactamente lo contrario: una división abandona el tenant existente y necesita llevarse su dominio a una nueva organización.
| Escenario | Qué ocurre con el dominio |
|---|---|
| Adquisición | El dominio de la empresa adquirida pasa al tenant corporativo. |
| Carve-out | Una unidad de negocio libera su dominio para utilizarlo en un tenant independiente. |
| Consolidación | Varios dominios de tenants distintos terminan administrados desde uno solo. |
| Rebranding | Se introduce un nuevo dominio y puede retirarse progresivamente el antiguo. |
| Tenant incorrecto o abandonado | El dominio debe recuperarse antes de poder utilizarse en el tenant correcto. |
Qué puede impedir eliminar un dominio de Microsoft 365
El botón Remove domain solo funciona cuando Microsoft considera que el dominio ya no es necesario para los recursos del tenant.
La documentación actual de Microsoft 365 indica que, antes de eliminarlo, el dominio no debe ser el dominio predeterminado y no pueden seguir utilizándolo usuarios, shared mailboxes, resource mailboxes, contactos, Microsoft 365 Groups, listas de distribución, Teams ni cuentas administrativas.
Microsoft Entra añade además dos comprobaciones especialmente relevantes: grupos que todavía tengan email o proxy addresses con el dominio y aplicaciones cuyo App ID URI lo contenga.
| Área | Ejemplos de dependencias |
|---|---|
| Usuarios | UPN, email y proxyAddresses. |
| Administradores | Cuenta administrativa que inicia sesión como admin@empresa.com. |
| Exchange | Buzones, shared mailboxes, salas, recursos y contactos. |
| Grupos | Microsoft 365 Groups, Teams, distribution lists y mail-enabled groups. |
| Aplicaciones | App ID URI que contiene el dominio. |
| Identidad híbrida | Objetos cuyo UPN o proxyAddresses siguen controlándose desde Active Directory. |
El administrador también cuenta
Un detalle que puede bloquear el cambio en el peor momento es que la propia cuenta utilizada para administrar el tenant use el dominio que se pretende eliminar.
Microsoft recomienda utilizar para la eliminación una cuenta administrativa basada en el dominio inicial onmicrosoft.com o en otro dominio diferente.
Además, si el único Global Administrator utiliza el dominio que se quiere retirar, Microsoft recomienda disponer primero de otro administrador con un dominio diferente antes de cambiar ese usuario.
Cómo utilizar onmicrosoft.com durante una migración
El dominio onmicrosoft.com es una pieza muy útil en una migración tenant-to-tenant porque permite preparar usuarios y objetos sin necesidad de disponer todavía del dominio corporativo.
Cuando el tenant se crea, Microsoft asigna un dominio inicial, por ejemplo:
empresa123.onmicrosoft.com
Ese dominio inicial permanece asociado al tenant y no puede eliminarse.
Microsoft permite actualmente crear dominios onmicrosoft.com adicionales y seleccionar uno como fallback domain. El límite documentado es de cinco dominios onmicrosoft.com en total y, una vez creados, tampoco pueden eliminarse.
Esto puede resultar útil cuando el nombre inicial del tenant no es adecuado para una transición o se quiere utilizar un namespace más reconocible.
No crees dominios onmicrosoft.com de prueba sin pensarlo
Microsoft indica que estos dominios no pueden eliminarse después. Si necesitas crear uno nuevo para usarlo como fallback, revisa bien el nombre antes de confirmarlo.
Referencia oficial: Microsoft – Add or replace an onmicrosoft.com fallback domain.
Qué cambia si existe Active Directory local o Microsoft Entra Connect
En un entorno cloud-only, cambiar el UPN de un usuario puede realizarse directamente sobre Microsoft Entra ID.
En una organización híbrida, la situación es diferente. Si el objeto está sincronizado desde Active Directory local, determinados atributos siguen teniendo como source of authority el directorio on-premises.
Modificar únicamente el valor en Microsoft 365 puede no ser posible o puede provocar que la sincronización vuelva a escribir el atributo anterior.
Antes del cutover conviene comprobar:
| Elemento | Qué revisar |
|---|---|
| UPN suffixes | Qué sufijos existen configurados en Active Directory Domains and Trusts. |
| proxyAddresses | Qué direcciones SMTP se sincronizan desde local. |
| Entra Connect Sync | Qué OUs y objetos están dentro del alcance. |
| Federación | Si el dominio utiliza autenticación federada. |
| Aplicaciones | Si existen aplicaciones AD FS u otras dependencias del sufijo UPN. |
Además, Microsoft indica que la opción ForceDelete no funciona cuando el dominio utiliza autenticación federada. En ese escenario, los usuarios y grupos deben modificarse primero desde el Active Directory que los administra.
DNS durante el cambio de tenant
Los DNS son la parte visible del cambio, pero solo deberían tocarse cuando todo lo que hay detrás ya está preparado.
Antes de la ventana de corte conviene exportar o documentar la zona actual y distinguir los registros relacionados con Microsoft 365 de los que pertenecen a otros servicios.
| Registro | Función | Momento habitual de actuación |
|---|---|---|
| TXT de verificación | Demuestra a Microsoft que controlas el dominio. | Al añadir el dominio al tenant destino. |
| MX | Define dónde debe entregarse el correo. | Durante el cambio de mail flow. |
| Autodiscover | Ayuda a clientes como Outlook a localizar Exchange Online. | Revisar dentro del cutover. |
| SPF | Define fuentes autorizadas para enviar correo. | Revisar antes y publicar la versión final durante el cambio. |
| DKIM | Permite firmar criptográficamente los mensajes. | Preparar valores cuando el dominio esté disponible en destino. |
| DMARC | Define cómo tratar correo que no supera alineación SPF/DKIM. | Revisar durante la transición y mantener correctamente publicado. |
Referencia oficial: Microsoft – Connect your domain by adding DNS records.
TTL: útil, pero no mágico
Reducir con antelación el TTL de los registros que se modificarán durante el cutover puede ayudar a disminuir el tiempo que determinados resolvers conservan los valores anteriores.
Pero no significa que todos los sistemas de Internet actualicen inmediatamente el registro. Existen cachés intermedias y comportamientos de proveedores que no controla Microsoft ni el administrador del dominio.
Por eso no conviene diseñar el cambio suponiendo una propagación instantánea.
MX y flujo de correo: no lo cambies antes de tiempo
El registro MX indica a otros sistemas de correo dónde deben entregar los mensajes destinados al dominio.
Durante una migración tenant-to-tenant, el momento exacto para modificarlo depende de la arquitectura de mail flow.
Un cambio prematuro puede hacer que mensajes nuevos lleguen al tenant destino cuando todavía faltan usuarios o buzones. Un cambio demasiado tardío puede hacer que el correo continúe entrando en origen cuando los usuarios ya están trabajando desde destino.
| Antes de cambiar el MX | Debería estar validado |
|---|---|
| Dominio | Añadido y verificado en destino. |
| Usuarios | Destinatarios relevantes preparados. |
| Buzones | Disponibles o correctamente encaminados según la arquitectura. |
| Aliases | Direcciones esperadas configuradas. |
| Mail flow | Probado internamente y entre tenants cuando exista coexistencia. |
| Antispam / gateway | Revisado si existe un servicio intermedio. |
Microsoft también recomienda, en migraciones desde otros servicios de correo, preparar los usuarios y buzones antes de apuntar el MX a Microsoft 365. El principio es igualmente válido aquí: primero prepara el destino, después cambia la entrada de correo.
¿El dominio es el punto crítico de tu cutover?
Podemos preparar un runbook específico con dependencias, secuencia de cambios, DNS, Exchange, validaciones y responsables para reducir la improvisación durante la ventana de migración.
Preparar mi cutover de dominioSPF: no crees dos registros al cambiar de tenant
SPF suele generar problemas porque durante una migración pueden coexistir Microsoft 365, servidores locales, aplicaciones SaaS, herramientas de marketing, sistemas ERP y plataformas de soporte enviando correo con el mismo dominio.
La regla más importante es clara: debe existir un único registro SPF TXT por dominio o subdominio.
Crear uno para Microsoft 365 y otro para una aplicación externa no suma permisos. Microsoft advierte que varios registros SPF en el mismo dominio provocan un permerror.
Si varias plataformas envían correo, deben integrarse las fuentes autorizadas dentro de un único registro, teniendo también en cuenta el límite de búsquedas DNS de SPF.
| Situación | Qué hacer |
|---|---|
| Solo Microsoft 365 envía correo | Utilizar la configuración SPF indicada por Microsoft para Exchange Online. |
| Microsoft 365 + ERP | Incluir correctamente ambas fuentes en un único registro. |
| Microsoft 365 + plataforma de marketing | Evaluar si conviene utilizar un subdominio específico para la plataforma externa. |
| Dos registros SPF publicados | Corregirlos y consolidarlos en uno. |
Microsoft recomienda además no depender solo de SPF para proteger el dominio frente a spoofing: debe complementarse con DKIM y DMARC.
Documentación oficial: Microsoft – Set up SPF for custom domains.
DKIM: no reutilices a ciegas la configuración del tenant origen
DKIM es uno de los puntos que más fácilmente se pasa por alto durante un tenant-to-tenant.
En Microsoft 365, los dominios personalizados deben configurarse para que Exchange Online firme los mensajes utilizando DKIM. Esto requiere publicar dos registros CNAME correspondientes a los selectores que Microsoft proporciona para ese dominio.
Cuando el dominio cambia de tenant, los valores de destino de esos CNAME deben obtenerse del nuevo tenant.
Microsoft indica actualmente que los valores deben consultarse directamente desde:
Microsoft Defender portal o Exchange Online PowerShell.
No conviene copiar los valores DKIM antiguos y asumir que seguirán siendo válidos, porque contienen información asociada a la configuración y routing del tenant correspondiente.
Orden recomendado
| Paso | Acción |
|---|---|
| 1 | Liberar el dominio del tenant origen. |
| 2 | Añadir y verificar el dominio en el tenant destino. |
| 3 | Consultar en el tenant destino los CNAME DKIM requeridos. |
| 4 | Publicar los dos selectores en DNS. |
| 5 | Esperar a que Microsoft detecte correctamente los registros. |
| 6 | Activar DKIM para el dominio. |
| 7 | Validar una cabecera de correo real. |
Referencia oficial: Microsoft – Set up DKIM to sign mail from your custom domain.
DMARC: mantener la protección durante el cambio
DMARC se publica en DNS, por lo que no “pertenece” directamente a uno de los tenants. Sin embargo, su funcionamiento depende de que SPF y/o DKIM estén correctamente alineados con el dominio utilizado en el campo From.
Durante un cutover, una configuración incompleta de SPF o DKIM puede hacer que mensajes legítimos empiecen a fallar DMARC.
Por eso, antes de cambiar el tenant hay que conocer todas las plataformas que envían correo en nombre del dominio.
| Origen de correo | Ejemplo | Qué comprobar |
|---|---|---|
| Exchange Online | Usuarios corporativos. | SPF y DKIM del nuevo tenant. |
| ERP / CRM | Facturas, notificaciones o workflows. | SPF, DKIM propio o relay utilizado. |
| Marketing | Newsletters. | Alineación SPF/DKIM y preferencia por subdominio. |
| Ticketing | Soporte o atención al cliente. | Dominio From y autenticación real. |
| Web | Formularios y notificaciones. | Servicio SMTP/API utilizado. |
Microsoft recomienda configurar primero SPF y DKIM y después implementar DMARC progresivamente, monitorizando los resultados antes de aplicar políticas restrictivas como p=reject.
Referencia oficial: Microsoft – Set up DMARC in Microsoft 365.
Aplicaciones y servicios externos: la dependencia invisible
Una migración puede liberar correctamente el dominio, configurar Exchange y publicar DNS y, aun así, descubrir después que una aplicación crítica ha dejado de funcionar.
El motivo es que muchas integraciones contienen referencias al dominio corporativo.
| Tipo de aplicación | Dependencia habitual |
|---|---|
| SSO | UPN, claims o dominio utilizado para identificar al usuario. |
| App Registration | App ID URI relacionado con el dominio. |
| SMTP | Dirección desde la que envía una aplicación. |
| SCIM | UPN o correo utilizado en el provisioning. |
| Firma electrónica | Cuentas corporativas y dominios autorizados. |
| CRM / ERP | OAuth, mailboxes, relay o Graph API. |
| Backups | Service accounts y permisos asociados al tenant anterior. |
Microsoft Entra bloquea directamente la eliminación cuando determinadas aplicaciones tienen un App ID URI que contiene el dominio.
Pero incluso aplicaciones que no bloqueen técnicamente la eliminación pueden dejar de funcionar después. Por eso el inventario de aplicaciones debe ser funcional, no solo administrativo.
Assessment previo: qué revisar antes de reservar la ventana de cambio
La mejor forma de reducir el riesgo del dominio es separar su análisis del resto de la migración y crear un inventario específico.
| Área | Qué buscar | Resultado esperado |
|---|---|---|
| Microsoft Entra ID | UPN, proxyAddresses, grupos y App ID URI. | Listado de objetos que deben modificarse. |
| Exchange Online | Buzones, aliases, shared mailboxes, recursos y contactos. | Mapa completo de direcciones SMTP. |
| Teams / Groups | Microsoft 365 Groups y Teams que utilizan direcciones del dominio. | Objetos que deben renombrarse temporalmente. |
| Active Directory | UPN suffix y proxyAddresses sincronizados. | Plan de modificación on-premises. |
| DNS | Registrar, DNS provider y registros existentes. | Backup de zona y acceso probado. |
| Correo externo | ERP, CRM, marketing, ticketing y aplicaciones. | Inventario de fuentes SPF/DKIM. |
| Aplicaciones | SSO, SCIM, Graph, SMTP y OAuth. | Plan de reconfiguración. |
Una prueba sencilla que ahorra problemas
Antes del cutover intenta determinar si Microsoft permitiría eliminar el dominio y revisa qué dependencias aparecen en el centro de administración.
No es necesario completar la eliminación. El objetivo es descubrir referencias inesperadas mientras todavía hay tiempo para corregirlas.
Estrategias para mover el dominio durante una migración
No todos los proyectos deben mover el dominio de la misma forma.
Cutover único
Usuarios y servicios principales cambian en una misma ventana. El dominio se libera del origen y se incorpora al destino dentro de ese periodo.
Es más sencillo desde el punto de vista conceptual, pero concentra gran cantidad de cambios en pocas horas.
Migración por oleadas con dominio al final
Los datos se premigran y los usuarios se preparan utilizando direcciones temporales. El dominio corporativo se mueve cuando la mayoría de workloads ya están preparados.
Este modelo reduce la cantidad de datos pendiente durante el corte, aunque requiere una estrategia clara de coexistencia.
Rebranding
Si además del tenant cambia el dominio corporativo, la estrategia puede ser diferente. En lugar de preservar empresa-antigua.com como dirección principal, puede mantenerse únicamente como alias o utilizarse durante un periodo transitorio.
En este caso la migración puede ser una oportunidad para simplificar y no necesariamente reproducir exactamente la configuración anterior.
Proceso recomendado para liberar un dominio y moverlo a otro tenant
Los detalles cambian según el entorno, pero un proceso sólido suele seguir este orden.
1. Preparar el tenant destino
Antes de tocar el dominio, el destino debería estar preparado en todo lo posible.
Los usuarios pueden crearse utilizando el dominio temporal del tenant, asignarse a grupos, recibir licencias y prepararse para los workloads de migración según las limitaciones de la herramienta utilizada.
2. Inventariar el dominio en origen
Hay que identificar todas las referencias: UPN, SMTP, aliases, grupos, contactos, Teams, aplicaciones y objetos sincronizados.
3. Preparar un namespace temporal
Normalmente se utiliza onmicrosoft.com u otro dominio que permanecerá en el tenant origen.
Este namespace servirá para sustituir temporalmente las referencias al dominio corporativo que necesitamos liberar.
4. Cambiar usuarios y objetos en origen
Se actualizan UPN, direcciones y grupos que todavía utilizan el dominio.
En objetos sincronizados desde Active Directory, estos cambios deben realizarse respetando su source of authority.
5. Revisar Exchange Online
Se comprueban shared mailboxes, resource mailboxes, contactos, distribution groups, mail-enabled groups y cualquier proxyAddress todavía relacionado con el dominio.
6. Revisar aplicaciones
Hay que eliminar o cambiar App ID URI que bloquee la retirada y preparar cualquier SSO, SCIM, Graph o SMTP que vaya a cambiar después.
7. Cambiar el dominio predeterminado si es necesario
Microsoft no permite eliminar un dominio que siga definido como predeterminado. Debe establecerse otro dominio antes de continuar.
8. Utilizar una cuenta administrativa independiente
No conviene realizar la operación con admin@empresa.com si empresa.com es precisamente el dominio que se quiere eliminar.
Es preferible una cuenta administrativa basada en onmicrosoft.com u otro dominio.
9. Eliminar el dominio del tenant origen
Una vez eliminadas las dependencias, se solicita la retirada desde el centro de administración.
Microsoft indica que el proceso puede tardar desde unos minutos hasta varias horas, y en entornos con muchas referencias puede llegar a un día.
10. Añadir el dominio al tenant destino
Cuando Microsoft ya lo considera libre, se añade al nuevo tenant y se demuestra la propiedad mediante el registro de verificación correspondiente.
11. Aplicarlo a usuarios y grupos
Ahora pueden establecerse los UPN, direcciones SMTP y aliases definitivos.
12. Preparar autenticación del correo
Se revisa SPF, se obtienen los nuevos selectores DKIM y se comprueba la política DMARC existente.
13. Cambiar el flujo de correo
Se modifica el MX y cualquier otro elemento de routing siguiendo la arquitectura diseñada.
14. Validar
Antes de comunicar que la migración está completada deben probarse identidad, correo, aplicaciones y dispositivos.
ForceDelete: qué es y por qué no debería ser el plan A
Microsoft Entra dispone de una función denominada ForceDelete para determinados escenarios en los que un dominio todavía tiene referencias.
ForceDelete puede reemplazar referencias al dominio personalizado por el dominio inicial onmicrosoft.com.
Esto puede parecer una forma rápida de desbloquear un dominio, pero tiene restricciones importantes.
| Limitación | Implicación |
|---|---|
| Menos de 1.000 referencias | La operación no está pensada para limpiar de forma indiscriminada grandes entornos. |
| Objetos administrados por Exchange | Determinados grupos deben limpiarse manualmente en Exchange. |
| Aplicaciones multitenant | Pueden impedir el proceso. |
| Dominio federado | ForceDelete no funciona para este tipo de dominio. |
| Usuarios afectados | Microsoft documenta que las cuentas afectadas pueden quedar deshabilitadas durante el proceso. |
Por tanto, ForceDelete no debería sustituir una limpieza controlada del dominio en una migración planificada.
Puede tener utilidad en determinados escenarios administrativos, pero para un tenant-to-tenant es preferible conocer y corregir las referencias de forma deliberada.
Referencia oficial: Microsoft – ForceDelete and custom domain management.
Runbook recomendado para la ventana de cutover
El movimiento del dominio debería ejecutarse con un documento operativo que indique quién hace cada cambio, cuándo y cómo se valida.
| Momento | Acciones |
|---|---|
| Días antes | Revisar dependencias, reducir TTL cuando proceda, validar acceso a DNS y preparar usuarios destino. |
| T-24 h | Confirmar jobs de migración, licencias, mail flow, aplicaciones y equipo de soporte. |
| Inicio del cutover | Ejecutar deltas finales o medidas de control de cambios según la herramienta. |
| Liberación | Cambiar referencias restantes y eliminar el dominio del origen. |
| Alta en destino | Añadir, verificar y asignar el dominio. |
| Correo | Actualizar MX, SPF, DKIM, routing y servicios externos necesarios. |
| Usuarios | Aplicar UPN y SMTP definitivos. |
| Aplicaciones | Activar configuraciones dependientes del nuevo tenant. |
| Pruebas | Ejecutar validación técnica y funcional. |
| Comunicación | Informar a usuarios de que el cambio ha terminado y de cualquier acción necesaria. |
Qué validar después de mover el dominio
Que Microsoft muestre el dominio como Healthy o Verified no demuestra que toda la empresa esté funcionando correctamente.
La validación debe cubrir varias capas.
Identidad
| Prueba | Resultado esperado |
|---|---|
| Inicio de sesión | El usuario puede autenticarse con el UPN definitivo. |
| MFA | El flujo de autenticación funciona correctamente. |
| Conditional Access | No aparecen bloqueos inesperados. |
| Aplicaciones | SSO y aplicaciones empresariales reconocen la nueva identidad. |
Exchange Online
| Prueba | Qué comprobar |
|---|---|
| Correo externo entrante | El mensaje llega al buzón del tenant destino. |
| Correo externo saliente | Se entrega correctamente y sin errores de autenticación. |
| Correo interno | Los usuarios se resuelven correctamente. |
| Aliases | Las direcciones secundarias siguen recibiendo. |
| Shared mailboxes | Los usuarios mantienen el acceso previsto. |
| Calendario | Reuniones y delegaciones funcionan según el alcance del proyecto. |
Autenticación del correo
Envía mensajes reales y revisa sus cabeceras. Deben comprobarse:
SPF=pass, DKIM=pass y DMARC=pass, siempre que la arquitectura de envío esté diseñada para ello.
También conviene comprobar diferentes fuentes de correo: usuarios, ERP, CRM, plataforma de marketing y cualquier otro sistema que envíe utilizando el dominio.
Clientes y dispositivos
El cambio de tenant puede hacer que algunos clientes necesiten volver a autenticarse.
Hay que probar:
Outlook, Teams, OneDrive Sync, dispositivos móviles, Microsoft 365 Apps y dispositivos administrados mediante Intune cuando formen parte del proyecto.
Errores que más problemas generan al mover un dominio
| Error | Consecuencia | Prevención |
|---|---|---|
| No revisar administradores | La cuenta utilizada para el cambio también depende del dominio que intenta eliminar. | Mantener una cuenta administrativa onmicrosoft.com disponible. |
| Olvidar aliases | Microsoft sigue detectando referencias y no libera el dominio. | Buscar todas las proxyAddresses. |
| Ignorar grupos de Exchange | La eliminación falla aunque los usuarios estén corregidos. | Revisar distribution lists y mail-enabled groups. |
| Cambiar MX demasiado pronto | El correo llega a un destino todavía incompleto. | Cambiarlo solo después de validar destinatarios y mail flow. |
| Publicar dos SPF | SPF devuelve permerror. | Integrar todas las fuentes en un único registro. |
| Reutilizar DKIM antiguo | Microsoft no firma correctamente o los CNAME apuntan al entorno anterior. | Obtener los selectores desde el nuevo tenant. |
| No revisar aplicaciones | SSO, SMTP o APIs dejan de funcionar. | Inventario previo de dependencias. |
| Cambiar solo en cloud objetos sincronizados | El cambio se revierte o entra en conflicto con AD local. | Modificar en el source of authority. |
| Usar ForceDelete sin analizar impacto | Cambios masivos no previstos en usuarios y objetos. | Utilizar limpieza controlada como procedimiento principal. |
| No validar cabeceras de correo | SPF/DKIM/DMARC parecen configurados, pero el correo real falla. | Realizar pruebas externas y revisar Authentication-Results. |
El dominio no debería ser una sorpresa el día de la migración
En Kloudeal podemos revisar el tenant origen, localizar las dependencias del dominio y preparar con antelación la secuencia de liberación, alta en destino, DNS y validación.
Analizar el cambio de mi dominio Microsoft 365Preguntas frecuentes sobre dominios Microsoft 365 y migraciones tenant-to-tenant
El mismo dominio personalizado exacto no puede estar añadido y verificado simultáneamente en dos tenants Microsoft Entra.
Por ejemplo, empresa.com debe liberarse del tenant origen antes de poder verificarse en el tenant destino.
Sí. Microsoft documenta que un subdominio como europe.empresa.com puede verificarse en un tenant distinto al que contiene empresa.com.
Esto no significa que el mismo dominio raíz pueda estar en ambos tenants, y cualquier uso del subdominio debe diseñarse teniendo en cuenta correo, identidad y aplicaciones.
No si empresa.com ya está verificado en el tenant origen.
El tenant destino puede prepararse usando su dominio onmicrosoft.com u otro dominio disponible, pero el dominio corporativo debe liberarse primero.
Normalmente porque todavía existe alguna dependencia.
Puede tratarse de usuarios, shared mailboxes, resource mailboxes, contactos, Microsoft 365 Groups, Teams, distribution lists, proxy addresses, administradores o aplicaciones que utilizan el dominio en un App ID URI.
Sí. Microsoft indica que el dominio que se pretende retirar no puede seguir configurado como dominio predeterminado de la organización.
No. Los dominios onmicrosoft.com no pueden eliminarse una vez creados.
Microsoft permite tener varios y seleccionar uno como fallback, pero actualmente limita el total a cinco.
Permite preparar usuarios y objetos cuando el dominio corporativo todavía está en el tenant origen.
También puede utilizarse temporalmente para sustituir UPN y direcciones mientras se libera el dominio personalizado.
Microsoft indica que una eliminación con pocas referencias puede completarse en pocos minutos.
Cuando existen muchas dependencias puede tardar varias horas y, en algunos casos, hasta un día. Por eso no conviene diseñar un cutover excesivamente ajustado suponiendo que la retirada será instantánea.
Es una función que puede sustituir determinadas referencias de un dominio personalizado por el dominio inicial onmicrosoft.com para facilitar su eliminación.
Tiene varias restricciones y puede modificar o deshabilitar objetos, por lo que no debería utilizarse como sustituto de una preparación controlada en una migración planificada.
No. Microsoft indica que ForceDelete no funciona cuando el dominio utiliza autenticación federada.
En ese caso deben modificarse los usuarios y grupos mediante el Active Directory que administra esos objetos antes de volver a intentar eliminar el dominio.
Los usuarios del tenant origen no pueden seguir utilizando el dominio en su UPN cuando llegue el momento de eliminarlo.
Normalmente se cambia temporalmente a un dominio alternativo u onmicrosoft.com.
No necesariamente. UPN e SMTP son atributos relacionados pero distintos.
En muchas empresas tienen el mismo valor, pero deben revisarse de forma independiente durante la migración.
Los cambios deben realizarse respetando el origen de autoridad de esos atributos.
Si UPN o proxyAddresses proceden del Active Directory local, normalmente habrá que modificarlos allí y dejar que Microsoft Entra Connect sincronice el cambio.
No. El registrador puede seguir siendo exactamente el mismo.
Tampoco es obligatorio cambiar el proveedor DNS. Lo que cambia es la asociación del dominio con Microsoft 365 y los registros necesarios para los nuevos servicios.
El registrador administra el registro y propiedad del dominio.
El proveedor DNS publica la zona y los registros como MX, TXT, CNAME y otros. Pueden ser la misma empresa o proveedores diferentes.
Cuando el tenant destino y el flujo de correo estén preparados para recibir los mensajes del dominio.
No conviene modificarlo demasiado pronto porque el correo podría empezar a llegar a un tenant que todavía no está listo.
Debe revisarse. Si Microsoft 365 y las fuentes legítimas de envío no cambian, una parte del registro puede mantenerse, pero hay que confirmar todas las plataformas que seguirán enviando correo.
Solo debe existir un registro SPF por dominio o subdominio.
No. Microsoft advierte que varios registros SPF TXT para el mismo dominio provocan un error permanente de SPF.
Las fuentes legítimas deben integrarse en un único registro respetando las limitaciones del protocolo.
Sí. Una vez añadido el dominio al tenant destino deben obtenerse los valores CNAME que Microsoft proporciona para ese entorno, publicarlos en DNS y activar DKIM.
No conviene asumir que los valores del tenant origen pueden reutilizarse.
No necesariamente y, en general, no debería desactivarse sin una razón técnica.
Lo importante es asegurar que las fuentes legítimas siguen pasando y alineando SPF o DKIM después del cutover.
Debe revisarse dentro del cambio de Exchange Online.
Los usuarios pueden necesitar volver a autenticarse o recrear perfiles dependiendo de cómo se haya ejecutado la migración de buzones, identidad y dispositivos.
No siempre.
Depende de la estrategia de migración, UPN, Exchange Online, Autodiscover y versión del cliente. Algunos escenarios pueden requerir nueva autenticación o creación de un perfil de Outlook.
Puede ser necesario, especialmente cuando cambia el tenant asociado a la identidad y al buzón.
Este comportamiento debe probarse con usuarios piloto antes de la migración masiva.
El simple cambio del dominio no migra Teams ni OneDrive.
Estos workloads deben formar parte de la estrategia tenant-to-tenant correspondiente. Los usuarios pueden además necesitar volver a iniciar sesión o sincronizar contra el nuevo tenant.
Hay que revisarlas una por una.
SSO, SCIM, Graph, SMTP, App Registrations, App ID URI, certificados, OAuth y otros servicios pueden contener referencias al tenant o al dominio anterior.
Primero hay que identificar el tenant y recuperar control o seguir el procedimiento correspondiente.
Microsoft documenta mecanismos de admin takeover para determinados tenants no administrados y también procedimientos para retirar un dominio de otra cuenta en escenarios compatibles.
El principio sigue siendo el mismo: el dominio debe quedar libre del tenant que actualmente lo utiliza antes de añadirse al nuevo.
Sin embargo, determinados proveedores pueden utilizar modelos de tenant o administración delegada propios, por lo que conviene identificar exactamente dónde está asociado el dominio antes de modificar servicios o cancelar suscripciones.
El objetivo debe ser minimizar el impacto, pero no es responsable prometer interrupción cero.
La liberación del dominio, DNS, propagación, Exchange, UPN, Outlook, móviles y aplicaciones pueden generar ventanas de transición o requerir acciones del usuario.
En muchos proyectos sí, especialmente cuando el dominio afecta al correo y al inicio de sesión de una parte importante de la empresa.
La ventana adecuada depende de la actividad internacional de la organización, soporte disponible, volumen y arquitectura de coexistencia.
Como mínimo: login, MFA, correo externo entrante y saliente, correo interno, aliases, shared mailboxes, calendario, SPF, DKIM, DMARC, Outlook, dispositivos móviles y aplicaciones críticas.
Cuando el dominio afecta a muchos usuarios, varios dominios, identidad híbrida, aplicaciones críticas, sistemas externos de correo, Teams, SharePoint o una migración tenant-to-tenant con poco margen para errores.
También es recomendable si no existe un inventario fiable de las dependencias antes de la ventana de corte.
Conclusión: el dominio debe ser una fase del proyecto, no una tarea del último minuto
Mover un dominio entre tenants de Microsoft 365 concentra identidad, correo y DNS en un único momento del proyecto. Por eso es una de las partes que más preparación necesita.
La dificultad real no está en pulsar Remove domain, sino en conseguir que Microsoft permita hacerlo porque ningún usuario, administrador, mailbox, grupo, Team, alias o aplicación sigue dependiendo de él.
Después llega una segunda fase igualmente importante: incorporar el dominio al tenant destino y reconstruir correctamente su funcionamiento. Eso implica UPN, SMTP, MX, SPF, DKIM, DMARC, mail flow, aplicaciones y experiencia de usuario.
Además, la documentación actual de Microsoft introduce detalles que conviene tener presentes: el mismo dominio exacto no puede verificarse en dos tenants, aunque determinados subdominios sí pueden utilizarse en tenants distintos; los dominios onmicrosoft.com no pueden eliminarse; ForceDelete tiene restricciones importantes; SPF solo admite un registro por dominio; y DKIM debe configurarse utilizando los valores proporcionados por el nuevo tenant.
La mejor estrategia es, por tanto, preparar todo lo posible antes del cutover, limpiar las dependencias del dominio con antelación, documentar la secuencia exacta y validar técnicamente cada servicio después del cambio.
¿Necesitas mover un dominio entre tenants de Microsoft 365?
En Kloudeal podemos ayudarte a preparar y ejecutar el cambio dentro de una migración tenant-to-tenant.
Revisamos dependencias del dominio, usuarios, grupos, Exchange Online, UPN, proxyAddresses, identidad híbrida, aplicaciones, MX, Autodiscover, SPF, DKIM, DMARC y servicios externos antes de la ventana de corte.
También podemos coordinarnos con la migración de Exchange Online, OneDrive, SharePoint y Teams para que el dominio se mueva en el momento adecuado y no como una tarea independiente del resto del proyecto.
Hablar con Kloudeal sobre mi cambio de dominioDocumentación oficial recomendada
Dominios Microsoft 365 y Microsoft Entra
- Microsoft – Remove a domain from Microsoft 365
- Microsoft – Add a custom domain to Microsoft 365
- Microsoft – Add your custom domain name to Microsoft Entra ID
- Microsoft – Manage custom domain names in Microsoft Entra ID
- Microsoft – Microsoft Entra Connect supported topologies
Dominios onmicrosoft.com
DNS y correo
- Microsoft – Connect your domain by adding DNS records
- Microsoft – External DNS records for Microsoft 365
SPF, DKIM y DMARC
- Microsoft – Set up SPF for your Microsoft 365 domain
- Microsoft – Set up DKIM for your custom domain
- Microsoft – Set up DMARC in Microsoft 365
- Microsoft – How email authentication works in Microsoft 365