Migración MX de Microsoft 365 a mx.microsoft: DNSSEC automático, Graph API obligatoria y acciones a realizar antes de julio de 2026
Por CaptainDNS
Publicado el 6 de marzo de 2026
- 1 de julio de 2026: Microsoft aprovisiona los MX de los nuevos Accepted Domains bajo
mx.microsoften lugar demail.protection.outlook.com(MC1048624, aplazado desde febrero de 2026) - Si tu dominio tiene DNSSEC activo, la cadena de confianza se extiende automáticamente al MX bajo
mx.microsoft: DANE se habilita sin ninguna acción adicional - Cualquier automatización que construya el MX a partir del patrón
<dominio>.mail.protection.outlook.comdejará de funcionar después del 1 de julio - La API Graph
serviceConfigurationRecordspasa a ser la única fuente de verdad - Los dominios existentes no se ven afectados de inmediato, pero Microsoft prevé una migración progresiva después de julio de 2026
- Comprueba ahora mismo si tu dominio está preparado para DNSSEC con un diagnóstico DNSSEC : es el requisito previo para beneficiarte de la protección DANE
El 4 de abril de 2025, Microsoft publicó el anuncio MC1048624: a partir del 1 de julio de 2026, todos los nuevos Accepted Domains añadidos a Exchange Online recibirán sus registros MX bajo el dominio mx.microsoft y ya no bajo mail.protection.outlook.com. La fecha inicial de febrero de 2026 se aplazó a julio tras los comentarios de la comunidad.
No es un cambio estético. El dominio mail.protection.outlook.com no está firmado con DNSSEC. El TLD .microsoft, en cambio, está firmado de extremo a extremo. Al migrar los MX bajo mx.microsoft, Microsoft elimina el principal obstáculo técnico para la adopción de DNSSEC y DANE en el correo entrante de Exchange Online. Los administradores ya no necesitan activar manualmente la migración del MX.
Para los equipos de IT, el impacto es doble. Por un lado, es una buena noticia: DNSSEC "gratis" si tu dominio ya está firmado. Por otro, cualquier automatización basada en el patrón <dominio>.mail.protection.outlook.com dejará de funcionar. Solo la Graph API serviceConfigurationRecords proporcionará el valor MX correcto.
Público objetivo: administradores de Microsoft 365, MSPs que gestionan tenants multidominio, equipos DevOps con workflows de aprovisionamiento DNS automatizados.
Qué cambia exactamente el 1 de julio de 2026
Antes: mail.protection.outlook.com
Hasta ahora, cuando añades un dominio personalizado a Exchange Online, Microsoft aprovisiona el MX con un formato predecible:
captaindns.com. 3600 IN MX 0 captaindns-com.mail.protection.outlook.com.
Este formato permitía deducir el valor MX a partir del nombre de dominio: sustituyes los puntos por guiones y añades .mail.protection.outlook.com. Muchas automatizaciones (scripts PowerShell, workflows de Terraform, herramientas de aprovisionamiento MSP) explotan este patrón.
Después: mx.microsoft
A partir de julio de 2026, los nuevos Accepted Domains recibirán un MX con el formato:
captaindns.com. 3600 IN MX 0 captaindns-com.o-v1.mx.microsoft.
El sufijo o-v1.mx.microsoft no se puede deducir solo a partir del nombre de dominio. El valor exacto debe obtenerse a través del centro de administración de Exchange o de la API Graph.
Cronología detallada
| Fecha | Evento |
|---|---|
| 4 de abril de 2025 | Publicación del anuncio MC1048624 |
| Febrero de 2026 | Fecha inicial prevista (aplazada) |
| 2 de febrero de 2026 | Actualización: aplazamiento a julio de 2026 |
| Principios de julio de 2026 | Inicio del cambio progresivo |
| Finales de julio de 2026 | Todos los nuevos Accepted Domains bajo mx.microsoft |
| Después de julio de 2026 | Migración progresiva de los dominios existentes (fecha sin confirmar) |
¿A quién afecta?
| Situación | Impacto |
|---|---|
| Dominio existente, MX ya configurado | Sin impacto inmediato. El MX actual bajo mail.protection.outlook.com sigue funcionando |
| Nuevo dominio añadido después de julio de 2026 | El MX estará bajo mx.microsoft. Las automatizaciones basadas en el patrón antiguo fallarán |
| Automatización de aprovisionamiento DNS | Acción necesaria: migrar a la API Graph serviceConfigurationRecords |
| DNSSEC ya activo en tu dominio | Bonus: DNSSEC se extiende automáticamente al MX, DANE se puede activar sin fricción |
¿Por qué este cambio? El problema de DNSSEC en outlook.com
El dominio outlook.com, y por extensión mail.protection.outlook.com, no está firmado con DNSSEC. Es una decisión histórica de Microsoft: firmar un dominio tan masivo con tantos subdominios dinámicos plantea desafíos operativos.
El problema: sin DNSSEC en el MX, DANE es imposible. Un servidor remitente quiere verificar el certificado TLS de Exchange Online mediante DANE. Debe poder validar la cadena DNSSEC de extremo a extremo, desde el MX hasta el TLSA. Si el MX apunta a un dominio sin firmar, la cadena se rompe.
La solución de Microsoft: el TLD .microsoft. Este TLD de marca (brand TLD) está firmado con DNSSEC de extremo a extremo. Al crear la infraestructura mx.microsoft, Microsoft obtiene una zona DNS totalmente bajo su control y firmada, sin las limitaciones heredadas de outlook.com.
La cadena DNSSEC completa queda así:
root (.) → .microsoft → mx.microsoft → o-v1.mx.microsoft → captaindns-com.o-v1.mx.microsoft
Cada eslabón está firmado. Los registros TLSA publicados por Microsoft bajo _25._tcp.captaindns-com.o-v1.mx.microsoft son verificables por cualquier servidor remitente compatible con DANE.
Para entender en detalle cómo funciona la cadena de confianza DNSSEC, consulta nuestra guía sobre la cadena de confianza DNSSEC.
DNSSEC automático: lo que obtienes gratis
El cambio MC1048624 tiene un efecto colateral importante: si tu dominio ya está firmado con DNSSEC, te beneficias automáticamente de la protección DNSSEC de extremo a extremo para tu correo entrante, sin ninguna acción en el centro de administración de Exchange.
Escenario 1: tu dominio no tiene DNSSEC
Nada cambia a nivel funcional. El MX apunta a mx.microsoft en lugar de mail.protection.outlook.com, pero la resolución DNS funciona con normalidad. Sin DANE, sin verificación TLSA : el comportamiento es idéntico al actual.
Escenario 2: tu dominio tiene DNSSEC activo
Aquí ocurre la magia:
- El servidor remitente resuelve el MX de
captaindns.com→captaindns-com.o-v1.mx.microsoft - La respuesta está firmada con DNSSEC (tu dominio está firmado,
mx.microsoftestá firmado) - El servidor solicita el TLSA para
_25._tcp.captaindns-com.o-v1.mx.microsoft - Microsoft publica automáticamente los registros TLSA correspondientes a los certificados de Exchange Online
- El servidor verifica el certificado TLS mediante DANE : autenticación del servidor sin depender de las autoridades de certificación
Resultado: protección contra ataques man-in-the-middle en el transporte de correo, de forma automática. Antes de este cambio, obtener DANE en Exchange Online requería un procedimiento manual de activación. Después de julio de 2026, para los nuevos dominios, es transparente.
La API Graph se convierte en la única fuente de verdad
Este es el punto de acción crítico del anuncio MC1048624. Microsoft lo dice explícitamente:
"After July 1, 2026, List serviceConfigurationRecords Graph API will be the only source of truth for your Accepted Domains' MX record value."
El problema de las automatizaciones actuales
Muchos scripts de aprovisionamiento construyen el MX por convención:
# ANTES: patrón predecible (DEJARÁ DE FUNCIONAR después de julio de 2026)
$domain = "captaindns.com"
$mx = $domain.Replace(".", "-") + ".mail.protection.outlook.com"
# Resultado: captaindns-com.mail.protection.outlook.com
Este patrón ya no funciona con mx.microsoft. El sufijo puede variar y no es predecible.
La solución: serviceConfigurationRecords
# DESPUÉS: usar la API Graph (OBLIGATORIO después de julio de 2026)
Connect-MgGraph -Scopes "Domain.Read.All"
$records = Get-MgDomainServiceConfigurationRecord -DomainId "captaindns.com"
$mxRecord = $records | Where-Object { $_.RecordType -eq "Mx" }
$mxValue = $mxRecord.AdditionalProperties.mailExchange
# Resultado: captaindns-com.o-v1.mx.microsoft (valor real, no deducido)
El endpoint REST correspondiente:
GET https://graph.microsoft.com/v1.0/domains/captaindns.com/serviceConfigurationRecords
Authorization: Bearer {token}
La respuesta JSON contiene el valor MX exacto en el campo mailExchange del objeto domainDnsMxRecord:
{
"@odata.type": "microsoft.graph.domainDnsMxRecord",
"isOptional": false,
"label": "captaindns.com",
"recordType": "Mx",
"supportedService": "Email",
"ttl": 3600,
"mailExchange": "captaindns-com.o-v1.mx.microsoft",
"preference": 0
}
Permisos necesarios: Domain.Read.All (mínimo). El usuario conectado debe tener el rol Administrador de nombres de dominio o Lector global.
Otros registros devueltos por la API
La API también devuelve los CNAME DKIM, el Autodiscover, el SPF y los SRV de Teams. Es la oportunidad de migrar todas tus automatizaciones DNS hacia esta fuente única:
| Tipo OData | Registro | Campos clave |
|---|---|---|
domainDnsMxRecord | MX | mailExchange, preference |
domainDnsTxtRecord | TXT (SPF) | text |
domainDnsCnameRecord | CNAME (DKIM, Autodiscover) | canonicalName |
domainDnsSrvRecord | SRV (Teams) | nameTarget, port, priority |
Preparar la transición: MTA-STS y TLS-RPT
En paralelo a DNSSEC y DANE, Microsoft recomienda desplegar MTA-STS y TLS-RPT para una cobertura completa de la seguridad del transporte de correo.
MTA-STS obliga a los servidores remitentes a usar TLS para entregar los correos, incluso si no soportan DANE. Es una red de seguridad complementaria:
_mta-sts.captaindns.com. 3600 IN TXT "v=STSv1; id=20260306T000000"
TLS-RPT te envía informes cuando un servidor remitente no logra establecer una conexión TLS con tu dominio:
_smtp._tls.captaindns.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Para la configuración detallada, consulta nuestras guías: MTA-STS para Microsoft 365 y TLS-RPT completo.
Plan de acción antes de julio de 2026
- Auditar tus automatizaciones: busca cualquier script, workflow de Terraform, playbook de Ansible o herramienta MSP que construya un MX a partir del patrón
mail.protection.outlook.com. Es la prioridad absoluta - Migrar a la API Graph: sustituye la construcción por convención por una llamada a
serviceConfigurationRecords. Pruébalo ahora mismo con un dominio de prueba - Activar DNSSEC en tus dominios: en tu registrar o proveedor DNS. Es el requisito previo para beneficiarte de DANE automático tras la migración
- Verificar tu configuración DNSSEC: usa
dig +dnssec captaindns.com SOApara confirmar que el flag AD está presente - Desplegar MTA-STS y TLS-RPT: completa el dispositivo de seguridad del transporte antes de la migración
- Seguir los anuncios de Microsoft: el MC1048624 ya se ha aplazado una vez. Sigue las actualizaciones en el centro de mensajes de Microsoft 365
FAQ
¿Mis dominios existentes se ven afectados por este cambio?
No, no de inmediato. El MC1048624 solo afecta a los nuevos Accepted Domains añadidos después del 1 de julio de 2026. Tus dominios existentes conservan su MX bajo mail.protection.outlook.com. Sin embargo, Microsoft prevé una migración progresiva de los dominios existentes después de esa fecha, sin un calendario preciso. Lo prudente es preparar tus automatizaciones desde ahora.
¿Qué pasa si mi automatización sigue usando el patrón antiguo después de julio de 2026?
Si añades un nuevo dominio a Exchange Online después de julio de 2026 y tu automatización construye el MX a partir de mail.protection.outlook.com, el MX será incorrecto. El flujo de correo no funcionará para ese dominio hasta que corrijas el valor MX para que coincida con el que se muestra en el centro de administración de Exchange o el que devuelve la API Graph.
¿Hay que activar DANE manualmente después de este cambio?
Para los nuevos dominios aprovisionados después de julio de 2026, si tu dominio tiene DNSSEC activo, la cadena DNSSEC se extiende automáticamente al MX bajo mx.microsoft y Microsoft publica los TLSA. No necesitas ninguna acción adicional para el DANE inbound. Para los dominios existentes que aún están bajo mail.protection.outlook.com, el procedimiento manual sigue siendo necesario.
¿Cuál es la diferencia entre DANE automático y DANE activado manualmente?
El resultado final es idéntico: un registro TLSA firmado con DNSSEC que autentica el certificado TLS de Exchange Online. La diferencia está en el camino. Con la activación manual (dominios existentes), tienes que iniciar la migración MX a través de PowerShell. Con los nuevos dominios después de julio de 2026, el MX ya está bajo mx.microsoft y los TLSA se publican automáticamente si DNSSEC está activo en tu dominio.
¿La API Graph serviceConfigurationRecords está disponible en las nubes soberanas?
Sí. El endpoint está disponible en la nube global, US Government L4, US Government L5 (DoD) y 21Vianet (China). Los permisos necesarios son idénticos: Domain.Read.All como mínimo.
¿Cómo puedo comprobar si mi dominio está preparado para DNSSEC?
Ejecuta dig +dnssec captaindns.com SOA y comprueba que el flag ad (Authenticated Data) aparece en la respuesta. Si no es así, activa DNSSEC en tu registrar. Consulta nuestra guía de activación de DNSSEC para el procedimiento detallado según tu proveedor DNS.
¿Este cambio afecta a SPF, DKIM y DMARC?
No. SPF (include:spf.protection.outlook.com), DKIM (CNAME hacia *.onmicrosoft.com) y DMARC no se ven afectados. Solo cambia el sufijo del registro MX. Los mecanismos de autenticación de correo siguen funcionando como antes.
¿Por qué Microsoft aplazó la fecha de febrero a julio de 2026?
Microsoft no ha comunicado una razón oficial. El aplazamiento se anunció el 2 de febrero de 2026 en una actualización del MC1048624 con la mención "Thank you for your patience". Es probable que los comentarios de la comunidad sobre la falta de preparación de las automatizaciones hayan motivado este plazo adicional.
Descarga las tablas comparativas
Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.
Glosario
- Accepted Domain: dominio personalizado añadido a un tenant de Microsoft 365 en el centro de administración de Exchange y configurado para recibir correos electrónicos.
- MC1048624: identificador del anuncio de Microsoft en el centro de mensajes de Microsoft 365 que describe la migración DNS de los MX hacia mx.microsoft.
- serviceConfigurationRecords: endpoint de la API Microsoft Graph que devuelve la lista de registros DNS necesarios para activar los servicios de Microsoft 365 en un dominio determinado.
- Brand TLD: dominio de primer nivel correspondiente a una marca (ej.:
.microsoft,.google,.amazon), gestionado por la empresa propietaria y normalmente firmado con DNSSEC. - DANE (DNS-based Authentication of Named Entities): mecanismo que vincula un certificado TLS a un nombre de dominio mediante un registro TLSA firmado con DNSSEC, eliminando la dependencia de las autoridades de certificación.
