Por qué verificar tu DANE TLSA
El transporte SMTP con TLS oportunista deja la puerta abierta a dos escenarios discretos: un atacante en posición intermedia que retira STARTTLS para forzar el texto plano, o un certificado falso aceptado por un MTA emisor que no puede distinguir el real del impostor. DANE cierra esa brecha publicando un hash del certificado esperado en el DNS, firmado con DNSSEC.
Pero DANE es exigente: un registro TLSA mal ubicado, una zona no firmada con DNSSEC o un hash desincronizado tras renovar el certificado bastan para invalidar silenciosamente tu despliegue. No llega ningún mensaje de error al MTA emisor: la conexión vuelve a TLS oportunista sin ruido y tu flujo SMTP pierde la protección que creías tener.
Verificar tu DANE TLSA en directo se vuelve indispensable:
- Tras la publicación inicial: confirmar que el registro se resuelve, está firmado con DNSSEC y el hash coincide con el certificado servido
- Tras cualquier renovación de certificado: la causa número 1 de averías DANE es la desincronización hash/certificado
- Auditoría de seguridad de correo: validar que DANE cubre todos los MX y que ningún borde queda en TLS oportunista
- Antes de migrar de proveedor de correo: Microsoft 365, Google Workspace y los proveedores tradicionales no ofrecen el mismo nivel de soporte de DANE
Cómo usar este checker en 3 pasos
Paso 1: introducir el dominio a analizar
Introduce el dominio de correo tal y como aparece en tus direcciones email:
captaindns.com(dominio principal)marketing.captaindns.com(subdominio si gestionas varias zonas)
La herramienta enumera automáticamente los MX y consulta _25._tcp.<host-mx> para cada uno. La validación DNSSEC recorre la cadena completa hasta la raíz.
Paso 2: leer los resultados por MX
El checker muestra, para cada MX:
| Elemento | Descripción |
|---|---|
| Estado DNSSEC | ¿La zona del host MX está firmada y la cadena de confianza completa? |
| Registro TLSA | Contenido en bruto publicado en _25._tcp.<host> |
| Usage / selector / matching | Desglose de los tres primeros campos con su significado |
| Hash publicado | Datos hexadecimales a comparar con el certificado servido |
| Certificado STARTTLS | Certificado servido en el puerto 25 y su hash calculado |
| Coincidencia | ¿El hash publicado coincide byte a byte con el certificado presentado? |
Paso 3: aplicar las correcciones
Los diagnósticos se ordenan por gravedad:
- Bloqueante: DNSSEC ausente, TLSA no encontrado, hash desalineado. El despliegue DANE no protege a nadie en el estado actual.
- Aviso: combinación no recomendada (usage 0 o 1 sin CA controlada), matching type 0 que publica el certificado en bruto, TTL anormalmente largo.
- Info: MX sin soporte de DANE esperado (Google Workspace), registros múltiples compatibles con una rotación de clave en curso.
Corrige la zona DNS, espera la propagación (TTL) y vuelve a lanzar el checker para confirmar.
Anatomía de un registro TLSA
El registro TLSA se publica en una posición precisa y contiene cuatro campos estrictamente especificados por el RFC 6698.
Posición DNS
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
El owner name sigue el patrón _<puerto>._<protocolo>.<host>. Para SMTP entrante, es invariablemente _25._tcp.<host-mx>. Publicar el registro en el apex del dominio en vez del nombre del host MX es el error más frecuente: ningún MTA lo encuentra.
Los cuatro campos
| Campo | Valores | Significado |
|---|---|---|
| Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Anclaje de confianza |
| Selector | 0 (cert completo), 1 (SubjectPublicKeyInfo) | Parte hasheada |
| Matching type | 0 (bruto), 1 (SHA-256), 2 (SHA-512) | Algoritmo |
| Dato | hexadecimal | Hash o bloque binario |
La combinación recomendada para SMTP
3 1 1 sigue siendo el estándar de facto:
- Usage 3 (DANE-EE): la confianza se ancla en tu clave, independientemente de cualquier autoridad de certificación
- Selector 1 (SPKI): el registro sigue siendo válido mientras se conserve la clave pública, incluso tras renovar el certificado
- Matching type 1 (SHA-256): 32 bytes, soportado universalmente, suficientemente robusto
DNSSEC: el requisito imprescindible
Sin DNSSEC, un registro TLSA es ignorado por cualquier MTA conforme. El checker limita explícitamente la puntuación a 30/100 en cuanto la cadena DNSSEC está rota o ausente.
Cadena de confianza a validar
Raíz (.) -> TLD (.com) -> Dominio (captaindns.com) -> _25._tcp.mail.captaindns.com
DNSSEC DNSSEC DNSSEC Firmado
Cada eslabón debe estar firmado. Una zona padre no firmada invalida todo lo que viene después, independientemente de la calidad del registro TLSA aguas abajo. El checker recorre la cadena y señala el eslabón defectuoso.
Trampas comunes ligadas a DNSSEC
- Zona del dominio firmada pero no la zona del host MX: si tus MX apuntan a un subdominio en una zona separada, es esa zona la que debe estar firmada.
- Registros DS ausentes en el registrador: la zona firmada localmente sigue siendo invisible para los resolutores externos si el DS no se ha publicado en el TLD.
- RRSIG caducadas: las firmas DNSSEC tienen un periodo de validez. Una renovación fallida pone la zona en modo bogus.
El checker indica cuál de estos casos se aplica.
Estrategias de rotación de clave
La rotación de certificado sin interrupción de servicio es el principal desafío operativo de DANE. Coexisten tres estrategias.
Estrategia 1: selector SPKI + reutilización de clave
Con --reuse-key (Certbot) o un --key-type rsa compartido, la clave pública permanece idéntica entre renovaciones. El hash SPKI no cambia y el registro 3 1 1 <hash-spki> sigue siendo válido indefinidamente. Es la estrategia más sencilla.
Estrategia 2: DANE-TA sobre la autoridad de certificación
2 0 1 <sha256-del-certificado-CA>
Anclas el certificado raíz de tu CA (Let's Encrypt ISRG Root X1 por ejemplo) en vez de tu propio certificado. Ventaja: ninguna actualización DNS al renovar. Inconveniente: confianza delegada a la CA, por tanto menos estricto que DANE-EE.
Estrategia 3: registro doble durante la transición
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-clave-actual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-clave-siguiente>
Publica el hash de la siguiente clave 7 días antes de la rotación (mínimo el doble del TTL máximo). Los MTA conformes aceptan una conexión si al menos un registro coincide con el certificado presentado. Tras la rotación, elimina el hash antiguo.
El checker reconoce la presencia de registros múltiples y la etiqueta como una rotación de clave en curso en vez de un error.
DANE y SMTP: lo que pasa al entregar
- El servidor emisor resuelve los MX de
captaindns.com - Consulta
_25._tcp.<mx>para recuperar el registro TLSA - Valida la cadena DNSSEC hasta la raíz
- Abre STARTTLS en el puerto 25 y recupera el certificado presentado
- Calcula el hash del certificado según el matching type publicado
- Si el hash coincide: conexión segura confirmada
- Si no: rechazo de la entrega (diferencia fundamental con el TLS oportunista)
DANE vs TLS oportunista
| Aspecto | TLS oportunista | DANE |
|---|---|---|
| Verificación de certificado | Ninguna (acepta todo) | Hash firmado por DNSSEC obligatorio |
| Protección MITM | No | Sí |
| Fallback no TLS | Sí (degradación silenciosa) | No |
| Requisito | Ninguno | DNSSEC en la zona del MX |
Diagnósticos comunes y soluciones
No se encuentra ningún registro TLSA
Causa: el dominio no ha configurado DANE, o el registro está publicado en una posición incorrecta.
Solución: genera y publica un registro TLSA en _25._tcp.<host-mx>. Nuestra guía de instalación DANE TLSA para Postfix, BIND y Let's Encrypt cubre el despliegue paso a paso.
DNSSEC ausente o roto
Causa: la zona no está firmada, o los DS no se han publicado en el registrador.
Solución: activa DNSSEC en tu proveedor DNS, exporta los DS y publícalos en tu registrador. Verifica la propagación con una herramienta DNSSEC dedicada antes de volver a lanzar este checker.
Hash de certificado desincronizado
Causa: el certificado TLS se ha renovado y el hash publicado ya no está actualizado.
Solución: usa el selector SPKI (1) con --reuse-key para que el registro sea invariante frente a las renovaciones. En su defecto, actualiza el hash inmediatamente y adopta la estrategia de registro doble para las próximas rotaciones.
TLSA en posición incorrecta
Causa: registro publicado en el dominio raíz en vez del nombre del host MX, o en el puerto equivocado.
Solución: vuelve a publicar exactamente en _25._tcp.<host-mx>. Para un MX mail.captaindns.com, es _25._tcp.mail.captaindns.com. Nada más.
Microsoft 365 / Google Workspace sin DANE entrante
Causa: estos proveedores no firman sus zonas DNS, por lo que DANE no es aplicable en el lado entrante.
Solución: despliega MTA-STS en lugar de DANE para estos proveedores. MTA-STS se apoya en HTTPS en vez de DNSSEC y es soportado por Google Workspace y Microsoft 365.
DANE y MTA-STS: enfoques complementarios
Los dos protocolos forman una defensa en profundidad, no una elección excluyente.
| Criterio | DANE | MTA-STS |
|---|---|---|
| Mecanismo | DNSSEC + registro TLSA | HTTPS + política de texto |
| Dependencia | DNSSEC requerido | HTTPS requerido |
| Confianza | Criptográfica (DNS firmado) | PKI (CA HTTPS) |
| Soporte Postfix / Exim | Excelente | Bueno |
| Soporte Microsoft 365 | Parcial (saliente 2022, entrante 2024) | Completo |
| Soporte Google Workspace | Ninguno (zonas no firmadas) | Completo |
| Despliegue | Complejo (DNSSEC) | Más sencillo |
Recomendación: despliega los dos. DANE para los dominios alojados en Postfix o Exim, MTA-STS para los dominios delegados a Microsoft 365 o Google Workspace. La cobertura máxima impone la combinación.
Herramientas complementarias y recursos
| Herramienta | Utilidad |
|---|---|
| Validador DANE TLSA | Validar la sintaxis de un registro ANTES de publicarlo en el DNS |
| Generador DANE TLSA | Crear un registro TLSA a partir de un certificado o una clave |
| MTA-STS Checker | Verificar la política MTA-STS complementaria |
| TLS-RPT Checker | Supervisar los fallos TLS mediante reportes |
| Inspector DMARC | Completar la autenticación de correo |
| Auditoría email-authentication | Vista general de las herramientas de autenticación de correo |
Guías relacionadas
- DANE TLSA: la guía completa - Comprender DANE de extremo a extremo, de DNSSEC al despliegue SMTP.
- DANE TLSA en Postfix, BIND y Let's Encrypt - Instalación paso a paso con rotación de clave.
- DANE TLSA y Microsoft 365 Exchange Online - Soporte de DANE entrante y saliente en Exchange Online.
- DANE TLSA: 12 casos prácticos de resolución de incidencias - Diagnóstico y resolución de incidentes DANE.
- MTA-STS vs DANE: comparativo detallado - Elegir o combinar los dos protocolos.
Especificaciones
- RFC 6698 - DANE TLSA (especificación original)
- RFC 7671 - Updates to DANE (aclaraciones operativas)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)