DANE/TLSA: la guía completa para autenticar certificados de correo electrónico mediante DNS
Por CaptainDNS
Publicado el 21 de febrero de 2026
- DANE vincula los certificados TLS a los nombres de dominio mediante registros DNS TLSA firmados con DNSSEC, eliminando la dependencia de las autoridades de certificación
- El uso DANE-EE con SPKI y SHA-256 (
3 1 1) es el gold standard para proteger SMTP - DNSSEC es un requisito indispensable: sin una zona firmada, los registros TLSA se ignoran
- DANE y MTA-STS son complementarios: DANE verifica el certificado a través del DNS, MTA-STS impone TLS a través de HTTPS
- TLS-RPT (RFC 8460) permite monitorizar los fallos de DANE en producción y anticiparse a los problemas de rotación
Cuando un servidor SMTP envía un correo electrónico, ¿cómo sabe que el servidor destinatario es el correcto? Por defecto, no lo sabe. STARTTLS cifra la conexión de forma oportunista, pero no verifica ni la identidad del servidor ni la autenticidad del certificado. Un atacante posicionado en la red puede interceptar la conexión, presentar un certificado falso y leer tus mensajes.
DANE (DNS-based Authentication of Named Entities) resuelve este problema publicando directamente en el DNS la información del certificado esperado. El servidor emisor consulta el registro TLSA, verifica que el certificado presentado coincide y rechaza la conexión en caso de discrepancia. La clave: DNSSEC firma esta información, garantizando que no ha sido falsificada.
Esta guía cubre el funcionamiento de DANE, la anatomía de un registro TLSA, los usos recomendados para el correo electrónico, el despliegue paso a paso, la complementariedad con MTA-STS y la monitorización con TLS-RPT. Está dirigida a administradores de correo, ingenieros de infraestructura y DevOps que gestionan servidores de correo.
¿Cómo funciona DANE?
El problema del TLS oportunista
SMTP fue diseñado sin cifrado. STARTTLS se añadió después (RFC 3207) para permitir a los servidores negociar una conexión TLS. Pero esta negociación es oportunista: si el servidor remoto no soporta TLS, el mensaje se envía en texto plano. Peor aún, un atacante puede suprimir el comando STARTTLS de la respuesta SMTP (ataque downgrade) y forzar el envío sin cifrado.
Incluso cuando se negocia TLS, el servidor emisor no verifica el certificado por defecto. Acepta cualquier certificado, incluido uno autofirmado presentado por un atacante. El cifrado existe, pero falta la autenticación.
DANE: el certificado en el DNS
DANE invierte la lógica. En lugar de confiar en una autoridad de certificación (CA) externa, el propietario del dominio publica en el DNS la huella del certificado que su servidor debe presentar. El servidor emisor:
- Resuelve el MX del dominio destinatario
- Busca el registro TLSA asociado al servidor MX
- Verifica la firma DNSSEC de la respuesta
- Establece la conexión TLS y compara el certificado presentado con la huella TLSA
- Rechaza la conexión si el certificado no coincide
La cadena de confianza DNSSEC
DANE solo funciona si la zona DNS está firmada con DNSSEC. Sin DNSSEC, un atacante podría falsificar el registro TLSA y presentar su propia huella de certificado. La cadena de confianza va desde la raíz DNS hasta el registro TLSA:
. (raíz) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA
Cada eslabón está firmado por la zona padre. Si un solo eslabón se rompe (zona no firmada, firma caducada), la validación DNSSEC falla y el registro TLSA se ignora.
Anatomía de un registro TLSA
Un registro TLSA se compone de cuatro campos:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
El nombre sigue la convención _puerto._protocolo.hostname. Para un servidor SMTP en el puerto 25, es _25._tcp.mail.captaindns.com.
Uso (campo 1): ¿qué verificar?
| Valor | Nombre | Descripción |
|---|---|---|
| 0 | PKIX-TA | Verifica el certificado CA + la cadena CA clásica |
| 1 | PKIX-EE | Verifica el certificado del servidor + la cadena CA clásica |
| 2 | DANE-TA | Verifica el certificado CA, sin exigir la cadena CA clásica |
| 3 | DANE-EE | Verifica el certificado del servidor directamente, sin CA |
Selector (campo 2): ¿qué parte del certificado?
| Valor | Nombre | Descripción |
|---|---|---|
| 0 | Cert | Certificado completo (DER) |
| 1 | SPKI | Solo la clave pública (SubjectPublicKeyInfo) |
SPKI (1) es lo recomendado: la clave pública no cambia cuando renuevas el certificado con el mismo par de claves. Esto simplifica la rotación.
Matching type (campo 3): formato de los datos
| Valor | Nombre | Descripción |
|---|---|---|
| 0 | Full | Datos brutos completos |
| 1 | SHA-256 | Hash SHA-256 (32 bytes, 64 caracteres hex) |
| 2 | SHA-512 | Hash SHA-512 (64 bytes, 128 caracteres hex) |
SHA-256 (1) es el estándar: compacto, resistente a colisiones, compatible en todas partes.
¿Qué uso TLSA elegir?
DANE-EE (uso 3): la opción recomendada para SMTP
La RFC 7672 (sección 3.1) recomienda DANE-EE para el correo. La combinación 3 1 1 (DANE-EE + SPKI + SHA-256) es el gold standard:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
Ventajas de DANE-EE:
- Sin dependencia de las CA: controlas completamente la confianza
- Se aceptan certificados autofirmados: la CA no necesita ser reconocida
- Rotación simplificada: con SPKI, el hash no cambia si conservas la misma clave
- Sin verificación de la cadena: solo importa el certificado end-entity
DANE-TA (uso 2): ¿cuándo usar la CA?
DANE-TA (2 0 1 o 2 1 1) es útil cuando gestionas varios servidores firmados por la misma CA interna. En lugar de publicar un TLSA por servidor, publicas la huella de la CA y se aceptan todos los certificados firmados por ella.
Inconveniente: si la CA se ve comprometida, todos los servidores quedan comprometidos.
PKIX-EE y PKIX-TA (usos 1 y 0): casos particulares
Estos usos combinan la verificación DANE con la validación CA clásica. Se utilizan raramente para SMTP porque añaden complejidad sin un beneficio claro respecto a DANE-EE.
DANE para el correo electrónico: RFC 7672
La RFC 7672 adapta DANE al contexto SMTP. Algunas especificidades:
STARTTLS y el puerto 25
Para el correo electrónico, DANE se aplica en el puerto 25 con STARTTLS (no en el puerto 465 con TLS implícito). El servidor emisor inicia una conexión SMTP clásica, envía EHLO, recibe el comando 250-STARTTLS y luego negocia TLS. Es en ese momento cuando compara el certificado presentado con el registro TLSA.
Nomenclatura TLSA para los servidores MX
El nombre del registro TLSA se construye a partir del hostname MX, no del dominio del correo electrónico:
# Correo destinado a user@captaindns.com
# MX de captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com
Si el dominio tiene varios MX, cada MX debe tener su propio registro TLSA.
Resolución: del dominio al certificado
El flujo completo para un correo hacia user@captaindns.com:
- Resolver
captaindns.com→ MX →mail.captaindns.com(validar DNSSEC) - Resolver
_25._tcp.mail.captaindns.com→ TLSA (validar DNSSEC) - Resolver
mail.captaindns.com→ A/AAAA (validar DNSSEC) - Conexión TCP → SMTP → STARTTLS → Verificar el certificado contra TLSA
- Si el certificado coincide: entregar. Si no: rechazar.
Desplegar DANE en 6 pasos
1. Activar DNSSEC en tu zona
Es el requisito indispensable. Contacta con tu registrar o tu proveedor de DNS para activar DNSSEC. Verifica que la cadena de confianza esté completa con una herramienta como dig +dnssec o el verificador DNSSEC de CaptainDNS.
2. Generar el registro TLSA
Genera tu registro con una herramienta dedicada (consulta el CTA al final del artículo). Proporciona tu certificado PEM o deja que la herramienta lo obtenga a través de STARTTLS. Elige la combinación 3 1 1 (DANE-EE, SPKI, SHA-256).
3. Publicar en el DNS
Añade el registro en tu zona:
_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef
4. Verificar la configuración
Tras la propagación (respeta el TTL), valida que todo esté en su sitio: registro TLSA resuelto, DNSSEC válido, certificado correspondiente. El inspector al final de este artículo permite realizar este control en pocos segundos.
5. Activar TLS-RPT
Publica un registro TLS-RPT para recibir los informes de fallos:
_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
6. Planificar la rotación de certificados
Es el punto crítico. Cuando renueves tu certificado:
- Con la misma clave (selector SPKI): el hash no cambia, no hay que hacer nada
- Con una nueva clave: publica el nuevo TLSA antes de desplegar el nuevo certificado. Mantén ambos registros durante el periodo de transición.
DANE y MTA-STS: complementariedad, no competencia
DANE y MTA-STS protegen ambos contra ataques al transporte SMTP, pero mediante mecanismos diferentes.
Lo que hace DANE y MTA-STS no
- Verifica el certificado a través del DNS: sin dependencia de las CA
- Acepta certificados autofirmados: el DNS es la autoridad
- Resiste a la compromisión de una CA: solo cuenta el DNS del dominio
Lo que hace MTA-STS y DANE no
- Funciona sin DNSSEC: utiliza HTTPS como canal autenticado
- Despliegue más sencillo: un archivo de texto en un servidor web
- Modo testing: permite monitorizar antes de imponer
La estrategia ideal: ambos
Desplegar DANE y MTA-STS simultáneamente cubre los dos casos:
- Los servidores que soportan DANE usan la verificación TLSA
- Los servidores que solo soportan MTA-STS usan la política HTTPS
- Los servidores que soportan ambos tienen una doble protección
Monitorizar DANE con TLS-RPT
TLS-RPT (RFC 8460) es el compañero indispensable de DANE en producción. Los informes JSON diarios incluyen los fallos específicos de DANE:
dane-required: el servidor emisor exige DANE pero no encuentra un TLSA válidotlsa-invalid: el registro TLSA tiene un formato incorrectodnssec-invalid: la validación DNSSEC ha falladodane-policy-failure: el certificado no coincide con el registro TLSA
Sin TLS-RPT, no sabrías que una renovación de certificado ha roto la correspondencia TLSA. Consulta nuestra guía completa de TLS-RPT para la puesta en marcha.
🎯 Plan de acción recomendado
- Verifica tu DNSSEC: tu zona debe estar firmada con una cadena de confianza completa
- Elige el uso
3 1 1: DANE-EE + SPKI + SHA-256, el estándar para SMTP - Genera y publica el TLSA: utiliza el generador, publica y espera la propagación
- Valida con el inspector: verifica TLSA + DNSSEC + correspondencia del certificado
- Activa TLS-RPT: recibe informes de fallos para anticiparte a los problemas
- Documenta la rotación: procedimiento de renovación de certificado con actualización TLSA
Verifica tu configuración DANE ahora: Utiliza nuestro inspector DANE/TLSA para analizar la configuración DANE de tu dominio en pocos segundos. ¿Necesitas crear un registro? El generador DANE/TLSA produce un registro TLSA listo para publicar.
FAQ
¿Qué es DANE y cómo funciona?
DANE (DNS-based Authentication of Named Entities) es un estándar de Internet (RFC 6698) que permite publicar en el DNS la información del certificado TLS esperado para un servidor. El servidor emisor consulta el registro TLSA, verifica la firma DNSSEC y luego compara el certificado presentado por el servidor con la huella publicada. Si el certificado no coincide, la conexión se rechaza.
¿Cuál es la diferencia entre DANE y MTA-STS?
DANE utiliza DNSSEC y los registros TLSA para autenticar los certificados. MTA-STS utiliza HTTPS y las autoridades de certificación. DANE ofrece una seguridad superior (sin dependencia de las CA) pero requiere DNSSEC. MTA-STS es más sencillo de desplegar. Ambos mecanismos son complementarios y pueden coexistir en el mismo dominio.
¿Es obligatorio DNSSEC para DANE?
Sí, DNSSEC es un requisito indispensable. Sin una zona firmada, los registros TLSA no son fiables porque un atacante podría falsificarlos. Los servidores emisores conformes a la RFC 7672 ignoran los TLSA cuya cadena DNSSEC no es válida.
¿Qué uso TLSA elegir para el correo electrónico?
La RFC 7672 recomienda DANE-EE (uso 3) con SPKI (selector 1) y SHA-256 (matching type 1), es decir, la combinación 3 1 1. Es el gold standard para SMTP: sin dependencia de las CA, rotación simplificada con SPKI y máxima compatibilidad.
¿Funciona DANE con Let's Encrypt?
Sí, DANE funciona con Let's Encrypt. Con DANE-EE y el selector SPKI (3 1 1), el hash no cambia mientras renueves el certificado con la misma clave privada. Let's Encrypt renueva cada 90 días, pero si conservas la clave, el TLSA sigue siendo válido. Si regeneras la clave, publica el nuevo TLSA antes de desplegar el certificado.
¿Qué proveedores de correo soportan DANE?
Los principales proveedores que soportan DANE en emisión (verificación DANE saliente) incluyen Postfix, Gmail (verificación parcial) y varios ISP europeos. Microsoft ha anunciado el soporte de DANE para Exchange Online. En recepción, cualquier servidor con DNSSEC y un TLSA publicado es compatible. La adopción es más fuerte en Europa (Alemania, Países Bajos) que en Estados Unidos.
¿Cómo monitorizar los fallos de DANE en producción?
Activa TLS-RPT (RFC 8460) publicando un registro DNS _smtp._tls con una dirección de recepción. Los servidores emisores enviarán informes JSON diarios detallando los fallos de DANE: certificado no correspondiente, DNSSEC inválido, TLSA ausente. Sin TLS-RPT, los fallos pasan desapercibidos.
📚 Guías de DANE/TLSA relacionadas
- Configurar DANE/TLSA con Postfix, Bind y Let's Encrypt (próximamente)
- Solución de problemas DANE/TLSA: diagnosticar y corregir errores comunes (próximamente)
- Desplegar DANE en un servidor Exchange o Microsoft 365 (próximamente)
Fuentes
- RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
- RFC 8460 - SMTP TLS Reporting
- Microsoft - SMTP DNS-Based Authentication of Named Entities (DANE)
