Última actualización: julio de 2026

En resumen: DANE exige una entrega de correo cifrada y autenticada — pero solo si el servidor de correo receptor proporciona registros DNSSEC y TLSA. Solo unos pocos proveedores pueden hacerlo. Este artículo muestra quién puede hacer DANE (Microsoft 365, autoalojamiento), quién no (Google Workspace, los hosts compartidos alemanes) — y qué alternativa te queda.

¿Qué es DANE?

DANE (DNS-based Authentication of Named Entities, RFC 6698) usa un registro TLSA en el DNS de tu dominio “para señalar que un dominio y sus servidores de correo admiten DANE”. Un servidor de envío comprueba antes de la entrega si el certificado TLS del destinatario coincide con el registro TLSA. Esto hace que la autenticación sea “resistente a ataques de degradación y MITM” — la ventaja clave frente al cifrado puramente best-effort de SMTP.

El requisito duro: DNSSEC + TLSA en el MX

Aquí está la trampa que hace DANE inalcanzable para la mayoría de los usuarios. DANE tiene “dependencias directas de DNSSEC” — y “solo puedes confiar en los registros TLSA si activas DNSSEC para tu dominio”. En concreto se necesitan tres cosas, y en el operador de tu servidor de correo receptor:

  1. DNSSEC para la zona (registros DNS firmados),
  2. registros TLSA bajo _25._tcp.mail.tu-dominio que coincidan con el certificado del MX,
  3. un MX que presente exactamente este certificado.

Ese es el punto decisivo: DANE no es un ajuste que tú pongas por tu cuenta como cliente — el operador de tus buzones debe admitirlo. En un host compartido cuyo MX no publica TLSA, sencillamente no puedes “configurar” DANE.

Quién puede hacer DANE

Microsoft 365 (Exchange Online). Microsoft ha puesto SMTP DANE entrante con DNSSEC disponible con carácter general. La activación se hace vía PowerShell, con el tipo de TLSA recomendado 3 1 1 (DANE-EE) — la documentación de Microsoft recalca “que no deben usarse los valores 0 o 1 del campo certificate usage”. Detalles en nuestra guía de DANE para Microsoft 365.

Servidores autoalojados (p. ej. Mailcow). Si gestionas tu propio MX, tienes control total: firma la zona con DNSSEC, genera TLSA a partir del certificado del MX, publica. Esa es la vía clásica de DANE — consulta DANE para Mailcow.

Con tu propio MX detrás de un proveedor de DNS con DNSSEC. Algunos proveedores de DNS “pueden ofrecer … DNSSEC como un ajuste”. Si gestionas tu propio servidor de correo detrás de una zona así, puedes implementar DANE — técnicamente esto coincide con la vía del autoalojamiento.

Quién no puede hacer DANE (por ti)

Google Workspace. Google no publica registros TLSA para su MX — Google se apoya en MTA-STS para el transporte entrante (“autenticado con un certificado público válido”, TLS 1.2+). Así que para los dominios de Google Workspace DANE no viene al caso; la alternativa es MTA-STS para Google Workspace.

Los hosts compartidos alemanes (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain). Algunos ofrecen firma DNSSEC para tu zona — pero sus servidores de correo no publican registros TLSA. Sin TLSA en el MX no hay DANE. DNSSEC por sí solo (sin TLSA relacionado con el correo) no hace nada por la seguridad de transporte de tu email.

Qué usar en su lugar: MTA-STS

Para todos los que no puedan implementar DANE, MTA-STS es la alternativa práctica. Alcanza el mismo objetivo — entrega TLS autenticada y forzada — sin DNSSEC, pero mediante un archivo de política servido por HTTPS. Dónde funciona bien (Google, Microsoft, Mailcow) y dónde se complica (hosts compartidos), lo explicamos en MTA-STS en hosting compartido y las guías individuales para Google Workspace, Microsoft 365 y Mailcow.

Y en cualquier caso: añade TLS-RPT para recibir informes sobre la entrega TLS — tanto si acabas usando DANE como MTA-STS.

Verifica el resultado

El escáner MXAudit gratuito te muestra si tu dominio está firmado con DNSSEC, si existen registros TLSA para tu MX, y cómo están MTA-STS y TLS-RPT — la forma rápida de ver qué protección de transporte se aplica realmente a tu configuración.

Más información