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

Por CaptainDNS
Publicado el 10 de marzo de 2026

Esquema comparativo de los protocolos MTA-STS y DANE para la seguridad del 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
Aloje su política MTA-STS de forma gratuita con CaptainDNS: 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 le guía hacia la mejor estrategia según su infraestructura. Si gestiona dominios de correo, ya sea con un proveedor cloud o sus propios servidores MX, esta comparativa es para usted.

¿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:

Un registro TXT DNS _mta-sts.captaindns.com que señala la existencia de la política y contiene un identificador de versión
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 su dominio:

Consulta el DNS para _mta-sts.captaindns.com
Descarga la política vía HTTPS (canal autenticado por el certificado web)
Verifica que el servidor MX corresponde a la política
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 su dominio, no tiene aún una política en caché. Si un atacante bloquea esta primera solicitud HTTPS, el servidor emisor no sabrá 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:

Consulta el DNS para los registros MX de captaindns.com
Recupera el registro TLSA asociado al servidor MX
Verifica la firma DNSSEC de la respuesta (obligatorio)
Compara el certificado TLS presentado por el servidor MX con el hash TLSA
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 su zona, debe estar firmada. Si su registrar o proveedor DNS no soporta DNSSEC, DANE es inutilizable.

Diagrama comparativo de los flujos de verificación MTA-STS y DANE durante el envío de un correo

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 su infraestructura DNS y de sus restricciones.

Caso 1: su 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 su única opción, y es eficaz: Gmail, Outlook y Yahoo verifican y respetan las políticas MTA-STS.

Caso 2: tiene DNSSEC activado

Recomendación: DANE + MTA-STS.

Dispone 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: gestiona sus propios servidores MX

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

Con sus propios servidores, usted controla los certificados TLS y los registros DNS. Si DNSSEC está activo en su zona, añada registros TLSA para cada servidor MX. Complemente con MTA-STS para cubrir a los emisores que no soportan DANE.

Árbol de decisión para elegir entre MTA-STS, DANE o ambos según su infraestructura

¿Por qué combinar MTA-STS y DANE?

Desplegar ambos protocolos simultáneamente es la mejor estrategia cuando su 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, siga esta progresión:

Comience con MTA-STS en modo testing: publique 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
Configure TLS-RPT: sin informes, estará a ciegas. TLS-RPT (RFC 8460) le envía un resumen diario de los fallos de negociación TLS
Supervise durante 1 a 2 semanas: revise los informes. Corrija los problemas de certificado o de configuración MX antes de continuar
Pase MTA-STS al modo enforce: los servidores emisores rechazarán a partir de ahora enviar en texto claro hacia sus MX
Añada DANE si DNSSEC está activo: publique los registros TLSA para cada servidor MX. Utilice el verificador DANE/TLSA para validar sus registros

🎯 Plan de acción recomendado

Verifique su configuración actual: lance un análisis con el verificador MTA-STS para conocer el estado de su dominio
Active MTA-STS en modo testing: aloje su política de forma gratuita con CaptainDNS: dos registros DNS, ningún servidor web que gestionar
Configure TLS-RPT: añada un registro DNS _smtp._tls.captaindns.com para recibir los informes de fallos TLS
Pase al modo enforce: cuando los informes confirmen cero errores, active el modo enforce para bloquear las conexiones no cifradas
Evalúe DANE: si su registrar soporta DNSSEC, añada registros TLSA para eliminar el TOFU y reforzar la seguridad

Asegure el transporte de sus correos ahora: aloje su política MTA-STS de forma gratuita 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 necesita gestionar un servidor web: dos registros DNS CNAME son suficientes para publicar su 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í obtiene 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 su dominio no está protegida por MTA-STS. El servidor debe primero descargar y almacenar en caché su política. Si un atacante bloquea esta primera solicitud HTTPS, el servidor no sabrá 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, verifique que su registro TXT _mta-sts está publicado y que su archivo de política es accesible en HTTPS. Para DANE, verifique que sus registros TLSA corresponden al certificado de sus 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.

📖 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