DANE pone la huella del certificado de tu servidor de correo en el DNS, bajo el host MX al que pertenece, y la firma con DNSSEC para que un servidor emisor pueda verificar el certificado sin confiar en una autoridad de certificación pública. Es un estándar terminado, no un borrador: el RFC 7672 está en la vía de estándares desde octubre de 2015.
Los cuatro proveedores de buzón que deciden si llega la mayor parte de tu correo no publican ningún registro TLSA. Comprobamos Gmail, Outlook.com, Yahoo e iCloud el 22 de septiembre de 2026 y no encontramos ninguno. Eso no vuelve inútil a DANE, pero sí decide qué debes hacer primero, y la respuesta es MTA-STS.
DANE es un registro TLSA bajo tu host MX, y DNSSEC es el fundamento
Un registro TLSA guarda un hash del certificado o de la clave pública que presenta tu servidor de correo, publicado en _25._tcp. más el nombre del host MX. El RFC 6698 definió el tipo de registro en agosto de 2012; el RFC 7672 definió cómo lo usa SMTP en octubre de 2015, y el RFC 7671 añadió orientación operativa el mismo mes.
El ancla de confianza es DNSSEC, y ese no es un detalle que puedas aplazar. Un servidor emisor conoce la huella de tu certificado a través del DNS, así que la respuesta tiene que estar autenticada en el DNS. Sin una cadena firmada, cualquiera que pueda manipular la consulta puede borrar el registro TLSA y el emisor recae en TLS sin autenticar, que es justo el ataque que DANE existe para detener. Un registro TLSA publicado en una zona sin firmar es decoración.
Por eso DANE también es una propiedad de tu host MX y no de tu dominio. El registro cuelga de cada nombre de host de tu conjunto MX, así que un dominio con tres hosts MX necesita tres conjuntos de registros, y todos ellos tienen que mantenerse al día con el certificado de esa máquina.
Solo dos de los cuatro usos de certificado son válidos para SMTP
TLSA lleva un campo de uso con cuatro valores, y la sección 3.1.3 del RFC 7672 descarta la mitad de ellos para el correo.
| Uso | Nombre | Válido para SMTP |
|---|---|---|
| 0 | PKIX-TA | No |
| 1 | PKIX-EE | No |
| 2 | DANE-TA | Sí |
| 3 | DANE-EE | Sí |
La razón está dicha con claridad en el RFC: no se puede esperar que los MTA cliente de SMTP estén configurados con un conjunto suficientemente completo de CA públicas de confianza. Los usos 0 y 1 piden al servidor emisor que valide también contra el sistema de CA públicas, y un servidor de correo no es un navegador. La especificación dice que el tratamiento por parte del cliente de esos dos es indefinido y que los clientes pueden tratar esos registros como inutilizables, así que publicar uno es jugárselo a la implementación de otro.
En la práctica el campo se asienta en una sola forma. Posteo publica cinco registros TLSA por host MX, todos de uso 3, selector 1 y tipo de coincidencia 1: DANE-EE sobre la clave pública del sujeto, con hash SHA-256. Eso es 3 1 1, y es la forma que conviene copiar. El selector 1 importa porque cubre la clave y no el certificado, así que renovar un certificado con la misma clave no rompe el registro.
Ninguno de los cuatro grandes proveedores de buzón publica TLSA
Consultamos todos los hosts MX de cada dominio de abajo buscando un registro TLSA en _25._tcp., a través tanto de Google Public DNS como de Cloudflare DNS, el 22 de septiembre de 2026. Ambos extremos coincidieron en todas las filas.
| Dominio | TLSA en sus hosts MX |
|---|---|
| gmail.com | Ninguno |
| outlook.com | Ninguno |
| yahoo.com | Ninguno |
| icloud.com | Ninguno |
| t-online.de | Ninguno |
| posteo.de | 5 registros por host, todos 3 1 1 |
| mailbox.org | 1 o 2 registros por host |
| gmx.net | 2 registros por host |
| web.de | 1 registro por host |
| freenet.de | 2 registros por host |
| protonmail.ch | 2 registros por host |
| nic.cz | 1 registro por host |
| rijksoverheid.nl | 2 registros por host |
El patrón es regional más que técnico. Los proveedores de buzón alemanes y suizos, el registro de dominios checo y el gobierno neerlandés publican TLSA y firman sus zonas. Los cuatro proveedores cuyas decisiones de filtrado importan de verdad a la mayoría de emisores no lo hacen, y t-online.de es la excepción alemana que demuestra que la división es una decisión de cada operador y no una regla nacional.
Exchange Online publica TLSA en sus hosts MX nuevos y no en los antiguos
Microsoft es el único gran operador que se está moviendo. Los inquilinos cuyo MX apunta al nombre más reciente mx.microsoft llevan cuatro registros TLSA, mezclando uso 2 y uso 3, en una zona firmada con DNSSEC. Lo vimos en kpn.com y en sidn.nl, que resuelven a hosts bajo mx.microsoft.
El nombre de host antiguo de Exchange Online bajo mail.protection.outlook.com no lleva nada, y tampoco el nombre de consumo que hay detrás de outlook.com. Así que si Microsoft admite DANE no tiene una respuesta única: depende de qué nombre MX le tocó a tu inquilino, y eso conviene comprobarlo en tu propio dominio en lugar de leerlo en un anuncio.
Un host respondió SERVFAIL, y eso no es lo mismo que no tener registro
Consultar microsoft-com.mail.protection.outlook.com devolvió SERVFAIL desde Google Public DNS y NXDOMAIN desde Cloudflare DNS. Son afirmaciones distintas, y solo una de ellas es una respuesta.
Solo NOERROR y NXDOMAIN te dicen algo sobre la zona. Un SERVFAIL te dice que la consulta falló, lo cual es un hecho sobre el resolutor y la ruta, no sobre si el registro existe. Un verificador que informa de que no hay DANE ante un SERVFAIL está afirmando algo que no midió, y quien lo lee actúa como si el operador hubiera decidido no publicar.
Por eso cada fila de la tabla de arriba se leyó dos veces, a través de dos resolutores independientes, y por eso el único host que se contradijo a sí mismo se describe aquí en lugar de recibir un veredicto.
MTA-STS es la política que puedes publicar hoy sin DNSSEC
MTA-STS resuelve el mismo problema con un ancla de confianza distinta. El RFC 8461, publicado en septiembre de 2018 por autores de Google, Oath, Comcast y Microsoft, pone un archivo de política tras HTTPS en un host conocido y apunta a él desde un registro TXT. La PKI web autentica la política, así que no hace falta DNSSEC.
| DANE para SMTP | MTA-STS | |
|---|---|---|
| Estándar | RFC 7672, 2015 | RFC 8461, 2018 |
| Ancla de confianza | DNSSEC | PKI web sobre HTTPS |
| Se publica como | TLSA por host MX | Registro TXT más un archivo de política |
| Necesita zona firmada | Sí | No |
| Apoyo de los grandes proveedores | Escaso | Habitual |
No son rivales y un dominio puede publicar ambos. Si tu zona está firmada y gestionas tus propios servidores de correo, DANE es más fuerte, porque no depende del sistema de autoridades de certificación al que sustituye. Si tu zona no está firmada, MTA-STS es el único de los dos que puedes desplegar, y es el que respetan los grandes proveedores.
Qué hacer, y en qué orden
- Comprueba qué publican ya tus hosts MX, con nuestra consulta de registros MX, antes de decidir nada. Si estás en una plataforma gestionada, la respuesta la cambia tu proveedor, no tú.
- Publica MTA-STS. Funciona sin DNSSEC, los grandes proveedores lo aplican y es el cambio que afecta a la entrega real este trimestre. Nuestro verificador de MTA-STS lee el registro TXT y el archivo de política a la vez.
- Publica TLS-RPT. Es un solo registro TXT, no cambia nada de la entrega y es como averiguas si alguna de las dos políticas se está respetando. Nuestro verificador de TLS-RPT valida el registro, incluida la etiqueta de versión sensible a mayúsculas que descarta en silencio un registro escrito en minúsculas.
- Añade DANE solo si firmas tu zona y gestionas tu propio MX. Publica
3 1 1por host, y rota el registro antes que el certificado, nunca después. - Nunca publiques TLSA en una zona sin firmar. No autentica nada y te compromete a mantener un registro al día con un certificado sin ganar nada a cambio.
Por qué comprobamos MTA-STS y TLS-RPT pero no DANE
Un veredicto de DANE necesita una decisión de confianza DNSSEC, y nuestros verificadores se ejecutan en tu navegador sobre DNS-over-HTTPS. El bit AD de una respuesta DoH es la afirmación del resolutor de que validó la cadena, no la prueba de que la cadena valida. Dar un resultado DANE en verde apoyado en la afirmación de otro sería justo el tipo de veredicto seguro y no ganado que estas herramientas existen para evitar, así que no lo ofrecemos.
Los registros de transporte que podemos leer por completo, los leemos por completo. Todo lo demás sobre tu configuración de envío es otra capa, y nuestra guía de autenticación de email cubre cómo encajan SPF, DKIM y DMARC por encima de ella. En los dominios que analizamos para el Informe de Entregabilidad de Email de Unspam 2026, el 48% publica una política DMARC, que es el trabajo pendiente que mueve más correo del que jamás moverá TLSA.
Para ver qué lleva de verdad un mensaje real cuando llega, haz una prueba de spam gratuita.
