Puntos clave
- DANE traslada la validación de certificados TLS de las autoridades de certificación externas al DNS, utilizando registros TLSA firmados con DNSSEC para establecer la confianza.
- Evita los ataques de degradación de STARTTLS al exigir conexiones cifradas, en lugar de permitir una transición silenciosa al texto sin cifrar.
- DANE reduce el riesgo de que se emitan certificados erróneos o que se vean comprometidos, al permitir que los propietarios de los dominios definan exactamente qué certificados son válidos.
- El protocolo DNSSEC es imprescindible para que DANE funcione. Sin él, los registros TLSA no pueden considerarse fiables ni verificarse.
- Aunque es muy eficaz, el uso de DANE sigue siendo limitado, por lo que a menudo se utiliza junto con MTA-STS y se complementa con DMARC para garantizar una seguridad completa del correo electrónico.
La autenticación de entidades con nombre basada en DNS (DANE) es un método para verificar certificados TLS mediante el DNS. Se basa en los registros DNSSEC y TLSA para garantizar que las conexiones cifradas no sean interceptadas ni se vean comprometidas.
El problema para el que se diseñó DANE
El envío de correos electrónicos a través del Protocolo simple de transferencia de correo (SMTP) suele utilizar STARTTLS para cifrar las conexiones. El problema es que STARTTLS es oportunista. Esto significa que, si el cifrado falla, la conexión puede volver a transmitirse en texto sin cifrar. Esta degradación puede producirse de forma silenciosa, lo que facilita a los atacantes aprovechar este comportamiento para interceptar los correos electrónicos.
La ruta habitual:

La ruta del ataque:

El TLS tradicional presenta además un segundo problema:
Los certificados TLS se validan a través de autoridades de certificación (CA) comerciales. Estas CA pueden verse comprometidas o emitir certificados de forma incorrecta. Si un atacante obtiene un certificado válido para un dominio, puede suplantar la identidad de ese servidor.
Estas dos cuestiones hacen que los ataques de intermediario sean posibles incluso cuando se utiliza TLS. DANE resuelve ambos problemas trasladando la validación de certificados al DNS, protegido por DNSSEC. De este modo, se elimina la dependencia de las autoridades de certificación externas y se evitan los ataques de degradación silenciosa.
¿Qué es DANE?
DANE es un protocolo de seguridad de Internet que permite a los propietarios de dominios publicar información sobre sus certificados TLS directamente en el DNS mediante registros TLSA.
Estos registros están protegidos por DNSSEC, lo que garantiza:
- Los registros no pueden modificarse durante el tránsito
- El cliente puede comprobar que la respuesta es auténtica
En lugar de confiar en una autoridad de certificación externa, el cliente comprueba la validez del certificado comparándolo con lo que el propio dominio ha publicado.
Cómo funciona DANE: paso a paso
Paso 1: El propietario del dominio publica un registro TLSA en el DNS
El administrador del dominio crea un registro de recursos TLSA (Transport Layer Security Authentication) y lo publica en su zona DNS. Este registro contiene los datos del certificado que los clientes utilizarán posteriormente para la verificación.

Paso 2: La zona DNS se firma mediante DNSSEC
DNSSEC (Extensiones de seguridad del DNS) firma criptográficamente toda la zona DNS, incluido el nuevo registro TLSA. De este modo se crea una cadena de confianza desde la zona raíz del DNS hasta los registros del dominio, lo que impide cualquier manipulación.

Paso 3: Un cliente se conecta al servidor y consulta el registro TLSA
Cuando un cliente (como un servidor de correo o un navegador) desea establecer una conexión TLS con el servidor, primero consulta el DNS para obtener el registro TLSA del dominio.

Paso 4: El cliente valida la respuesta DNS mediante DNSSEC
Antes de dar por válido el registro TLSA, el resolutor del cliente valida las firmas DNSSEC siguiendo la cadena de confianza.

Paso 5: El servidor presenta su certificado TLS
Durante el protocolo de enlace TLS, el servidor envía su certificado TLS al cliente para demostrar su identidad mediante la presentación de su cadena de certificados.

Paso 6: El cliente compara el certificado con el registro TLSA
Esta es la parte más importante de la comprobación DANE. En este paso, el cliente extrae la parte pertinente del certificado del servidor y la compara con los datos almacenados en el registro TLSA.

Paso 7: Si coinciden, se establece la conexión
Cuando los datos del certificado coinciden con el registro TLSA, la validación DANE se realiza correctamente, con lo que se establece con éxito la conexión TLS.

Paso 8: Si no coinciden, se rechaza la conexión
Cuando el certificado no coincide con el registro TLSA, el cliente lo interpreta como un fallo de seguridad y se niega a completar el protocolo de enlace TLS. Esto impide, desde el principio, que los ataques de intermediario tengan éxito.

