¿Qué es la generación de informes TLS? Cómo detectan los informes TLS de SMTP los errores en la entrega de correos electrónicos
por
Última actualización:
Tiempo de lectura: 6 min
La mayoría de los fallos de TLS en SMTP se producen sin que nadie se dé cuenta. Un certificado caduca, un servidor deja de admitir STARTTLS o un atacante fuerza una degradación de seguridad, y el correo electrónico se envía sin cifrar o nunca llega a su destino, sin que haya ninguna alerta que explique el motivo. Los informes de TLS sirven precisamente para subsanar esa carencia.
Tal y como se define en el RFC 8460, el sistema de informes TLS de SMTP (TLS-RPT) ofrece a los propietarios de dominios una forma estandarizada de saber cuándo falla el cifrado TLS entre servidores de correo y por qué. En este artículo se explica cómo funciona el TLS de SMTP, por qué puede fallar, cómo es un informe TLS-RPT real campo por campo y los tipos específicos de fallos con los que te encontrarás una vez que empieces a leerlos.
¿Qué es el SMTP TLS y por qué falla?
Para entender por qué es importante la generación de informes TLS, conviene saber por qué el protocolo SMTP lo necesitaba en primer lugar.
El protocolo SMTP no se diseñó pensando en el cifrado
El SMTP se remonta a 1982. En aquella época, el correo electrónico era una red pequeña y de confianza, y el protocolo se diseñó sin una capa de cifrado. Por defecto, los mensajes se transmitían entre servidores en texto sin cifrar.
Esa brecha permaneció abierta durante décadas. El cifrado se incorporó más tarde, como una opción y no como un requisito, y ahí es donde surge el siguiente problema.
STARTTLS hizo que el cifrado fuera opcional, no garantizado
STARTTLS permite que un servidor emisor solicite a un servidor receptor que cambie una conexión en texto plano por una cifrada. Si ambas partes lo admiten, el mensaje se transmite cifrado. Si alguna de las partes no lo admite, o si algo interfiere en el proceso de establecimiento de la conexión, esta vuelve discretamente al texto plano y el correo electrónico se envía de todos modos.
Esa solución alternativa es el problema fundamental que TLS-RPT se diseñó para poner de manifiesto. El protocolo SMTP estándar no ofrece ninguna indicación de cuándo se ha enviado un mensaje sin cifrar, ya sea debido a una configuración errónea o a que alguien haya eliminado deliberadamente el comando STARTTLS durante la transmisión.
¿Qué es el informe TLS (TLS-RPT)?
TLS-RPT es un estándar de generación de informes, definido en el RFC 8460, que permite a los propietarios de dominios recibir informes periódicos y estructurados sobre los fallos en las conexiones TLS de los correos electrónicos enviados a su dominio. No evita que se produzcan los fallos, sino que te indica cuándo se han producido, con qué frecuencia y por qué, para que puedas solucionar el problema subyacente.
Para obtener un desglose completo de los campos del informe del RFC 8460 y saber cómo publicar un registro DNS TLS-RPT, consulta nuestra guía detallada sobre TLS-RPT.
Relación entre TLS-RPT y MTA-STS
TLS-RPT y MTA-STS funcionan en conjunto. MTA-STS es el mecanismo de aplicación: indica a los servidores remitentes que el correo dirigido a tu dominio debe enviarse a través de una conexión cifrada y autenticada, o no enviarse en absoluto. TLS-RPT es el mecanismo de visibilidad: informa de lo que ha ocurrido cada vez que no se ha podido establecer esa conexión cifrada. Uno establece la norma y el otro te avisa cuando se activa dicha norma.
Para conocer los pasos detallados sobre cómo configurar MTA-STS para tu dominio, puedes consultar nuestra guía de implementación de MTA-STS.
Cómo funciona la generación de informes SMTP TLS, paso a paso
- El propietario del dominio publica un registro DNS TLS-RPT, que indica a los servidores de correo emisores dónde deben enviar los informes de error.
- Un servidor de envío intenta entregar el correo utilizando TLS, normalmente a través de STARTTLS.
- Si ese intento falla, el servidor de envío registra el motivo del fallo.
- Aproximadamente una vez cada 24 horas, el servidor remitente recopila esos resultados en un informe JSON y lo envía, normalmente por correo electrónico o mediante una solicitud POST por HTTPS, a la dirección que figura en el registro TLS-RPT del dominio.
- El propietario del dominio abre el informe y busca patrones: qué servidores fallan, con qué frecuencia y por qué.
El contenido de un informe TLS-RPT real
Los informes TLS-RPT se reciben en formato JSON, que no es precisamente legible para los humanos. A continuación se muestra un ejemplo abreviado y realista basado en el formato RFC 8460, con un resumen de una sesión correcta y otro de una fallida, seguido de una explicación en lenguaje sencillo de cada campo.
JSON
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-07-01T00:00:00Z",
"end-datetime": "2026-07-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "[email protected]",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: enforce",
"mx: mail.yourdomain.com",
"max_age: 604800"
],
"policy-domain": "yourdomain.com"
},
"summary": {
"total-successful-session-count": 4821,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail.yourdomain.com",
"receiving-mx-helo": "mail.yourdomain.com",
"receiving-ip": "203.0.113.45",
"failed-session-count": 2,
"additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail2.yourdomain.com",
"receiving-ip": "203.0.113.46",
"failed-session-count": 1
}
}
}
]
}
Qué significa realmente cada campo
- nombre-de-la-organización: Quién envió el informe. Normalmente, un gran proveedor de correo electrónico como Google, Microsoft o Yahoo.
- rango de fechas: El periodo que abarca el informe. La mayoría de los remitentes elaboran sus informes sobre una base de 24 horas continuas.
- datos-de-contacto / id-del-informe: Datos para ponerse en contacto con el remitente y un identificador único para este informe concreto. Resulta útil si necesitas hacer referencia al informe en un ticket de asistencia.
- tipo-de-política / cadena-de-política: La política MTA-STS (o DANE) que el servidor remitente detectó para tu dominio en ese momento, tal y como se obtuvo. Esto te permite confirmar que tu política publicada coincide con lo que los remitentes reciben realmente.
- número-total-de-sesiones-exitosas / número-total-de-sesiones-fallidas: La cifra principal. En este ejemplo, 4.821 de los 4.824 intentos de entrega tuvieron éxito y 3 fallaron.
- detalles-del-error: Una entrada por tipo de error, con un recuento. Esta es la parte sobre la que hay que actuar:
– certificado-caducado: El certificado TLS había caducado en 2 de las sesiones fallidas. Solución: renovar y reinstalar el certificado.
– starttls-not-supported: El servidor receptor (mail2.tudominio.com) no respondió en absoluto a STARTTLS en una sesión. Solución: comprueba la configuración TLS del servidor, ya que puede faltar o estar mal configurada.
Tipos habituales de errores de TLS que aparecerán en los informes
Los informes TLS-RPT utilizan un conjunto fijo de valores de tipo de resultado. A continuación se indican los que aparecen con más frecuencia, qué significa cada uno de ellos y cómo actuar en cada caso.
Certificado caducado
El certificado TLS del servidor receptor había caducado. Renueva el certificado antes de que caduque y configura un recordatorio con suficiente antelación a la próxima fecha de caducidad.
Discrepancia en el nombre del certificado
El certificado presentado no coincide con el nombre de host que esperaba el servidor remitente. Esto suele deberse a un certificado mal configurado o a un registro DNS que apunta a un host incorrecto.
STARTTLS no es compatible
El servidor receptor no respondió en absoluto al comando STARTTLS. Comprueba que TLS esté correctamente habilitado en ese servidor de correo y verifica que el software del servidor lo admita realmente.
Error al recuperar la política MTA-STS
El servidor de envío no ha podido recuperar tu archivo de política MTA-STS a través de HTTPS. Comprueba que se pueda acceder al archivo de política, que tenga el formato correcto y que se sirva con un certificado válido.
Versión de TLS demasiado antigua
La conexión ha intentado negociar una versión de TLS que el servidor de origen considera obsoleta o insegura. Actualiza la configuración TLS de tu servidor de correo para descartar las versiones antiguas del protocolo. En concreto, para problemas de validación relacionados con los certificados, consulta nuestra guía sobre DANE.
Por qué es importante la generación de informes SMTP TLS
La generación de informes SMTP TLS resulta beneficiosa por una amplia variedad de razones. A continuación se enumeran algunas de ellas:
Seguridad: Detección de ataques de degradación
TLS-RPT detecta los casos en los que se ha forzado una conexión a un canal no cifrado, que es precisamente el patrón que subyace a un ataque de degradación de tipo «man-in-the-middle» (MITM). Sin este tipo de notificaciones, ese tipo de interceptación puede prolongarse indefinidamente sin que nadie se dé cuenta.
Visibilidad: Elimine los ángulos muertos
Sin TLS-RPT, no hay ninguna forma fiable de saber por qué han fallado los correos electrónicos enviados a tu dominio, ni si se han entregado sin cifrado. Los informes muestran exactamente dónde y por qué se ha interrumpido una conexión TLS, en lugar de dejarte a ti las conjeturas.
Eficacia: Solución de problemas más rápida
Revisar los registros del servidor para localizar un problema de entrega lleva tiempo. Los informes de TLS-RPT señalan directamente el servidor en el que se ha producido el fallo, el tipo de fallo y la frecuencia con la que se ha producido, lo que reduce el tiempo de resolución de problemas de días a minutos.
Conclusión: Cómo PowerDMARC simplifica la generación de informes TLS
Los informes TLS-RPT se reciben como archivos JSON sin procesar, y leerlos manualmente para cada una de las fuentes de envío se vuelve muy tedioso al poco tiempo. PowerDMARC convierte automáticamente estos informes en paneles de control fáciles de leer, agrupados por tipo de resultado y por fuente de envío, para que puedas ver qué está fallando y dónde sin tener que abrir ni un solo archivo JSON.
Ayudamos a los titulares de dominios:
- Analiza automáticamente el JSON sin procesar y lo convierte en paneles de control fáciles de leer, sin necesidad de descodificar manualmente los archivos de informe TLS-RPT.
- Filtrar por dos vistas del informe: por origen de envío (modo de política, recuento de sesiones, totales de entrega) y por resultado (sesiones correctas arriba, fallidas abajo).
- El análisis detallado no permite ampliar una sesión fallida ni ver el nombre de host, la dirección IP, el número de fallos y el motivo del servidor receptor, por lo que la solución no resulta evidente a simple vista.
- Sube archivos JSON, ZIP o GZ con un historial de subidas para poder consultar los informes anteriores en cualquier momento.
- Genera y valida automáticamente los registros CNAME necesarios para que los informes empiecen a llegar con una configuración de DNS con un solo clic, además de una dirección configurable a la que se envían los informes agregados.
- Exporta archivos JSON sin procesar cuando necesites el archivo original para un ticket o para un análisis más detallado, con permisos detallados que controlan quiénes de la cuenta pueden subir informes.
Empieza una prueba gratuita o reserva una demostración para verlo con los datos de tu propio dominio.
Preguntas frecuentes
1. ¿Para qué se utilizan los informes TLS?
Los informes TLS se utilizan para detectar y diagnosticar fallos en el envío de correos electrónicos cifrados, como certificados caducados, servidores mal configurados y ataques de degradación, mediante la generación de informes periódicos sobre qué ha fallado y por qué.
2. ¿El informe SMTP TLS es lo mismo que el TLS-RPT?
Sí. «Informes SMTP TLS» y «TLS-RPT» hacen referencia al mismo estándar RFC 8460. TLS-RPT es la denominación abreviada del protocolo.
3. ¿Cómo configuro los informes TLS para mi dominio?
Para configurarlo en tu dominio, solo tienes que publicar un registro DNS TLS-RPT en el que se especifique dónde deben enviarse los informes. Puedes generar uno con nuestro generador de registros TLS-RPT y comprobar que está activo con nuestro verificador de TLS-RPT.
4. ¿Qué ocurre si no activo TLS-RPT?
Si no activas TLS-RPT, los servidores de correo seguirán intentando el cifrado TLS por su cuenta, pero no tendrás visibilidad alguna sobre los fallos. Los ataques de degradación, los certificados caducados y los servidores mal configurados pueden pasar desapercibidos indefinidamente.
5. ¿Funciona TLS-RPT sin MTA-STS?
Sí, TLS-RPT puede informar de los fallos de TLS de forma independiente. Sin embargo, resulta más útil cuando se combina con MTA-STS, ya que MTA-STS garantiza la entrega cifrada y TLS-RPT informa de lo que ocurrió cuando se activó esa garantía.
6. ¿Con qué frecuencia se envían los informes TLS de SMTP?
La mayoría de los remitentes generan y envían informes aproximadamente una vez cada 24 horas, aunque el intervalo exacto puede variar según el proveedor.
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- ¿Qué es la generación de informes TLS? Cómo detectan los informes TLS de SMTP los fallos en la entrega de correos electrónicos - 9 de julio de 2026
- Los mejores servidores MCP de DMARC en 2026: conecta la IA a tus datos de autenticación de correo electrónico - 9 de julio de 2026
- Caso práctico de DMARC para MSP: The Great Geek amplía sus servicios de seguridad de correo electrónico para pymes con PowerDMARC - 25 de junio de 2026
