Comprobador de registros DANE/TLSA

Consulta los registros TLSA publicados por los servidores de correo (hosts MX) de un dominio en varios resolutores DNS públicos para comprobar si DANE está configurado.

Última actualización: 2026-09-20

Diagnosticar la validación de certificados mediante DANE (registros TLSA)

DANE es el arreglo por el cual el certificado que presenta un servidor de correo **se valida contra un registro TLSA colocado en el DNS.** Esta herramienta consulta los registros TLSA publicados por los hosts MX de un dominio contra varios resolutores públicos y comunica si están configurados.

**La premisa que aquí no cabe omitir jamás es que DANE se sostiene únicamente sobre DNSSEC.** Lo que garantiza que un registro TLSA no ha sido manipulado es el propio DNSSEC, de modo que **colocar registros TLSA en un dominio sin DNSSEC habilitado no equivale a protección alguna.** Esta es la diferencia capital respecto de MTA-STS: donde MTA-STS deposita su confianza en los certificados web, **DANE la deposita en DNSSEC.** El otro punto que exige cuidado en la operación es la renovación de certificados, pues **sustituir el certificado de un servidor sin actualizar a la vez el registro TLSA hace fallar la validación y detiene la llegada del correo.** El orden requerido es añadir primero la nueva huella, conmutar, y solo después retirar la antigua.

Cómo se usa

Introduzca el dominio Indique únicamente el dominio, en la forma `example.com`.
Mire el resultado de cada host MX **Los registros TLSA residen en `_25._tcp.nombredehost` de cada host MX.**
Confirme si DNSSEC está en su sitio **Sin DNSSEC, un registro TLSA no brinda protección alguna.**
Planifique el procedimiento de renovación **Deje coexistir un tiempo la huella antigua y la nueva antes de conmutar.**

Consejos para aprovecharla mejor

Los registros TLSA no se publican bajo el nombre de dominio normal, sino bajo un nombre especial, `_25._tcp.{host MX}`. Por eso buscar TLSA en el dominio sin más nunca encuentra nada.
"DANE no configurado" no es un error. DANE es una capa adicional de defensa para el cifrado del correo, y la mayoría de los servidores de correo todavía no lo usan.
DANE solo es fiable si el propio registro TLSA del dominio está protegido por la cadena de firmas de DNSSEC. Aunque se encuentre un registro TLSA, conviene usar también la herramienta hermana "Comprobador DNSSEC" para confirmar que el dominio tiene DNSSEC habilitado.
Cuando un dominio tiene varios hosts MX, esta herramienta comprueba hasta 3 hosts, empezando por el de menor número de preferencia (mayor prioridad).
Si los resolutores no coinciden, es posible que el registro se haya actualizado recientemente y las cachés aún no se hayan sincronizado. Espera un poco y vuelve a comprobarlo.

Cuándo resulta útil

Inspeccionar sus propios servidores de correo

Puede hallar la discrepancia en que se creía colocado un TLSA que falta en el host MX.

Comprobar antes de renovar un certificado

**Errar el orden detiene el correo, lo que hace que comprobar de antemano compense con creces.**

Sopesar DANE frente a MTA-STS

**Elija según dónde prefiera depositar la confianza, en DNSSEC o en certificados web; ambos pueden adoptarse juntos.**

Saber hasta dónde ha llegado un corresponsal

Puede ver si usa DANE siquiera.

Términos de DANE

Registro TLSA: **El registro que coloca en el DNS la huella de un certificado o de una clave pública.** Reside en un nombre como `_25._tcp.mail.example.com`.
DNSSEC: **La premisa de DANE.** Sin él, el propio registro TLSA podría manipularse y no se sostiene protección alguna.
Campo de uso: El primer número de un registro TLSA, que declara si se refiere al certificado mismo o a una autoridad de certificación.
DANE-EE: El enfoque que registra la huella del propio certificado del servidor. **Permite validar sin depender de autoridad alguna.**
Rotación: La tarea de sustituir un certificado y su registro TLSA. **Añada primero la nueva huella y retire la antigua después.**
TLS oportunista: El enfoque antiguo y optativo de cifrar allí donde la otra parte lo admita. **DANE y MTA-STS lo elevan a requisito.**

Preguntas frecuentes

Que "DANE no esté configurado" no es peligroso en sí mismo: la gran mayoría de los servidores de correo siguen funcionando sin él. Aun así, habilitarlo vale la pena considerarlo como defensa frente a ataques de hombre en el medio contra STARTTLS si tienes la opción.

Ambos buscan forzar el cifrado TLS en el transporte de correo, pero basan su confianza de forma distinta: MTA-STS depende de la cadena de validación de una autoridad de certificación, mientras que DANE depende de la cadena de firmas de DNSSEC. Si ya tienes DNSSEC habilitado, DANE encaja de forma natural; si no, MTA-STS es el punto de partida más práctico. También se pueden usar ambos a la vez.

Usage especifica el modelo de validación (si aún se requiere validación de CA o si el certificado se fija directamente), Selector especifica si se aplica el hash al certificado completo o solo a la clave pública, y Matching Type especifica el algoritmo de hash (como SHA-256 o SHA-512). Distintas combinaciones se adaptan a distintos patrones operativos.

Para una protección completa, todo host MX que pueda ser elegido como destino de entrega debería tener un registro TLSA. Si solo algunos hosts lo tienen, el correo entregado a un host sin registro no queda protegido.

Esta herramienta solo comprueba un estado superficial: si se ha publicado un registro TLSA. No verifica si los datos de asociación del certificado coinciden realmente con el certificado del servidor, así que combínala con una herramienta especializada si necesitas una comprobación rigurosa.

A propósito — Proteger el cifrado del correo con certificados, no solo con "que no lo intercepten"

El cifrado del correo mediante SMTP (STARTTLS) ha tenido durante mucho tiempo una debilidad. La mayoría de los servidores de correo usan TLS oportunista: si la otra parte no admite cifrado, la conexión cae de vuelta a texto plano. Esto abrió la puerta a los "ataques STRIPTLS", en los que un atacante de tipo hombre en el medio elimina silenciosamente el comando STARTTLS para que la conexión se degrade a texto plano sin que ninguna de las partes lo note.

DANE (DNS-based Authentication of Named Entities, RFC 6698) responde a esto publicando registros TLSA en el DNS. Al fijar de antemano en el DNS el certificado de un servidor de correo (o el hash de su clave pública), el servidor remitente puede verificar que el host al que se conecta presenta realmente el certificado esperado. A diferencia de la validación habitual de certificados SSL/TLS, DANE no depende en absoluto de la cadena de confianza de una autoridad de certificación: solo confía en la cadena de firmas de DNSSEC.

La debilidad de DANE es que solo funciona si el propio dominio está firmado con DNSSEC. Sin DNSSEC, nada impide que el registro TLSA sea manipulado en tránsito, lo que hace que la garantía de DANE carezca de sentido. Por eso la adopción de DANE sigue de cerca la de DNSSEC, y ha tenido una adopción más temprana en algunos registros europeos (como .nl y .cz).

Ver todas las curiosidades