Desplegar DANE para Exchange Online y Microsoft 365

Q: ¿Cuánto tiempo tarda la activación de DANE en Exchange Online?

La activación se realiza en dos fases. La migración MX ( Enable-DnssecForVerifiedDomain ) tarda unos minutos, pero la propagación DNS depende de tus TTL. La publicación TLSA ( Enable-SmtpDaneInbound ) tarda de 15 a 30 minutos. Calcula unas horas en total, principalmente por las propagaciones DNS.

Por CaptainDNS
Publicado el 24 de febrero de 2026

Esquema del flujo DANE entre un remitente SMTP y Exchange Online con DNSSEC y TLSA

TL;DR

Microsoft 365 soporta DANE inbound (SMTP) desde marzo de 2024 para Exchange Online, con publicación automática de los registros TLSA
El requisito principal es DNSSEC: tu dominio debe estar firmado y los registros DS publicados en tu registrar
La activación migra tu MX de mail.protection.outlook.com a o-v1.mx.microsoft, un dominio firmado con DNSSEC. Microsoft publica automáticamente los TLSA, no tienes que gestionarlos
Google Workspace no soporta DANE inbound, solo el DANE outbound (verificación) está activo
Verifica tu despliegue con nuestro inspector DANE/TLSA que prueba DNSSEC, TLSA y la cadena de certificados en un solo clic

Microsoft anunció la disponibilidad general de DANE inbound para Exchange Online en marzo de 2024. En la práctica, los dominios alojados en Microsoft 365 ahora pueden recibir correos protegidos por DANE: los servidores remitentes que verifican DANE/TLSA validan el certificado TLS de Exchange Online a través de DNS firmado, en lugar de confiar ciegamente en las autoridades de certificación.

Pero activar DANE en Microsoft 365 no se hace con un solo botón. El requisito fundamental es DNSSEC: sin una zona DNS firmada, los registros TLSA publicados por Microsoft no tienen ningún valor. Y la configuración de DNSSEC depende de tu registrar y de tu proveedor DNS, no de Microsoft.

Esta guía cubre el procedimiento completo: verificar los requisitos, activar DNSSEC en tu dominio, activar DANE en Exchange Online y validar el despliegue de extremo a extremo. También compara las diferencias con Google Workspace (que no soporta DANE inbound) y los servidores on-premise como Postfix o Exchange Server.

Público objetivo: administradores de Microsoft 365, IT managers de empresa, MSPs que gestionan tenants M365. Para los fundamentos de DANE y TLSA, consulta el primer artículo de esta serie (enlace al final de la página).

¿Cómo funciona DANE con Exchange Online?

Cuando un servidor remitente envía un correo hacia un dominio alojado en Exchange Online y protegido por DANE:

Resolución MX: el servidor resuelve el MX de captaindns.com y obtiene captaindns-com.o-v1.mx.microsoft (el nuevo formato MX para dominios DANE)
Verificación DNSSEC: verifica que la respuesta DNS está firmada con DNSSEC. La cadena de confianza pasa por root → .microsoft → mx.microsoft → o-v1.mx.microsoft, completamente firmada
Consulta TLSA: solicita el registro TLSA en _25._tcp.captaindns-com.o-v1.mx.microsoft
Conexión TLS: se conecta en STARTTLS en el puerto 25 y compara el certificado presentado por Exchange Online con el hash TLSA
Entrega: si todo coincide, el correo se entrega. Si no, se rechaza o se aplaza según la política del servidor remitente

Un punto importante: outlook.com no está firmado con DNSSEC. Por eso Microsoft creó la infraestructura mx.microsoft bajo el TLD .microsoft, que está firmado con DNSSEC de extremo a extremo. La activación de DANE migra automáticamente tu MX del antiguo formato mail.protection.outlook.com al nuevo o-v1.mx.microsoft.

La diferencia clave con un servidor self-hosted (Postfix, Exchange Server on-premise): Microsoft gestiona la migración MX, los registros TLSA y los certificados TLS. No publicas tú mismo los TLSA. Tu única responsabilidad es activar DNSSEC en tu dominio.

Flujo DANE entre un servidor remitente y Exchange Online

Requisitos antes de activar DANE

Dominio con DNSSEC activo

DANE depende completamente de DNSSEC. Sin firmas DNS válidas, los registros TLSA son ignorados por los servidores remitentes. Verifica el estado actual:

dig +dnssec captaindns.com SOA +short

Si la respuesta incluye un flag ad (Authenticated Data) en el header, tu dominio está firmado. Si no, debes activar DNSSEC.

Registrar compatible con DNSSEC

No todos los registrars soportan DNSSEC de la misma manera:

Registrar	DNSSEC	Método
Cloudflare	Automático	Un clic en el dashboard, DS publicado automáticamente
OVH	Soportado	Activación manual, DS a publicar en el registrant
Gandi	Soportado	Clave KSK a proporcionar, DS publicado automáticamente
GoDaddy	Soportado	Activación manual en los ajustes DNS avanzados
Route 53 (AWS)	Soportado	Creación de la cadena KSK/ZSK, DS a publicar manualmente

Si tu registrar no soporta DNSSEC, tendrás que migrar tu DNS a un proveedor compatible antes de poder activar DANE.

MX apuntando a Exchange Online

Antes de activar DANE, tus MX apuntan a *.mail.protection.outlook.com. Verifica:

dig MX captaindns.com +short

El resultado debe parecerse a:

0 captaindns-com.mail.protection.outlook.com.

Al activar DANE, Microsoft te pedirá migrar este MX hacia un nuevo formato: captaindns-com.o-v1.mx.microsoft. Este nuevo dominio está alojado bajo el TLD .microsoft, firmado con DNSSEC de extremo a extremo. Como el antiguo outlook.com no está firmado con DNSSEC, la cadena de confianza sería imposible sin esta migración.

Si tus MX pasan por un relay de terceros (Proofpoint, Mimecast, Barracuda), DANE protegerá únicamente el último salto hacia Exchange Online. El relay en sí también debe soportar DANE para una protección de extremo a extremo.

Activar DNSSEC en tu dominio

El procedimiento varía según tu proveedor DNS. Aquí están los pasos generales comunes.

Si tu DNS está en Cloudflare

Inicia sesión en el dashboard de Cloudflare
Selecciona tu dominio
Ve a DNS → DNSSEC
Haz clic en Enable DNSSEC
Cloudflare muestra la información DS a publicar en tu registrar
Si Cloudflare también es tu registrar, es automático

Cloudflare firma la zona y publica el DS en pocos minutos. Verifica después:

dig +dnssec captaindns.com DNSKEY +short

Si tu DNS está en otro proveedor

El proceso se divide en dos pasos:

Activar la firma de zona en tu proveedor DNS (generación de claves KSK/ZSK, firma automática)
Publicar el registro DS en tu registrar (la clave DS hace el enlace entre tu zona firmada y la zona padre)

El DS debe coincidir exactamente con la clave KSK de tu zona. Un error en el DS romperá la resolución DNS de tu dominio. Prueba siempre en un entorno de staging o con un subdominio primero.

Guía en 4 pasos para desplegar DANE en Microsoft 365

Activa la firma DNSSEC en tu proveedor DNS y publica el registro DS en tu registrar. Verifica con dig +dnssec captaindns.com SOA que el flag ad aparece en la respuesta. Calcula de 24 a 48 horas para la propagación completa del DS.
Reduce el TTL de tu MX actual al mínimo (no menos de 30 segundos) y espera la expiración del TTL anterior. Ejecuta Enable-DnssecForVerifiedDomain -DomainName captaindns.com en Exchange Online PowerShell. El comando devuelve el nuevo valor MX: captaindns-com.o-v1.mx.microsoft. Añade este nuevo MX con prioridad 20, verifica que funciona, luego pásalo a prioridad 0 y elimina el antiguo MX mail.protection.outlook.com.
Una vez migrado el MX y en funcionamiento, ejecuta Enable-SmtpDaneInbound -DomainName captaindns.com. Microsoft genera y publica automáticamente los registros TLSA en _25._tcp.captaindns-com.o-v1.mx.microsoft. La propagación tarda de 15 a 30 minutos.
Usa dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft para confirmar la presencia del TLSA. Prueba la conexión TLS con openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Valida todo con la herramienta de verificación DANE/TLSA de CaptainDNS.

Activar DANE en Exchange Online

La activación se realiza en dos fases distintas: primero la migración DNSSEC (nuevo MX), luego la activación DANE (publicación TLSA). El procedimiento se gestiona a través de Exchange Online PowerShell.

Fase 1: migración MX hacia mx.microsoft

Esta primera fase activa DNSSEC y migra tu MX hacia la infraestructura mx.microsoft, firmada con DNSSEC.

# Conexión a Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@captaindns.com

# Activar DNSSEC para el dominio
Enable-DnssecForVerifiedDomain -DomainName captaindns.com

El comando devuelve el nuevo valor MX:

Result	DnssecMxValue
`Success`	`captaindns-com.o-v1.mx.microsoft`

Procedimiento de migración MX:

