Cambio de dominio entre tenants de Microsoft 365

Cómo preparar el cambio de dominio como una operación coordinada

Un cambio de dominio entre tenants de Microsoft 365 requiere coordinar identidad, correo y aplicaciones. El dominio puede aparecer en nombres de inicio de sesión, direcciones principales, alias, grupos y referencias de aplicaciones. El inventario debe localizar esos usos y definir cómo se sustituirán temporalmente antes de intentar liberar el dominio. La lista de usuarios visibles en el portal no describe por sí sola todas las dependencias.

El plan de corte debe indicar qué equipo actúa en origen, quién prepara el destino y quién puede modificar los registros DNS. Esas responsabilidades pueden pertenecer a proveedores diferentes. Antes de la ventana se verifica que los accesos autorizados y las personas necesarias están disponibles, junto con las pruebas que confirmarán cada paso. Una credencial pendiente o un responsable ausente pueden detener la operación aunque la preparación técnica sea correcta.

También se comunica qué notará el usuario: cambios de inicio de sesión, sesiones que debe renovar o configuraciones que necesitarán acompañamiento. La dirección de correo y la cuenta de acceso deben comprobarse como elementos relacionados, pero distintos. Esa explicación ayuda a atender incidencias sin modificar direcciones o permisos que no son la causa del problema.

Cómo validar el dominio después de asociarlo al destino

La verificación administrativa es un hito del proceso, pero después deben probarse servicios. Se comprueba inicio de sesión, destinatarios, direcciones alternativas y flujo de correo interno y externo. También se revisan los sistemas que envían mensajes con el dominio y la configuración de autenticación que corresponda al nuevo diseño. Un correo entregado correctamente no acredita todos esos recorridos.

Los resultados se registran por destinatario y aplicación, con una vía de atención durante el primer periodo de uso. Si se necesita una contingencia, debe respetar el estado real en que ha quedado el dominio y los datos generados desde el cambio. No conviene prometer una vuelta instantánea al punto de partida sin haber analizado esas condiciones y las dependencias que ya se han modificado.

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.

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:

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.

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.

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.

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.

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:

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.

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.

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.

SPF: 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.

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.

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.

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.

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.

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.

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.

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.

Exchange Online.

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

Preguntas frecuentes sobre dominios Microsoft 365 y migraciones tenant-to-tenant

¿Mover el dominio de tenant exige cambiar de registrador?

No son la misma operación. El registrador mantiene el registro del dominio y el servicio DNS publica sus registros, mientras el tenant lo asocia con identidades y servicios de Microsoft. El proyecto debe saber quién administra cada parte y qué cambios se necesitan, sin mezclar el traslado entre tenants con una transferencia del registro.

¿Por qué un dominio puede seguir sin poder eliminarse del origen?

Puede haber objetos o referencias que todavía lo utilizan. Es necesario revisar usuarios, direcciones, grupos y dependencias aplicables, siguiendo los requisitos del servicio. Intentar la retirada sin completar ese inventario traslada la investigación a la ventana de corte. El plan debe comprobar previamente las referencias y su tratamiento temporal.

¿Cambiar el nombre de inicio de sesión modifica todos los accesos?

No debe darse por hecho que todas las aplicaciones y sesiones se actualizan de la misma manera. El UPN, las direcciones de correo y los identificadores que utilizan las aplicaciones tienen funciones diferentes. El piloto debe probar el recorrido con la cuenta prevista y documentar las configuraciones o sesiones que requieren intervención.

¿Qué pruebas deben hacerse después de verificar el dominio en destino?

Además de la asociación administrativa, se prueban inicio de sesión, destinatarios, envío y recepción interna y externa, alias y aplicaciones relevantes. También se revisa la autenticación del correo conforme al diseño. Las pruebas deben dejar evidencia del resultado y responsables para las incidencias, porque verificar el dominio no equivale a validar todos sus servicios.

Recomendaciones finales: 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.

Documentació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.

• Microsoft – Add or replace an onmicrosoft.com fallback domain

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

Dominios asociados a otro tenant.

• Microsoft – Remove a domain from another Microsoft 365 account
• Microsoft – Admin takeover of an unmanaged directory