MTA-STS vs DANE: ¿qué protocolo elegir para asegurar el transporte de correo?

⚡TL;DR

• MTA-STS (RFC 8461) publica una política de cifrado obligatorio vía HTTPS. Funciona sin DNSSEC, pero la primera conexión sigue siendo vulnerable (TOFU)
• DANE/TLSA (RFC 7672) ancla el certificado TLS en el DNS firmado por DNSSEC. Sin TOFU, pero DNSSEC es obligatorio en toda la cadena
• Ambos protocolos son complementarios: MTA-STS cubre los dominios sin DNSSEC, DANE elimina el TOFU para los que sí lo tienen
• Aloja tu política MTA-STS con CaptainDNS (primera herramienta gratis, después 3 €/mes sin IVA): dos registros DNS son suficientes

El cifrado SMTP oportunista (STARTTLS) protege la mayoría de los correos en tránsito. Pero «oportunista» significa que un atacante de red puede suprimirlo sin que nadie lo detecte. Los ataques de downgrade SMTP explotan esta debilidad para interceptar mensajes en texto claro.

Dos protocolos responden a este problema: MTA-STS (RFC 8461) y DANE/TLSA (RFC 7672). Ambos imponen el cifrado TLS obligatorio entre servidores de correo. Pero sus mecanismos de confianza, sus requisitos previos y su adopción difieren.

Este artículo compara MTA-STS y DANE criterio por criterio. Identifica los casos de uso de cada uno y te guía hacia la mejor estrategia según tu infraestructura. Si gestionas dominios de correo, ya sea con un proveedor cloud o tus propios servidores MX, esta comparativa es para ti.

¿Cómo funcionan MTA-STS y DANE?

Ambos protocolos comparten el mismo objetivo: impedir que un servidor emisor envíe un correo en texto claro cuando el servidor destinatario soporta TLS. Pero utilizan canales de confianza diferentes.

MTA-STS: una política publicada vía HTTPS

MTA-STS se basa en dos elementos:

1. Un registro TXT DNS _mta-sts.captaindns.com que señala la existencia de la política y contiene un identificador de versión
2. Un archivo de texto alojado en HTTPS en https://mta-sts.captaindns.com/.well-known/mta-sts.txt que describe la política: servidores MX autorizados, modo (testing o enforce), duración de caché (max_age)

Cuando un servidor emisor (como Gmail u Outlook) quiere enviar un correo a tu dominio:

1. Consulta el DNS para _mta-sts.captaindns.com
2. Descarga la política vía HTTPS (canal autenticado por el certificado web)
3. Verifica que el servidor MX corresponde a la política
4. En modo enforce, rechaza enviar en texto claro o hacia un MX no incluido en la lista

El canal HTTPS es la clave: aunque un atacante manipule el tráfico SMTP, no puede falsificar el certificado HTTPS del dominio. La política permanece fiable.

Limitación: el TOFU (Trust On First Use). La primera vez que un servidor emisor contacta con tu dominio, no tiene aún una política en caché. Si un atacante bloquea esta primera solicitud HTTPS, el servidor emisor no sabrás que MTA-STS está activado. Las conexiones siguientes quedan protegidas gracias a la caché (válida hasta max_age).

DANE/TLSA: el certificado anclado en el DNS firmado

DANE funciona de forma diferente. Publica la huella (hash) del certificado TLS del servidor MX directamente en un registro TLSA del DNS:

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

El servidor emisor:

1. Consulta el DNS para los registros MX de captaindns.com
2. Recupera el registro TLSA asociado al servidor MX
3. Verifica la firma DNSSEC de la respuesta (obligatorio)
4. Compara el certificado TLS presentado por el servidor MX con el hash TLSA
5. Si todo coincide, la conexión se establece. En caso contrario, el correo no se envía

Ventaja: sin TOFU. Cada conexión se verifica individualmente mediante el DNS firmado. Un atacante no puede ni falsificar el registro TLSA (protegido por DNSSEC) ni presentar un certificado falso (el hash no coincidiría).

Limitación: DNSSEC obligatorio. Toda la cadena DNS, desde la raíz hasta tu zona, debe estar firmada. Si tu registrar o proveedor DNS no soporta DNSSEC, DANE es inutilizable.

Comparación técnica detallada

Criterio	MTA-STS (RFC 8461)	DANE/TLSA (RFC 7672)
Canal de confianza	HTTPS (PKI web)	DNSSEC
Protección 1.ª conexión	No (TOFU)	Sí
Dependencia DNSSEC	No	Obligatorio
Validación certificado	Hostname match (CN/SAN)	Hash del certificado (TLSA)
Modo testing nativo	Sí (mode: testing)	No
Informes de fallo	Vía TLS-RPT (RFC 8460)	Vía TLS-RPT (RFC 8460)
Complejidad de despliegue	Baja (2 registros DNS + archivo HTTPS)	Elevada (DNSSEC + registros TLSA + rotación)
Revocación	Modificar la política (plazo = max_age)	Modificar el registro TLSA (plazo = TTL)
Adopción emisores	Gmail, Outlook, Yahoo, Proton Mail	Postfix, Exim, algunos operadores UE
Estándar web requerido	Sí (certificado HTTPS válido)	No