¿Qué es un registro TLSA?
Un registro TLSA es un registro DNS que utiliza DANE para definir cómo debe validarse un certificado TLS.
The format looks like this: <usage> <selector> <matching-type> <certificate-data>
Ejemplo de registro TLSA:
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)
Cada campo tiene una función específica:
- Uso: Define cómo debe verificarse y considerarse fiable el certificado
- Selector: especifica qué parte del certificado se utiliza (certificado completo o clave pública)
- Tipo de coincidencia: indica cómo se almacenan los datos (valor completo o hash)
- Datos del certificado: el valor real o el hash con el que se va a comparar
Valores de uso del certificado
Hay cuatro tipos de uso:
0 (PKIX-TA): Restricción de ancla de confianza mediante PKI tradicional
1 (PKIX-EE): Certificado de entidad final validado mediante PKI
2 (DANE-TA): Ancla de confianza definida por DNS
3 (DANE-EE): Certificado de entidad final definido directamente en DNS
En lo que respecta a la seguridad del correo electrónico, los niveles de uso 2 y 3 son los más relevantes, ya que eliminan la dependencia de las autoridades de certificación públicas.
Dónde se publican los registros TLSA
Los registros TLSA se publican en subdominios específicos basados en servicios. En el caso del SMTP, suelen tener el siguiente formato: _25._tcp.mail.example.com
DANE para el correo electrónico: cómo protege el protocolo SMTP
DANE ayuda al servidor emisor a verificar la autenticidad de los certificados del servidor receptor. Esta verificación contribuye a prevenir los ataques de degradación de STARTTLS y los ataques de intermediario, lo que ayuda a proteger las comunicaciones SMTP.
DANE aplica el protocolo TLS para la transmisión de correo electrónico, lo que impide que los mensajes se envíen en texto sin cifrar o que sean manipulados durante el tránsito.
Por qué DANE requiere DNSSEC
DANE depende totalmente de la integridad de los registros DNS. Sin DNSSEC, los registros TLSA podrían ser falsificados y los atacantes podrían redirigir a los clientes hacia certificados maliciosos. Así es como funciona esta dependencia: DNSSEC firma las respuestas DNS utilizando claves criptográficas. Esto permite al cliente verificar que la respuesta no ha sido alterada y que los datos son auténticos. Por lo tanto, sin DNSSEC, DANE no ofrece ninguna ventaja real en materia de seguridad.
¿Quién utiliza DANE?
La adopción de DANE varía a nivel mundial, registrándose las tasas más altas entre los organismos gubernamentales europeos y las organizaciones de Estados Unidos. Su uso está aumentando en los sectores en los que la confidencialidad del correo electrónico es fundamental. Entre los usuarios habituales de DANE se encuentran:
- Los administradores de correo electrónico como medida de autenticación y seguridad
- Organismos públicos de países europeos y de Estados Unidos, con el fin de garantizar la seguridad de las comunicaciones por correo electrónico en el sector público (por ejemplo: la empresa alemana T-Online es una de las primeras en adoptar DANE en la práctica)
- Proveedores de correo electrónico como Comcast, Protonmail, etc.
- Microsoft ha anunciado que, a partir de julio de 2024, admitirá el protocolo SMTP entrante DANE.
DANE frente a MTA-STS: ¿En qué se diferencian?
Tanto DANE como el Agente de Transferencia de Correo – Seguridad de Transporte Estricta (MTA-STS) están diseñados para proteger las conexiones SMTP, pero utilizan modelos de confianza diferentes. Mientras que MTA-STS se basa en HTTPS y en las autoridades de certificación (CA), DANE se basa en DNSSEC y en el DNS. Estas son algunas de las diferencias clave entre ambos:
| Característica | DANE | MTA-STS |
|---|---|---|
| Se requiere DNSSEC | Sí | No |
| Ubicación de la póliza | DNS | Archivo de políticas HTTPS |
| Dependencia de CA | Opcional | Requerido |
| Protección contra la rebaja de calificación | Fuerte | Fuerte |
| Adopción | Bajo | Alta |
Para obtener más información sobre MTA-STS, lee nuestra guía completa sobre qué es MTA-STS. Para saber cómo implementar MTA-STS en tu dominio, consulta nuestra guía de implementación de MTA-STS.
Cómo funciona TLS-RPT junto con DANE y MTA-STS
TLS-RPT es un protocolo de notificación que ofrece visibilidad sobre los fallos en la negociación de TLS y los problemas de entrega provocados por configuraciones erróneas de DANE o MTA-STS. Se puede considerar TLS-RPT como una capa de visibilidad que se superpone a DANE y MTA-STS (capas de seguridad). Aunque tanto DANE como MTA-STS contribuyen a garantizar el uso de TLS para proteger las transmisiones de correo electrónico, existe una laguna importante en cuanto a la claridad sobre cuándo o por qué falla la entrega.
Ahí es donde entra en juego TLS-RPT. El protocolo de informes TLS para SMTP (TLS-RPT) envía diariamente a los servidores receptores informes de retroalimentación agregados sobre:
- Errores en la negociación TLS
- Problemas con la validación de certificados
- Discrepancias en las políticas (MTA-STS o DANE)
- Errores de entrega debidos a la aplicación de TLS
Cómo comprobar si tu dominio tiene un registro DANE/TLSA
Para comprobar la configuración de DANE, debes verificar lo siguiente:
- Si existe un registro TLSA para tu servidor de correo
- Si DNSSEC está habilitado y es válido
- Si el certificado coincide con el registro TLSA
Puedes utilizar el verificador de registros DANE gratuito de PowerDMARC para comprobar rápidamente tu configuración.
Cómo implementar DANE para el correo electrónico
Para implementar DANE en tu correo electrónico, puedes seguir los pasos que se indican a continuación:
Paso 1: Habilitar DNSSEC
DANE no funciona sin DNSSEC, por lo que el primer paso es configurar DNSSEC a través de tu proveedor de DNS o registrador. Puedes comprobar si ya lo tienes configurado para tu dominio utilizando nuestra herramienta de verificación de DNSSEC.
Paso 2: Obtener los datos del certificado TLS
Extrae el certificado o el hash de la clave pública de tu servidor de correo.
Paso 3: Crear el registro TLSA
Define el uso, el selector y el tipo de coincidencia correctos y, a continuación, publica tu registro TLSA en el subdominio correspondiente.
Paso 4: Validar el registro
Utiliza nuestra herramienta de comprobación DANE para verificar que el registro es correcto y que DNSSEC funciona correctamente.
Paso 5: Supervisar los cambios en los certificados
Cuando se renueve o modifique su certificado TLS, deberá actualizar el registro TLSA. De no hacerlo, podría interrumpirse el envío de correo electrónico.
Palabras finales
Si aún no proteges la capa de transporte de tu correo electrónico mediante MTA-STS, DANE puede ser un excelente punto de partida. Especialmente en sectores que manejan datos confidenciales, como las instituciones financieras y los organismos del sector público, es fundamental proteger los mensajes contra la interceptación.
Sin embargo, DANE no puede impedir los ataques de suplantación de identidad o de phishing que utilicen tu propio nombre de dominio. Para ello, DMARC es imprescindible. ¿Quieres una solución integral de seguridad de dominios que gestione la autenticación de tu correo electrónico de principio a fin? Solicita hoy mismo una demostración con nuestros expertos.
Preguntas frecuentes
¿Es DANE lo mismo que DNSSEC?
No, DANE y DNSSEC no son lo mismo, aunque DANE necesita DNSSEC para funcionar. DNSSEC protege los registros DNS, mientras que DANE utiliza DNSSEC para publicar de forma segura la información de los certificados.
¿Necesito tanto DANE como MTA-STS?
No necesariamente, pero el uso de ambos ofrece una mayor compatibilidad y una protección más sólida. En general, MTA-STS tiene una tasa de adopción más alta que DANE.
¿Sustituye DANE a SPF, DKIM o DMARC?
No. DANE protege la capa de transporte , mientras que SPF, DKIM y DMARC se encargan de la autenticación del correo electrónico y la prevención del suplantación de identidad. Para lograr una seguridad completa del correo electrónico, es necesario un enfoque multicapa que combine todos los protocolos con una supervisión y actualizaciones constantes.
¿Qué ocurre si mi registro TLSA es incorrecto?
Si tu registro TLSA es incorrecto, los servidores de correo que aplican DANE rechazarán las conexiones. Esto puede provocar fallos en la entrega del correo electrónico. Es importante que compruebes tu configuración de DANE (incluida la validez de tu registro TLSA) para solucionar cualquier problema.
¿Qué proveedores de correo electrónico son compatibles con DANE?
El soporte para DANE varía en todo el mundo. Algunos proveedores europeos y organizaciones centradas en la seguridad lo exigen, pero su adopción a nivel mundial sigue siendo limitada.
- ¿Qué es DANE? Explicación de la autenticación de entidades con nombre basada en el DNS (2026) - 20 de abril de 2026
- Introducción a la seguridad de las VPN: prácticas recomendadas para proteger tu privacidad - 14 de abril de 2026
- Reseña de MXtoolbox: características, opiniones de los usuarios, ventajas y desventajas (2026) - 14 de abril de 2026


