¿Qué verifica este inspector DANE TLSA?
Introduce tu dominio y nuestra herramienta ejecuta 5 verificaciones en secuencia:
- Resolución MX: Identifica los servidores de correo del dominio
- Búsqueda TLSA: Consulta
_25._tcp.hostnamepara cada servidor MX - Verificación DNSSEC: Comprueba que la cadena de firmas es completa y válida
- Validación de sintaxis: Verifica la conformidad con RFC 6698 y RFC 7672
- Correspondencia de certificado: Compara los datos TLSA con el certificado TLS actual del servidor
Si alguna de estas verificaciones falla, recibes un diagnóstico detallado con la corrección recomendada.
Comprender los registros DANE TLSA
Ubicación DNS
Los registros TLSA se publican bajo el hostname del servidor MX, no del dominio:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
Error frecuente: Si tu MX apunta a mail.captaindns.com, el TLSA va en _25._tcp.mail.captaindns.com. Publicarlo en _25._tcp.captaindns.com no funciona.
Estructura del registro
| Campo | Valores | Significado |
|---|---|---|
| Certificate Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Tipo de restricción |
| Selector | 0 (Cert), 1 (SPKI) | Parte del certificado comparada |
| Matching Type | 0 (Full), 1 (SHA-256), 2 (SHA-512) | Método de comparación |
| Certificate Data | Hexadecimal | Hash o datos completos |
Configuración recomendada para SMTP
3 1 1 <sha256-hash>
- Usage 3 (DANE-EE): No necesita validación PKIX
- Selector 1 (SPKI): Sobrevive a las renovaciones con la misma clave
- Matching Type 1 (SHA-256): Compacto y seguro
El papel de DNSSEC en DANE
DANE no funciona sin DNSSEC. Sin firma criptográfica, los registros TLSA no tienen valor. Veamos por qué:
Cadena de confianza
Raíz DNS (.) → TLD (.com) → Dominio (captaindns.com) → TLSA record
DNSSEC DNSSEC DNSSEC Firmado
Cada nivel de la jerarquía DNS debe estar firmado con DNSSEC. Si falta un solo eslabón, los registros TLSA se consideran no autenticados y se ignoran sin aviso.
Lo que verifica nuestra herramienta
| Verificación | Descripción | Impacto si falla |
|---|---|---|
| Zona firmada | El dominio tiene claves DNSSEC | Registros TLSA ignorados |
| Cadena válida | Las firmas son verificables | Registros TLSA ignorados |
| Firma no expirada | Los RRSIG siguen siendo válidos | Registros TLSA ignorados temporalmente |
¿Tu dominio tiene DNSSEC? Verifica con nuestra Auditoría de dominio email antes de configurar DANE.
Problemas habituales detectados
Ningún registro TLSA encontrado
Causa: El dominio no tiene DANE configurado Impacto: Sin protección DANE para el correo entrante Corrección: Genera un registro DANE TLSA y publícalo en DNS
DNSSEC ausente
Causa: El dominio no está firmado con DNSSEC Impacto: Los registros TLSA se ignoran aunque existan Corrección: Activa DNSSEC en tu registrar y luego en tu proveedor DNS
Hash de certificado desincronizado
Causa: El certificado TLS se renovó sin actualizar el TLSA Impacto: Los MTA DANE-aware rechazan la conexión o vuelven al modo oportunista Corrección: Actualiza el hash TLSA con el nuevo certificado. Usa DANE-TA (usage 2) o SPKI selector (1) con reutilización de clave para evitar este problema.
TLSA en ubicación incorrecta
Causa: Registro publicado para el dominio en lugar del servidor MX
Impacto: Los servidores remitentes no encuentran el registro
Corrección: Publica en _25._tcp.<hostname-mx>, no en _25._tcp.<dominio>
Estrategia de rotación de certificado con DANE
La rotación de certificado es el principal reto operacional con DANE. Si el hash TLSA no coincide con el certificado actual, los servidores DANE-aware pueden rechazar la entrega. Aquí tienes tres estrategias:
Estrategia 1: DANE-TA (recomendada para Let's Encrypt)
Fija el certificado CA en lugar del certificado del servidor:
2 0 1 <sha256-del-certificado-CA>
Ventaja: El TLSA sigue siendo válido mientras la misma CA firme tus certificados. Inconveniente: Menos estricto que un fijado directo.
Estrategia 2: DANE-EE con reutilización de clave
Mantén la misma clave privada entre renovaciones:
3 1 1 <sha256-de-la-clave-publica>
Ventaja: Fijado fuerte + sobrevive a las renovaciones.
Inconveniente: Requiere configurar la reutilización de clave (ej: --reuse-key en Certbot).
Estrategia 3: Doble registro (rollover)
Publica ambos TLSA antes de la rotación:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificado-actual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificado-futuro>
Después de la rotación, elimina el hash antiguo. ¿Necesitas generar los hashes? Usa nuestro Generador DANE TLSA.
DANE y SMTP: protección del correo en tránsito
Cómo funciona DANE para SMTP (en 6 pasos)
- El servidor remitente resuelve el MX de tu dominio
- Busca los registros TLSA en
_25._tcp.<hostname-mx> - Verifica que la respuesta TLSA está firmada con DNSSEC
- Se conecta vía STARTTLS al servidor MX
- Compara el certificado TLS presentado con los datos TLSA
- Certificado válido → conexión segura. Inválido → entrega rechazada
Diferencia con el TLS oportunista
| Aspecto | TLS oportunista | DANE |
|---|---|---|
| Verificación de certificado | Ninguna (acepta todo) | Mediante registro TLSA |
| Protección MITM | No | Sí |
| Fallback sin TLS | Sí | No (por defecto) |
| Prerrequisito | Ninguno | DNSSEC |
DANE convierte el TLS en obligatorio y verificable. Sin DANE, un atacante puede interceptar la conexión SMTP sin que nadie lo detecte.
FAQ - Preguntas frecuentes
P: ¿Qué verifica el DANE TLSA Checker?
R: Nuestro checker realiza un lookup DNS de los registros TLSA de tu dominio, valida su sintaxis, verifica el estado de la firma DNSSEC, controla la correspondencia con el certificado del servidor de correo, y señala los problemas de configuración.
P: ¿Por qué falla mi DANE TLSA check?
R: Causas habituales: DNSSEC ausente en el dominio, registros TLSA no publicados en la ubicación correcta (_25._tcp.mail.captaindns.com), hash de certificado desincronizado tras la renovación, o combinación usage/selector/matching type incorrecta.
P: ¿Cuál es el nombre DNS correcto para los registros TLSA SMTP?
R: Los registros TLSA SMTP deben publicarse en _puerto._protocolo.hostname, típicamente _25._tcp.mail.captaindns.com. El hostname debe ser el del servidor MX destino, no el dominio en sí.
P: ¿Cómo protege DANE el correo en tránsito?
R: DANE previene ataques man-in-the-middle en las conexiones SMTP, permitiendo al servidor remitente verificar el certificado TLS mediante DNS/DNSSEC en lugar de depender únicamente de las autoridades de certificación.
P: ¿Con qué frecuencia debo verificar mis registros DANE TLSA?
R: Verifica tras cada renovación de certificado TLS, tras cualquier cambio DNS, y mensualmente. La expiración de certificado es la causa número 1 de los fallos DANE.
P: ¿DANE funciona con certificados Let's Encrypt?
R: Sí, pero planifica las renovaciones de 90 días. DANE-TA (usage 2) con el certificado CA de Let's Encrypt es más fácil. DANE-EE (usage 3) con reutilización de clave (--reuse-key en Certbot) también funciona.
Herramientas complementarias
| Herramienta | Utilidad |
|---|---|
| DANE TLSA Validator | Validar la sintaxis antes de publicar |
| DANE TLSA Generator | Crear un registro TLSA desde un certificado |
| Inspector MTA-STS | Verificar la política MTA-STS (seguridad TLS alternativa) |
| Inspector TLS-RPT | Monitorizar los fallos TLS mediante informes |
| SMTP Check | Verificar la conexión STARTTLS que DANE protege |
| Auditoría dominio email | Auditoría completa de la autenticación email |
Recursos útiles
- RFC 6698 - DANE TLSA (especificación original)
- RFC 7671 - Updates to DANE (actualizaciones operacionales)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)
- Microsoft - DANE with DNSSEC (guía Exchange Online)
- Let's Encrypt - Using DANE (consejos DANE con LE)