Lo que muestra esta tabla

MTA-STS gana en accesibilidad: sin DNSSEC requerido, modo testing integrado, amplia adopción por los grandes proveedores. Es el protocolo que la mayoría de los dominios pueden desplegar de inmediato.

DANE gana en seguridad: sin TOFU, verificación criptográfica directa, sin dependencia de una autoridad de certificación web. Pero exige DNSSEC, lo que sigue siendo un obstáculo importante.

¿Qué protocolo elegir según su situación?

No hay una respuesta universal. La elección depende de tu infraestructura DNS y de tus restricciones.

Caso 1: tu registrar no soporta DNSSEC

Recomendación: solo MTA-STS.

Es la situación más habitual. La mayoría de los registrars para el público general no ofrecen DNSSEC o lo hacen difícil de configurar. MTA-STS es tu única opción, y es eficaz: Gmail, Outlook y Yahoo verifican y respetan las políticas MTA-STS.

Caso 2: tienes DNSSEC activado

Recomendación: DANE + MTA-STS.

Dispones de lo mejor de ambos mundos. DANE elimina el TOFU para los servidores emisores que lo soportan (principalmente Postfix en el ecosistema europeo). MTA-STS cubre a todos los demás emisores (Gmail, Outlook, Yahoo). Ambos protocolos coexisten sin conflictos.

Caso 3: utiliza Microsoft 365 o Google Workspace

Recomendación: MTA-STS.

Microsoft ha anunciado el soporte de DANE para Exchange Online con DNSSEC automático en los nuevos dominios MX mx.microsoft. Google Workspace no soporta DANE en recepción. En ambos casos, MTA-STS está plenamente soportado y es fácil de activar.

Caso 4: gestionas tus propios servidores MX

Recomendación: DANE + MTA-STS si DNSSEC está activo, MTA-STS en caso contrario.

Con tus propios servidores, controlas los certificados TLS y los registros DNS. Si DNSSEC está activo en tu zona, añade registros TLSA para cada servidor MX. Complementa con MTA-STS para cubrir a los emisores que no soportan DANE.

¿Por qué combinar MTA-STS y DANE?

Desplegar ambos protocolos simultáneamente es la mejor estrategia cuando tu infraestructura lo permite. He aquí por qué:

MTA-STS compensa las limitaciones de DANE:

• Los servidores emisores que no soportan DANE (Gmail, Yahoo) utilizan MTA-STS
• El modo testing de MTA-STS permite validar la configuración antes de imponer el cifrado

DANE compensa las limitaciones de MTA-STS:

• Sin TOFU: cada conexión se verifica desde la primera interacción
• Sin dependencia de una autoridad de certificación web: la confianza proviene del DNS firmado

Sin conflictos: un servidor emisor que soporta ambos verificará DANE en primer lugar (verificación DNS directa), luego MTA-STS como red de seguridad. Si uno de los dos falla, el otro toma el relevo.

Buenas prácticas de despliegue

Sea cual sea el protocolo elegido, sigue esta progresión:

1. Comienza con MTA-STS en modo testing: publica una política con mode: testing. Los servidores emisores enviarán los correos con normalidad, pero señalarán los fallos TLS en los informes TLS-RPT
2. Configura TLS-RPT: sin informes, estarás a ciegas. TLS-RPT (RFC 8460) te envía un resumen diario de los fallos de negociación TLS
3. Supervisa durante 1 a 2 semanas: revisa los informes. Corrige los problemas de certificado o de configuración MX antes de continuar
4. Pasa MTA-STS al modo enforce: los servidores emisores rechazarán a partir de ahora enviar en texto claro hacia tus MX
5. Añade DANE si DNSSEC está activo: publica los registros TLSA para cada servidor MX. Utiliza el verificador DANE/TLSA para validar tus registros y luego el validador de sintaxis DANE/TLSA para comprobar la forma cruda antes de la publicación

🎯 Plan de acción recomendado

1. Verifica tu configuración actual: lanza un análisis con el verificador MTA-STS para conocer el estado de tu dominio
2. Activa MTA-STS en modo testing: aloja tu política con CaptainDNS (primera herramienta gratis, después 3 €/mes sin IVA): dos registros DNS, ningún servidor web que gestionar
3. Configura TLS-RPT: añade un registro DNS _smtp._tls.captaindns.com para recibir los informes de fallos TLS
4. Pasa al modo enforce: cuando los informes confirmen cero errores, activa el modo enforce para bloquear las conexiones no cifradas
5. Evalúa DANE: si tu registrar soporta DNSSEC, añade registros TLSA para eliminar el TOFU y reforzar la seguridad

