Última actualización: julio de 2026
En resumen: la seguridad en la capa de transporte protege tus correos contra ataques de degradación e intermediario (MitM). Aunque los 25 proveedores soportan SPF, DKIM y DMARC, DANE de entrada solo está disponible en 3 proveedores (Mailcow, Microsoft 365, Infomaniak) y MTA-STS gestionado solo en 3 proveedores (Google Workspace, Mailcow, Microsoft 365). Abajo tienes la tabla comparativa completa de los 25 proveedores con las razones técnicas exactas.
Mientras que SPF, DKIM y DMARC aseguran la autenticidad del remitente y la integridad de los mensajes, DANE y MTA-STS protegen la capa de transporte (SMTP) entre los servidores implicados. Obligan a establecer una conexión cifrada mediante TLS y evitan ataques de intermediario (Man-in-the-Middle) y de degradación de protocolo.
Poder usar estos mecanismos de protección avanzados depende directamente de tu proveedor de correo y de su arquitectura técnica. Nuestro directorio de proveedores demuestra que en el hosting compartido tradicional suelen faltar las condiciones necesarias, como registros TLSA firmados por DNSSEC en los servidores MX o un certificado HTTPS para el subdominio de política.
Tabla completa: DANE y MTA-STS en los 25 proveedores
La siguiente tabla detalla el estado exacto de los 25 proveedores de nuestra matriz técnica respecto a DANE entrante (a través de registros TLSA) y MTA-STS gestionado (mediante subdominios de política y registros DNS).
Análisis técnico detallado por categoría
1. Por qué la mayoría de hostings compartidos no pueden ofrecer DANE
Para que DANE entrante funcione correctamente, los servidores de correo oficiales de tu proveedor (por ejemplo, en IONOS, Strato, All-Inkl o DonDominio) deben estar firmados con DNSSEC y publicar registros TLSA válidos en el DNS que vinculen sus certificados TLS. Como detallamos en DANE para correo: quién puede usarlo, los grandes proveedores de hosting compartido no publican registros TLSA en sus servidores de correo de uso común (MX):
- IONOS, Strato, All-Inkl, checkdomain, domainfactory, united-domains: Los servidores oficiales carecen de registros TLSA (
MX has no TLSA; see overview). Por tanto, implementar DANE para un dominio cliente en estos sistemas compartidos es técnicamente inviable. - Gandi, OVHcloud, GoDaddy, o2switch, LWS, DonDominio, Dinahosting, cdmon, Raiola Networks, Hostinger, webgo: Igualmente, estos proveedores no mantienen registros TLSA en sus servidores MX estándar (
MX has no TLSA; see overview). - Hetzner DNS, Netcup, Cloudflare, Amazon Route 53: Al ser especialistas en DNS (o cuando se utilizan únicamente consolas DNS sin buzones gestionados), ofrecen soporte completo de DNSSEC y registros TLSA en sus paneles. Sin embargo, como no operan los buzones de recepción de tu dominio, DANE solo se aplica si administras tu propio servidor MX (
only via own MX; see overview).
2. Por qué Google Workspace y Microsoft 365 adoptan enfoques distintos
Las dos principales suites de correo en la nube muestran una estrategia diferente en cuanto a la seguridad de la capa de transporte:
- Microsoft 365 (Exchange Online): Microsoft soporta tanto DANE entrante como MTA-STS. Puedes activar DANE para tu dominio personalizado mediante DNSSEC y comandos de PowerShell (configurar DANE/DNSSEC en Microsoft 365). Al mismo tiempo, ofrece una configuración totalmente gestionada de MTA-STS (MTA-STS en Microsoft 365).
- Google Workspace: Google no publica registros TLSA para sus intercambiadores de correo oficiales (
no inbound DANE; uses MTA-STS (see overview)). En su lugar, Google apuesta al 100 % por MTA-STS como estándar para forzar la conexión cifrada (configurar MTA-STS en Google Workspace).
3. Por qué MTA-STS gestionado es poco práctico en hosting compartido
MTA-STS no solo requiere un registro DNS TXT, sino también alojar un archivo de política (mta-sts.txt) exactamente en el subdominio mta-sts.tudominio.es mediante HTTPS y con un certificado SSL/TLS válido. Como explicamos en MTA-STS en hosting compartido, esto supone un obstáculo técnico importante en las plataformas de alojamiento tradicional (no managed MTA-STS; see mta-sts-shared-hosting):
- Proveedores como IONOS, Strato, All-Inkl, Netcup, OVHcloud, o Hostinger no ofrecen un servicio automatizado que aloje y renueve el certificado de este subdominio de política.
- Para activar MTA-STS en estos entornos, debes crear manualmente un subdominio dedicado con espacio web y gestionar el certificado SSL, o recurrir a servicios externos de alojamiento de políticas.
4. Servidores autoalojados: Control total con Mailcow
Si necesitas el máximo nivel de seguridad en el transporte y deseas mantener DANE y MTA-STS funcionando en paralelo, administrar tu propio servidor de correo es la solución más completa.
Con Mailcow gestionas tu propia infraestructura en contenedores. Como tienes control absoluto sobre la zona DNS y los certificados TLS de tu servidor MX (mail.tudominio.es), Mailcow genera automáticamente los registros TLSA exactos para DANE y sirve la política de MTA-STS desde su propia interfaz web (configurar MTA-STS con Mailcow).
Verifica tu configuración con MXAudit
Independientemente del proveedor o del estándar de transporte que utilices, revisa siempre la configuración de tu dominio con el escaner gratuito MXAudit después de actualizar tu DNS. La herramienta realiza un análisis instantáneo de toda tu pila de seguridad de correo — verificando los registros SPF, DKIM, y DMARC, y comprobando en segundos si tu dominio cuenta con registros TLSA válidos para DANE y una política MTA-STS operativa.
Más información
- RFC 6698 — DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (consultado el 17 de julio de 2026)
- RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) (consultado el 17 de julio de 2026)
- DANE para correo: quién puede usarlo — Guía completa sobre los requisitos de TLSA y DNSSEC
- MTA-STS en hosting compartido — Análisis técnico sobre el alojamiento de políticas HTTPS
- Guías de seguridad de correo por proveedor — Resumen de los 25 proveedores y guías paso a paso