Artículo de blog
- 8 minutos leídos
Waseem OsmanEspecialista en DMARCAutenticación DANE: lo que deben saber los responsables de seguridad empresarial

Descripción general de la autenticación DANE:
- DANE impide que los atacantes utilicen certificados fraudulentos para interceptar el tráfico de correo electrónico
- DANE protege la capa de transporte, complementando a DMARC en lugar de sustituirlo
- DANE requiere DNSSEC – sin él, el protocolo no puede funcionar de forma segura
- La carga operativa de DANE proviene de la rotación de claves, no de la renovación de certificados
- Los errores de DANE son silenciosos por defecto – supervisión de TLS-RPT es esencial
La autenticación de entidades con nombre basada en DNS (DANE) es uno de los protocolos menos utilizados en la seguridad del correo electrónico empresarial.
La mayoría de las organizaciones se centran en la verificación del remitente y pasan por alto por completo la seguridad de la capa de transporte. Esto deja una vulnerabilidad importante: la posibilidad de ataques de tipo «hombre en el medio» (MitM) que pueden interceptar las comunicaciones de correo electrónico incluso cuando la autenticación del remitente se supera con éxito.
Qué aporta DANE a tu infraestructura de seguridad del correo electrónico
DANE permite a los propietarios de dominios publicar registros TLSA en su DNS que especifican qué certificados TLS están autorizados para un servicio concreto. Cuando se implementa correctamente, DANE impide que los atacantes utilicen certificados fraudulentos para interceptar el tráfico de correo electrónico entre servidores – incluso si han comprometido una autoridad de certificación (CA) u obtenido un certificado válido mediante ingeniería social.
A diferencia de DMARC, que se centra en la autenticación de mensajes, DANE protege la capa de transporte. Esto la convierte en una tecnología complementaria, no en una competidora. Tu política DMARC podría autenticar correctamente a un remitente, pero sin DANE, ese mensaje autenticado aún podría ser interceptado y leído durante la transmisión.
DMARC indica a los servidores receptores si un mensaje es legítimo basándose en la autenticación del remitente. DANE indica a los servidores receptores si la propia conexión TLS es legítima basándose en la autenticación del certificado. Ambos abordan vectores de ataque diferentes.
Por qué sigue siendo baja la implementación de DANE
Las especificaciones técnicas de DANE están bien definidas, pero las empresas se enfrentan a varios obstáculos operativos, lo que puede ayudar a explicar su baja tasa de adopción.
Los requisitos previos de DNSSEC constituyen el obstáculo más importante. DANE requiere la validación de DNSSEC para funcionar de forma segura, lo que significa que las empresas deben implementarlo y mantenerlo primero en sus dominios de correo electrónico.
Muchas empresas aún carecen de una cobertura completa de DNSSEC, y la consideran una carga operativa adicional en lugar de un control de seguridad fundamental. Sin una zona DNS totalmente firmada y una cadena de confianza completa, los servidores de envío que cumplen la normativa ignoran los registros TLSA.
La gestión de certificados es el segundo aspecto importante a tener en cuenta, aunque es más compleja de lo que parece a primera vista.
La configuración DANE recomendada para SMTP es DANE-EE con SPKI y SHA-256, que se escribe como 3 1 1. Especificada en las RFC 7671 y RFC 7672, esta configuración fija la huella digital de la clave pública en lugar de todo el certificado. Si renuevas tu certificado utilizando el mismo par de claves, no es necesario modificar tu registro TLSA.
La carga operativa surge al cambiar el par de claves. Cuando una empresa cambia a un nuevo par de claves, es necesario un periodo de transición: el nuevo registro TLSA debe publicarse y debe dejarse tiempo para que se propague antes de retirar el certificado antiguo. Si no se respeta este plazo, se pueden rechazar correos electrónicos legítimos.
Tomar la decisión de implementar DANE
La implementación de DANE no es adecuada para todas las organizaciones. La decisión debe basarse en el riesgo, la preparación operativa y la infraestructura.
El riesgo es la primera consideración. Las empresas que gestionan comunicaciones confidenciales u operan en sectores regulados tienden a considerar que las ventajas de DANE en materia de seguridad del transporte justifican los costes operativos adicionales. La vulneración de una CA es una amenaza real, y DANE la aborda directamente.
La preparación operativa es igualmente importante. La implementación de DANE requiere operaciones de DNS consolidadas, cobertura de DNSSEC y procesos de gestión del ciclo de vida de las claves. Las empresas que carezcan de estas capacidades deben subsanar esas carencias fundamentales antes de intentar la implementación.
La infraestructura es el último aspecto a tener en cuenta. Comprueba si los proveedores de correo electrónico en la nube gestionan DANE en tu nombre, si las puertas de enlace de seguridad pueden encargarse de la validación de DANE, y si los sistemas de supervisión ofrecen una visibilidad adecuada de los modos de fallo específicos de DANE a través de TLS-RPT.
Supervisión de DANE en producción
Los errores de DANE son silenciosos por defecto. Cuando un servidor de envío no puede validar tu registro TLSA, aplaza o rechaza la entrega sin notificártelo necesariamente. TLS-RPT (RFC 8460) proporciona la visibilidad necesaria para detectar esto.
Los informes TLS-RPT incluyen tipos de fallos específicos de DANE – el más habitual es dane-policy-failure, que ocurre cuando la renovación de un certificado modifica el material de la clave sin la correspondiente actualización del registro TLSA. Estos informes detectan los fallos de DANE antes de que tus socios de envío empiecen a reportar problemas de entrega.
Cómo se integra DANE en la infraestructura de correo electrónico existente
La implementación de DANE debe tener en cuenta todos los componentes de tu entorno – servidores de correo electrónico, puertas de enlace de seguridad, proveedores de servicios en la nube y servicios de terceros – no solo tu infraestructura de envío principal.
Los proveedores de servicios en la nube plantean consideraciones específicas. Los principales proveedores, como Microsoft Exchange Online, han implementado DANE en su propia infraestructura, lo que significa que las empresas que utilizan esos servicios se benefician de DANE en el correo electrónico entrante, y que la gestión de los registros TLSA se lleva a cabo en su nombre.
La integración de las pasarelas de seguridad requiere una planificación minuciosa. Las empresas que utilizan pasarelas de correo electrónico seguras para el análisis de malware y el filtrado de contenidos necesitan que esas pasarelas sean compatibles con DANE para evitar que se rompa la cadena de validación de certificados. Es posible que las pasarelas antiguas requieran actualizaciones o ser sustituidas para admitir DANE correctamente.
Cómo puede ayudar Sendmarc
La gestión de TLS-RPT de Sendmarc ofrece a los equipos una visibilidad directa de los fallos en la capa de transporte, incluidos los errores específicos de DANE como dane-policy-failure, antes de que afecten a la capacidad de entrega.
Recibe las últimas actualizaciones de seguridad de correo electrónico en tu bandeja de entrada cada mes
¿Tu dominio está protegido?
Obtén la puntuación de seguridad de tu dominio en segundos.
Consulta tus calificaciones de suplantación, privacidad y marca.
Si corres riesgo de suplantación de identidad, uno de nuestros expertos se pondrá en contacto para ayudarte.