---

Asegura el transporte de tus correos ahora: aloja tu política MTA-STS (primera herramienta gratis, después 3 €/mes sin IVA) con CaptainDNS. Dos registros DNS, cero servidores web, protección activa en 5 minutos.

---

FAQ

¿Cuál es la diferencia entre MTA-STS y DANE?

MTA-STS (RFC 8461) publica una política de cifrado obligatorio mediante un archivo HTTPS. Se basa en la PKI web (certificados SSL) y funciona sin DNSSEC. DANE (RFC 7672) ancla el certificado TLS del servidor MX directamente en el DNS mediante registros TLSA firmados por DNSSEC. MTA-STS sufre del TOFU (primera conexión no protegida), DANE no. A cambio, DANE exige DNSSEC en toda la cadena DNS.

¿Se necesita DNSSEC para usar MTA-STS?

No. MTA-STS se basa en HTTPS, no en DNSSEC. Es su principal ventaja: cualquier dominio que disponga de alojamiento HTTPS puede activar MTA-STS. Con CaptainDNS, ni siquiera necesitas gestionar un servidor web: dos registros DNS CNAME son suficientes para publicar tu política.

¿Es DANE mejor que MTA-STS?

DANE ofrece una seguridad superior en un punto preciso: elimina el TOFU (Trust On First Use). Cada conexión se verifica individualmente mediante el DNS firmado. Pero DANE es mucho más difícil de desplegar (DNSSEC obligatorio) y está menos soportado por los grandes proveedores (Gmail y Yahoo no verifican DANE). En la práctica, MTA-STS protege más dominios gracias a su simplicidad.

¿Se pueden usar MTA-STS y DANE a la vez?

Sí, y es lo recomendado. Ambos protocolos coexisten sin conflictos. Un servidor emisor que soporta DANE verificará el registro TLSA como prioridad. Si solo soporta MTA-STS, utilizará la política HTTPS. Así obtienes la cobertura máxima: DANE para los servidores compatibles, MTA-STS para todos los demás.

¿Cuál es el problema del TOFU con MTA-STS?

TOFU (Trust On First Use) significa que la primera conexión de un servidor emisor hacia tu dominio no está protegida por MTA-STS. El servidor debe primero descargar y almacenar en caché tu política. Si un atacante bloquea esta primera solicitud HTTPS, el servidor no sabrás que MTA-STS está activo. Las conexiones siguientes quedan protegidas por la caché (válida durante max_age, típicamente 7 días). DANE elimina este problema porque la verificación se realiza vía DNS en cada conexión.

¿Google y Microsoft soportan DANE?

Microsoft despliega progresivamente el soporte de DANE para Exchange Online, con DNSSEC automático en los nuevos dominios MX. Google Gmail no soporta DANE en recepción (no publica registros TLSA), pero verifica y respeta los registros DANE de los dominios destinatarios en emisión. Ambos soportan plenamente MTA-STS como emisores.

¿Cómo probar mi configuración MTA-STS o DANE?

Para MTA-STS, verifica que tu registro TXT _mta-sts está publicado y que tu archivo de política es accesible en HTTPS. Para DANE, verifica que tus registros TLSA corresponden al certificado de tus servidores MX y que DNSSEC está activo en toda la cadena. CaptainDNS ofrece herramientas de verificación dedicadas para ambos protocolos.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

• Descargar comparativa (CSV)
• Descargar comparativa (JSON)

📖 Glosario

• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada vía HTTPS que impone el cifrado TLS para la recepción de correos en un dominio.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672 para SMTP). Mecanismo que ancla el certificado TLS en el DNS mediante registros TLSA, verificado por DNSSEC.
• TLSA: tipo de registro DNS utilizado por DANE para publicar la huella (hash) del certificado TLS de un servidor.
• TOFU: Trust On First Use. Modelo de seguridad en el que la primera conexión no se verifica, pero las siguientes se validan gracias a los datos almacenados en caché durante la primera interacción.
• DNSSEC: DNS Security Extensions. Sistema de firmas criptográficas que autentica las respuestas DNS e impide su falsificación.
• STARTTLS: extensión SMTP (RFC 3207) que permite negociar una conexión TLS tras el establecimiento de una conexión en texto claro en el puerto 25.
• PKI: Public Key Infrastructure. Sistema de certificados digitales utilizado por HTTPS (y por tanto MTA-STS) para autenticar los servidores.

📚 Guías de seguridad del transporte de correo relacionadas

• Ataques de downgrade SMTP: cómo funcionan y cómo protegerse: Mecanismo del STARTTLS stripping y soluciones de protección
• De testing a enforce: estrategia de despliegue MTA-STS progresiva: guía paso a paso del despliegue progresivo

Fuentes

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE)
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol
• RFC 8460 - SMTP TLS Reporting (TLS-RPT)
• Google Transparency Report - Email encryption in transit