Reducir el TTL de tu MX actual al mínimo (no menos de 30 segundos)
Esperar la expiración del TTL anterior
Añadir el nuevo MX captaindns-com.o-v1.mx.microsoft con prioridad 20
Verificar que el nuevo MX recibe correo correctamente
Cambiar las prioridades: nuevo MX a 0, antiguo a 30
Eliminar el antiguo MX captaindns-com.mail.protection.outlook.com
Establecer el TTL del nuevo MX a 3600 segundos

Si usas MTA-STS, pasa la política a modo testing y añade el nuevo hostname en el archivo de política antes de la migración. Restaura el modo enforce una vez finalizado.

Fase 2: activación DANE (publicación TLSA)

Una vez migrado el MX y en funcionamiento:

# Activar DANE (publicación de los TLSA)
Enable-SmtpDaneInbound -DomainName captaindns.com

# Verificar el estado completo
Get-DnssecStatusForVerifiedDomain -DomainName captaindns.com

El estado pasa por varias fases:

Estado	Significado
`DnssecFeatureNotEnabled`	DNSSEC no activado
`DnssecValidationPending`	Microsoft verifica DNSSEC en tu dominio
`DnssecEnabled`	DNSSEC validado, MX migrado, TLSA aún no publicado
`DaneEnabled`	DANE activo, TLSA publicado y funcional
`DnssecValidationFailed`	Fallo en la validación DNSSEC, verifica tu DS

Plazos

Migración MX: unos minutos para el comando, luego el tiempo de propagación DNS (variable según el TTL)
Publicación TLSA: de 15 a 30 minutos después de Enable-SmtpDaneInbound
De extremo a extremo: calcula unas horas, principalmente por las propagaciones DNS

Verificar el despliegue

Verificar los TLSA con dig

dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft +short

Resultado esperado:

3 1 1 A4B5C6D7E8F9...  (hash SHA-256 del certificado Exchange Online)

Microsoft publica varios registros TLSA 3 1 1 (DANE-EE, SPKI, SHA-256) y 3 1 2 (DANE-EE, SPKI, SHA-512) para asegurar la redundancia. Es normal que algunos no coincidan con el certificado actual: basta con que uno coincida para validar DANE.

Verificar la conexión TLS

openssl s_client -starttls smtp \
  -connect captaindns-com.o-v1.mx.microsoft:25 \
  -servername captaindns-com.o-v1.mx.microsoft

Verifica que el certificado presentado corresponde a uno de los hash TLSA publicados.

Verificar con CaptainDNS

El inspector DANE/TLSA mencionado en el TL;DR prueba automáticamente:

La presencia y validez de DNSSEC en tu dominio
La resolución MX hacia o-v1.mx.microsoft
La presencia de los registros TLSA bajo la zona firmada
La correspondencia entre el TLSA y el certificado TLS

Matriz de compatibilidad DANE por proveedor de correo

Errores comunes y soluciones

DNSSEC validation failed

Causa: el registro DS en tu registrar no corresponde a la clave KSK de tu zona.

Solución: verifica la correspondencia entre el DS publicado y la clave KSK con dig DNSKEY captaindns.com +short y compara con el DS en tu registrar. Regenera el DS si es necesario.

TLSA no publicado tras la activación

Causa: el MX no se migró a o-v1.mx.microsoft, Microsoft no pudo validar DNSSEC, o la propagación aún está en curso.

Solución: verifica que tu MX apunta a *.o-v1.mx.microsoft y que el antiguo mail.protection.outlook.com está eliminado. Verifica el estado con Get-DnssecStatusForVerifiedDomain. Si el estado es DnssecValidationFailed, corrige tu configuración DNSSEC antes de reintentar.

Antiguo MX no eliminado

Causa: el antiguo MX mail.protection.outlook.com coexiste con el nuevo o-v1.mx.microsoft, lo que impide que DANE funcione correctamente.

Solución: sigue el procedimiento de migración MX completo. El nuevo MX debe estar en prioridad 0 y el antiguo debe eliminarse antes de activar Enable-SmtpDaneInbound.

Relay de terceros bloqueando DANE

Causa: un servicio de filtrado (Proofpoint, Mimecast) intercepta los MX y no soporta DANE.

Solución: DANE solo protege el último salto SMTP. Si tu relay no soporta DANE, tendrás que elegir entre el filtrado de terceros y DANE. Algunos relays están empezando a soportar DANE en 2025-2026, consulta con tu proveedor.

Correos rechazados por servidores estrictos

Causa: tu DANE está mal configurado y los servidores remitentes que aplican una política DANE estricta rechazan los mensajes.

