Ir al contenido principal

Nuevo

Prueba la entregabilidad de tus correos

Envía un correo de prueba y obtén un diagnóstico completo de tu autenticación SPF, DKIM y DMARC en segundos.

  • Prueba de envío real
  • Diagnóstico instantáneo
  • Sin registro

DANE TLSA Validator

Valida tus registros TLSA antes de publicarlos en DNS

Verifica la sintaxis de tu registro DANE TLSA antes de publicarlo. Nuestro validador controla los campos certificate usage, selector y matching type, verifica el formato de los datos hexadecimales y detecta las combinaciones inválidas.

Formato: usage selector matching-type datos (ej.: 3 1 1 seguido del hash hexadecimal).

Conformidad RFC 6698

Valida tu registro según la especificación DANE. Detecta valores fuera de rango, combinaciones inválidas y sintaxis malformada.

Verificación DNSSEC

Recuerda que DANE requiere DNSSEC para funcionar. Sin firma DNSSEC, los registros TLSA son ignorados por los servidores.

Respuesta instantánea

Validación en tiempo real mientras escribes. Sin esperas, sin enviar formularios. Resultados inmediatos con códigos de diagnóstico.

Diagnóstico detallado

Explicaciones claras para cada problema detectado. Cada error incluye el campo afectado, el valor inválido y cómo corregirlo.

Seguridad TLS email

DANE protege las conexiones SMTP contra ataques MITM. Valida tus registros TLSA para garantizar la seguridad del transporte de correo.

¿Qué es DANE TLSA y por qué validar la sintaxis?

DANE (DNS-based Authentication of Named Entities) vincula certificados TLS a nombres DNS mediante registros TLSA firmados por DNSSEC. Definido en RFC 6698 y ampliado por RFC 7671, elimina la dependencia de las autoridades de certificación para autenticar servidores de correo.

¿Por qué validar antes de publicar? Un solo error de sintaxis puede anular toda tu protección DANE:

  • Un registro TLSA inválido se ignora sin ningún aviso
  • Un valor de usage incorrecto debilita la seguridad en lugar de reforzarla
  • Los datos hexadecimales malformados inutilizan el registro por completo
  • Una combinación usage/selector/matching type incoherente causa fallos de entrega

Valida siempre la sintaxis con esta herramienta antes de publicar en DNS.


Formato del registro TLSA explicado

Estructura básica

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
CampoValoresDescripción
Certificate Usage0-3Tipo de restricción de certificado
Selector0-1Parte del certificado a comparar
Matching Type0-2Método de comparación
Certificate DataHexDatos de certificado o hash

Certificate Usage (campo 1)

ValorNombreDescripción
0PKIX-TARestricción CA: el certificado debe estar firmado por esta CA Y validado PKIX
1PKIX-EERestricción certificado: coincidencia exacta del certificado del servidor + validación PKIX
2DANE-TAAncla de confianza: acepta cualquier certificado firmado por esta CA
3DANE-EECertificado dominio: coincidencia exacta del certificado del servidor, sin validación PKIX

Recomendación: DANE-EE (3) es el más usado para SMTP. No requiere validación PKIX, lo que simplifica el despliegue.

Selector (campo 2)

ValorNombreDescripción
0CertCertificado completo (DER)
1SPKISolo clave pública (Subject Public Key Info)

Recomendación: Elige SPKI (1). Tu registro seguirá siendo válido tras cada renovación si conservas la misma clave.

Matching Type (campo 3)

ValorNombreLongitud hex
0FullVariable (certificado completo)
1SHA-25664 caracteres
2SHA-512128 caracteres

Recomendación: SHA-256 (1) ofrece el mejor equilibrio entre tamaño (64 caracteres hex) y seguridad. Es el estándar de facto.


Errores de sintaxis habituales

Valor de usage fuera de rango

# Incorrecto, usage 4 no existe
3 1 1 2bb183af... → usage debe ser 0-3

# Correcto, DANE-EE (3)
3 1 1 2bb183af...

Datos hex inválidos

# Incorrecto, caracteres no-hex (G, Z)
3 1 1 2bg183zf...

# Correcto, solo 0-9, a-f
3 1 1 2bb183af...

Longitud de hash incorrecta

# Incorrecto, SHA-256 debe tener 64 caracteres hex
3 1 1 2bb183