Solución: utiliza la metodología de diagnóstico descrita en nuestra guía de troubleshooting DANE/TLSA (enlace al final de la página) para diagnosticar el error exacto. Verifica en primer lugar la cadena DNSSEC y la correspondencia TLSA/certificado.

Microsoft 365 vs Google Workspace vs on-premise

Funcionalidad	Microsoft 365	Google Workspace	On-premise (Postfix)
DANE inbound	Sí (desde marzo 2024)	No	Sí (nativo)
DANE outbound	Sí	Sí	Sí (nativo)
Migración MX	Sí (`o-v1.mx.microsoft`)	N/A	No (MX sin cambios)
Gestión TLSA	Automática (Microsoft)	N/A	Manual
Gestión certificado	Automática (Microsoft)	N/A	Manual (Let's Encrypt, etc.)
Requisitos	DNSSEC + migración MX	-	DNSSEC + TLSA + certificado
Complejidad	Media (DNSSEC + migración)	N/A	Alta (todo por gestionar)
Rotación certificado	Transparente	N/A	Deploy-hook necesario

Google Workspace

Google soporta DANE en salida (verificación de los TLSA de los destinatarios) desde 2023, pero no soporta DANE en entrada. Los dominios alojados en Google Workspace no pueden publicar TLSA a través de Google. Si usas Google Workspace y quieres DANE inbound, actualmente no existe ninguna solución.

Exchange Server on-premise

Para un servidor Exchange on-premise (2016, 2019), DANE funciona como para cualquier servidor SMTP autoalojado:

Gestionas tú mismo DNSSEC, los TLSA y los certificados
La configuración es similar a Postfix (consulta nuestro tutorial Postfix/Bind/Let's Encrypt en las guías relacionadas)
Debes automatizar la rotación TLSA durante la renovación de los certificados

Complementar DANE con MTA-STS y TLS-RPT

DANE y MTA-STS son complementarios, no competidores:

DANE verifica el certificado a través de DNS/DNSSEC (robusto, pero requiere DNSSEC)
MTA-STS impone TLS mediante una política HTTPS (más simple, pero depende de las CA)
TLS-RPT reporta los fallos TLS y DANE por correo diario

Microsoft 365 soporta los tres protocolos. Para una seguridad de correo máxima:

Activa DANE (esta guía)
Publica una política MTA-STS con nuestro generador MTA-STS
Activa TLS-RPT para recibir los informes de fallos

FAQ

¿Microsoft 365 soporta DANE?

Sí. Microsoft lanzó el soporte DANE inbound para Exchange Online en disponibilidad general en marzo de 2024. La activación migra tu MX de mail.protection.outlook.com a o-v1.mx.microsoft, un dominio bajo el TLD .microsoft firmado con DNSSEC. Microsoft publica después automáticamente los registros TLSA.

¿Hay que publicar los registros TLSA manualmente con Microsoft 365?

No. A diferencia de un servidor self-hosted, Microsoft gestiona automáticamente la publicación y la rotación de los registros TLSA bajo la zona o-v1.mx.microsoft. Tu responsabilidad es activar DNSSEC en tu dominio y migrar el MX al nuevo formato.

¿Google Workspace soporta DANE inbound?

No. Google Workspace solo soporta DANE en salida (verificación de los TLSA de los destinatarios). No existe forma de activar DANE inbound para los dominios alojados en Google Workspace.

¿Cuánto tiempo tarda la activación de DANE en Exchange Online?

La activación se realiza en dos fases. La migración MX (Enable-DnssecForVerifiedDomain) tarda unos minutos, pero la propagación DNS depende de tus TTL. La publicación TLSA (Enable-SmtpDaneInbound) tarda de 15 a 30 minutos. Calcula unas horas en total, principalmente por las propagaciones DNS.

¿Qué ocurre si DNSSEC falla en mi dominio?

Si DNSSEC falla (firma expirada, DS incorrecto), la resolución DNS de tu dominio se verá comprometida. Los servidores DANE-aware no podrán validar los TLSA y rechazarán o aplazarán los correos. Por eso la monitorización de DNSSEC es crítica.

¿DANE funciona con un relay de terceros (Proofpoint, Mimecast)?

Parcialmente. DANE solo protege el último salto SMTP. Si tus MX apuntan a un relay de terceros que luego retransmite hacia Exchange Online, DANE solo protege el salto relay → Exchange. El salto remitente → relay no está cubierto salvo que el relay también soporte DANE.

¿Se pueden usar DANE y MTA-STS a la vez?

Sí, y es lo recomendado. DANE verifica el certificado a través de DNS/DNSSEC, MTA-STS impone TLS mediante HTTPS. Los dos protocolos son complementarios. Microsoft 365 soporta ambos simultáneamente.