# Correcto, hash SHA-256 completo (64 car.)
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4

Combinación usage/selector incoherente

# Atención, DANE-EE (3) + Cert (0) cambia en cada renovación
3 0 1 ...

# Recomendado, DANE-EE (3) + SPKI (1) sobrevive a las renovaciones
3 1 1 ...

Configuración DANE para SMTP: los 5 pasos

Paso 1: Activar DNSSEC

DANE requiere DNSSEC obligatoriamente. Sin firma DNSSEC, los registros TLSA se ignoran sin aviso.

Paso 2: Generar el registro TLSA

Usa nuestro Generador DANE TLSA para crear un registro con los parámetros correctos. Configuración recomendada: 3 1 1 (DANE-EE + SPKI + SHA-256).

Paso 3: Validar la sintaxis

Pega tu registro en este validador. Corrige cualquier error antes de publicar en DNS.

Paso 4: Publicar en DNS

Añade el registro TLSA en la ubicación correcta: _25._tcp.mail.captaindns.com. Verifica que el hostname corresponde a tu servidor MX.

Paso 5: Verificar el despliegue

Usa nuestro DANE TLSA Checker para confirmar que el registro está en línea y firmado con DNSSEC.


DANE vs MTA-STS: dos enfoques de seguridad TLS

CriterioDANEMTA-STS
MecanismoDNSSEC + TLSA recordsHTTPS + política texto
DependenciaDNSSEC requeridoHTTPS requerido
Nivel de confianzaCriptográfico (DNSSEC)PKI (HTTPS)
Facilidad de despliegueComplejo (DNSSEC)Más sencillo
AdopciónGobiernos, institucionesMás amplia

Ambos son complementarios. MTA-STS funciona sin DNSSEC. DANE ofrece una seguridad criptográfica más fuerte basada en la cadena DNSSEC. Despliega ambos para una protección máxima del correo en tránsito.

Verifica tu configuración MTA-STS con nuestro Inspector MTA-STS.


FAQ - Preguntas frecuentes

P: ¿Qué es un registro DANE TLSA?

R: Un registro DANE TLSA es un registro DNS que asocia un certificado TLS a un nombre de dominio mediante DNSSEC. Permite la verificación del certificado sin depender únicamente de las autoridades de certificación, añadiendo una capa de seguridad a las conexiones SMTP.


P: ¿Qué verifica el validador DANE TLSA?

R: Nuestro validador analiza la sintaxis TLSA: el campo certificate usage (0-3), el selector (0-1), el matching type (0-2) y el formato de los datos de asociación de certificado. Detecta combinaciones inválidas y datos hexadecimales malformados.


P: ¿Cuáles son los tipos de certificate usage TLSA?

R: Existen cuatro tipos de usage: PKIX-TA (0) restricción CA, PKIX-EE (1) restricción de certificado de servicio, DANE-TA (2) aserción de ancla de confianza, DANE-EE (3) certificado emitido por el dominio. DANE-EE (3) es el más común para SMTP.


P: ¿Qué diferencia hay entre DANE-TA y DANE-EE?

R: DANE-TA (usage 2) fija una autoridad de certificación, permitiendo la rotación de certificado sin actualización DNS. DANE-EE (usage 3) fija el certificado del servidor específico, ofreciendo mayor seguridad pero requiriendo actualización DNS en cada renovación.


P: ¿DANE necesita DNSSEC?

R: Sí, imprescindible. Sin DNSSEC, los registros TLSA no pueden ser autenticados. El modelo de seguridad DANE depende completamente de DNSSEC para garantizar la integridad de las respuestas DNS.


P: ¿Puedo usar DANE con Microsoft 365 o Google Workspace?

R: Microsoft 365 soporta DANE con DNSSEC para correo entrante (Exchange Online). Google Workspace aún no soporta DANE para recepción. Ambas plataformas soportan la validación DANE para envío hacia destinatarios compatibles.


Herramientas complementarias

HerramientaUtilidad
DANE TLSA CheckerVerificar el registro TLSA desplegado en DNS
DANE TLSA GeneratorCrear un registro TLSA a partir de un certificado
Inspector MTA-STSVerificar la política MTA-STS (seguridad TLS alternativa)
Inspector TLS-RPTMonitorizar los fallos TLS mediante informes
Auditoría dominio emailAuditoría completa de la autenticación email

Recursos útiles