¿Qué es el informe SMTP TLS (TLS-RPT)?

Dado que las organizaciones dependen cada vez más del correo electrónico como principal medio de comunicación, no se puede exagerar la importancia de fortificar estos canales frente a posibles amenazas. La seguridad de la capa de transporte(TLS) garantiza la confidencialidad e integridad de los datos transmitidos a través de las redes. 

SMTP TLS Reporting (TLS-RPT) es un protocolo crítico que funciona junto con MTA-STS para garantizar que sus correos electrónicos se entregan de forma segura. Al proporcionar información detallada sobre los problemas de entrega de correo electrónico, TLS-RPT ayuda a los propietarios de dominios a mantener la integridad y confidencialidad de sus comunicaciones. En esta completa guía, exploraremos qué son los informes SMTP TLS, cómo funcionan y por qué son esenciales para su estrategia de seguridad del correo electrónico."

Varios protocolos ayudan a cifrar los canales de mensajes SMTP para evitar que los ciberatacantes intercepten las comunicaciones por correo electrónico. Entre ellos se encuentran STARTTLS, DANE y MTA-STS. Sin embargo, cuando fallan los intentos de cifrado al utilizar estos protocolos, es posible que no se entregue el correo electrónico. TLS-RPT (descrito en RFC 8460) proporciona un mecanismo de retroalimentación para informar sobre estos fallos de entrega.

Recomendamos encarecidamente el uso de TLS-RPT junto con la solución MTA-STS MTA-STS. Vamos a entender cómo estos protocolos trabajan juntos para reforzar la seguridad del correo electrónico.

¿Qué es TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) es un estándar para informar de problemas de entrega de correo electrónico cuando éste no está cifrado con TLS. Su importancia en la autenticación del correo electrónico va de la mano con la razón de activar el cifrado TLS para los correos electrónicos. 

El cifrado TLS garantiza que todos los correos electrónicos enviados se entreguen de forma segura. En caso de que la conexión no sea segura, muchas veces puede fallar la entrega de los correos electrónicos. TLS-RPT permite a los propietarios de dominios supervisar la entrega de correos electrónicos y los fallos de conexión. Los informes pueden contener información sobre: 

• Problemas de gestión de la política MTA-STS 
• Motivo y tipo de fallo en la entrega
• Dirección IP de los agentes de transferencia de correo electrónico remitentes y receptores
• Recuento total de sesiones de conexión TLS exitosas y fallidas 

Esto proporciona visibilidad sobre sus canales de correo electrónico y la capacidad de contrarrestar más rápidamente los problemas de entregabilidad.

Simplifique la generación de informes SMTP TLS con PowerDMARC.

¿Cómo funcionan los informes TLS?

En la comunicación por correo electrónico SMTP, el cifrado TLS es "oportunista". Esto significa que si no se puede negociar un canal cifrado, el correo electrónico se sigue enviando en formato no cifrado (texto sin formato). De hecho, hace casi 4 décadas, los protocolos de correo electrónico SMTP no soportaban el cifrado TLS. Hubo que adaptarlo más tarde en forma del comando STARTTLS. 

El comando STARTTLS sólo se emite en comunicaciones SMTP si ambas partes soportan encriptación TLS. De lo contrario, el correo electrónico seguirá enviándose en texto plano. 

Para deshacerse del cifrado oportunista en SMTP, se introdujo MTA-STS (RFC 8461). El protocolo MTA-STS garantiza que los correos electrónicos se cifran antes de ser entregados. Su servidor de correo electrónico o Agente de Transferencia de Correo (MTA) negocia con el servidor receptor para ver si soporta el comando STARTTLS. Si lo hace, el correo electrónico se encripta con TLS y se entrega. De lo contrario, la entrega falla.

Explicación paso a paso del funcionamiento de TLS-RPT

1. Comprender el proceso de enlace TLS

El handshake de Seguridad de Capa de Transporte (TLS handshake) es el proceso de establecer una conexión segura entre dos Agentes de Transferencia de Correo (MTAs) que se comunican. Este proceso implica los siguientes pasos: 

• El MTA emisor de correo electrónico envía un mensaje "Client Hello" al MTA receptor. Este mensaje contiene parámetros útiles como versiones TLS y suites de cifrado. 
• El MTA que recibe el correo electrónico recibe este mensaje y responde con un mensaje "Server Hello". Éste contiene la versión TLS y el conjunto de cifrado seleccionados. 
• Una vez iniciado el protocolo TLS, el MTA receptor envía su certificado SSL/TLS, emitido por una CA (autoridad de certificación) de confianza. Este certificado contiene la clave pública.
• Los dos MTA que se comunican intercambian de forma segura sus claves criptográficas y establecen una conexión cifrada TLS. Esto garantiza una comunicación por correo electrónico segura entre ambas partes. 

2. Escenarios de TLS Handshake fallido 

TLS Handshakes puede fallar debido a una variedad de razones: 

• Errores de certificación: Los certificados caducados o emitidos por Autoridades de Certificación que no son de confianza pueden provocar fallos en el handshake TLS.
• Desajuste de versiones: Si hay un desajuste entre las versiones TLS soportadas por los MTAs emisor y receptor, puede provocar un fallo en el handshake.
• Fallos de STARTTLS: Si el comando STARTTLS no está correctamente implementado puede provocar de nuevo un fallo de encriptación TLS.
• Aplicación de MTA-STS: En caso de que el receptor del correo electrónico haya configurado su modo de política MTA-STS en "enforce", un handshake TLS fallido puede provocar el rechazo del mensaje.

3. Generación y entrega de informes

Siempre que se producen fallos de cifrado TLS, el servidor de envío genera un informe TLS-RPT y lo envía al propietario del dominio para su posterior evaluación y resolución de problemas. 

Contenido del informe

Detalles del servidor de envío: Dirección IP y nombre de dominio del remitente.

Detalles del servidor receptor: El dominio del destinatario y la información del servidor de correo electrónico.

Descripción del error: Tipo y detalles del fallo (por ejemplo, error de certificado, desajuste de protocolo).

Tiempo de fracaso: Hora en la que se produjo el problema.

Modo de política: Si el dominio está en modo "testing" o "enforce".

Entrega de informes

Estos informes TLS se envían en formato JSON a la dirección de correo electrónico especificada en el registro TLS-RPT DNS TXT del propietario del dominio. 

Función del cifrado oportunista en SMTP

SMTP utiliza tradicionalmente el cifrado oportunista. Esto significa que intenta utilizar TLS, pero vuelve a la entrega sin cifrar si el MTA receptor no admite TLS.

Sin embargo, el cifrado oportunista tiene una limitación importante. En este tipo de cifrado que no establece ningún mandato, los correos electrónicos pueden enviarse en texto plano o en texto claro (en un formato no cifrado) si falla el cifrado TLS. Estos mensajes sin cifrar son vulnerables a la interceptación.

Funcionamiento conjunto de MTA-STS y TLS-RPT

Mail Transfer Agent Strict Transport Security (MTA-STS) y TLS-RPT son protocolos complementarios en el ecosistema de autenticación del correo electrónico. Mientras que MTA-STS garantiza que el MTA remitente debe utilizar TLS para la entrega y rechazar los correos electrónicos si falla el cifrado,

TLS-RPT permite a los propietarios de dominios supervisar los handshakes TLS fallidos y solucionar problemas. Cuando se implementan conjuntamente, pueden evitar la interceptación de mensajes en tránsito y minimizar los problemas de entregabilidad del correo electrónico. 

Relación entre DANE y TLS-RPT

La Autenticación de Entidades Nombradas basada en DNS (DANE) es un protocolo que permite a los propietarios de dominios especificar certificados TLS verificados mediante DNSSEC para evitar ataques de intermediario. Mientras que TLS-RPT supervisa los fallos de TLS, DANE garantiza que sólo se utilicen certificados de confianza. De este modo, DANE impide activamente que los atacantes realicen ataques de downgrade de TLS y de suplantación de certificados, manteniendo así la integridad de las comunicaciones por correo electrónico. 

¿Por qué necesita informes SMTP TLS?

Los propietarios de dominios necesitan mantenerse informados sobre los problemas de entrega de correo electrónico debidos a fallos en el cifrado TLS de los correos electrónicos enviados desde un dominio habilitado para MTA-STS. Los informes TLS lo hacen posible proporcionando esta información. 

• Seguridad del correo electrónico: Destacar los riesgos de la comunicación por correo electrónico sin cifrar (por ejemplo, interceptación, ataques de intermediario).
• Conformidad: Mencione cómo TLS-RPT ayuda a las organizaciones a cumplir los requisitos normativos en materia de protección de datos.
• Entregabilidad: Explique cómo TLS-RPT mejora la entregabilidad del correo electrónico identificando y resolviendo los problemas de cifrado.

Pasos para configurar TLS-RPT

Puede activar los informes TLS para su dominio creando un registro TXT para TLS-RPT y publicándolo en su DNS. Este registro debe publicarse en el subdominio smtp.tls.sudominio.com

Paso 1: Generar un registro TLS-RPT (Utilizando un generador de registros TLS-RPT)

Puede inscribirse en PowerDMARC de forma gratuita y utilizar nuestro generador de registros TLS-RPT para crear su registro.

Paso 2: Introduzca su dirección de correo electrónico de notificación

Introduzca una dirección de correo electrónico en la que desee recibir sus informes SMTP TLS.

Paso 3: Publicar el registro TLS en su DNS

Puede ponerse en contacto con su registrador de dominios para crear un nuevo registro TXT para TLS-RPT. Si gestiona su propio DNS, edite su configuración DNS para incluir el registro.

Sintaxis y ejemplo de registro TLS-RPT

Sintaxis: v=TLSRPTv1; rua=mailto:[email protected];

Desglosemos los 2 componentes del registro de información TLS proporcionado:

1. v=TLSRPTv1: Esta etiqueta especifica la versión del protocolo TLS-RPT que se está utilizando. En este caso, "TLSRPTv1" indica la primera versión del protocolo.
2. rua=mailto:[email protected]: rua significa "Reporting URI(s) for Aggregate Data. Esta etiqueta especifica dónde debe enviar el servidor de correo del destinatario los informes TLS agregados.

Puede configurar más de un destino para recibir sus informes. Para varios destinos, separe cada entrada con una coma (,). Puede utilizar "mailto:" para especificar una dirección de correo electrónico para este paso, o bien indicar al MTA que envíe los informes mediante POST a URL de punto final utilizando "https:" en el campo rua=. Si utiliza "https:" asegúrese de que el campo define la URL a un servidor web habilitado para HTTPS con un certificado válido. Tanto "mailto:" como "https:" también pueden utilizarse en un único registro, separados por una coma. 

Ejemplo: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Nota: En la práctica, deberá sustituir "sudominio.com" por el nombre real del dominio en el que desea recibir estos informes.

Comprender los informes TLS-RPT JSON

Estructura de un informe TLS-RPT JSON

Los informes TLS se envían en formato JSON. A continuación se muestra un ejemplo de cómo podría ser un informe TLS JSON:

{

  "nombre-organización": "Organización Inc.",

  “date-range”: {

    "start-datetime": “2020-10-22T00:00:00Z”,

    "end-datetime": “2020-10-22T23:59:59Z”

  },

  "información de contacto": "[email protected]",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "políticas": [

    {

      “policy”: {

        "policy-type": "sts",

        "policy-string": [

          "version: STSv1",

          "mode: testing",

          "mx: mx.dominio.com",

          "mx: mx2.dominio.com",

          "mx: mx3.dominio.com",

          "max_age: 604800"

        ],

        "política-dominio": "dominio.es"

      },

      “summary”: {

        "total-successful-session-count": 15,

        "total-failure-session-count": 0

      }

Campos clave y su significado

He aquí el desglose de los principales campos de este informe JSON TLS:

Formato de informe TLS-RPT JSON e interpretación de datos

Metadatos del informe

{

  "nombre-organización": "Organización MTA remitente",

  “date-range”: {

    "start-datetime": “2025-02-25T00:00:00Z”,

    "end-datetime": “2025-02-25T23:59:59Z”

  },

  "report-id": “unique-report-id-12345”

}

Esta sección del informe JSON contiene información básica, como el nombre de la organización del remitente del correo electrónico, la fecha y hora de inicio, la fecha y hora de finalización y el ID exclusivo del informe TLS generado.

Detalles de la póliza

“policy”: {

  "policy-type": "sts",

  "policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

Esta sección describe el modo de política MTA-STS implementado, que en este caso es el modo Enforce, pero también puede configurarse en modo Testing. 

Detalles del fracaso

"failure-details": [

  {

    "tipo de resultado": "certificado caducado",

    "sending-mta": "smtp.ejemplo.org",

    "receiving-mta": "mail.ejemplo.com",

    "failure-reason": "TLS handshake failed due to expired certificate".

  }

]

Esta sección es la parte más crucial de su informe TLS, ya que detalla los motivos del cifrado y los posibles fallos de entrega. En este caso, el ejemplo indica que un certificado caducado es la causa del fallo del protocolo TLS. Esto juega un papel importante en la detección de errores durante los handshakes TLS fallidos y promueve una rápida resolución de problemas para comunicaciones TLS seguras. 

Razones y solución de problemas de los fallos de encriptación TLS

Puede haber varias razones para los fallos de encriptación TLS. Aparte de la falta de soporte para el cifrado en cualquiera de las partes, razones más siniestras como un ataque de degradación SMTP pueden provocar el fallo de la conexión TLS. Pero a los propietarios de dominios les gustaría saber sobre la entrega fallida. TLS reporting (TLS-RPT) es un protocolo que le notificará. En caso de fallo de entrega, recibirá el informe TLS en formato de archivo JSON en la dirección de correo electrónico definida en su registro TLS-RPT. A continuación se indican algunas razones comunes de los fallos de encriptación y consejos para solucionarlos:

1. Cuestiones relativas a los certificados

certificado_vencido

El certificado presentado por el servidor remoto ha superado su fecha de caducidad. Esto hace que no sea de confianza para el cifrado. En este caso, es necesario renovar el certificado.

certificado_no_válido_aún

El certificado presentado por el servidor remoto aún no es válido. Esto puede deberse a una hora incorrecta del servidor o a un uso prematuro del certificado. En este caso, lo mejor es que te pongas en contacto con tu proveedor de certificados.

certificado_revocado

El certificado presentado por el servidor remoto ha sido revocado por la autoridad de certificación debido a problemas de seguridad. En este caso, lo mejor es que te pongas en contacto con tu proveedor de certificados.

no_valid_signature

La cadena de certificados presentada por el servidor remoto no es de confianza para el servidor de correo o el cliente del remitente, lo que indica un riesgo potencial para la seguridad. En este caso, lo mejor es que te pongas en contacto con tu proveedor de certificados.

certificado_no_soportado

El certificado presentado por el servidor remoto utiliza algoritmos de cifrado o longitudes de clave no compatibles con el servidor de correo del remitente, lo que impide una conexión segura. En este caso, lo mejor es que te pongas en contacto con tu proveedor de certificados.

2. No coincidencia de nombre de host e identidad

nombre_de_anfitrión_incorrecto

El nombre de host especificado en el certificado del servidor no coincide con el nombre de host del servidor al que intenta conectarse el servidor de correo del remitente. Indica un posible ataque de intermediario o un problema de configuración.

Puede comprobar los registros MX en su archivo de políticas MTA-STS para asegurarse de que coinciden con el registro MX del dominio.

3. Cuestiones de protocolo y apretón de manos

fallo_apretón_de_manos

Se ha producido un problema durante el proceso inicial de enlace TLS entre el servidor de correo del remitente y el servidor de correo del destinatario, lo que ha impedido que se establezca el canal seguro. Vuelva a comprobar si se ha establecido la conexión SMTP STARTTLS. Puede haber varias razones que contribuyan a los fallos de encriptación, como la falta de soporte para STARTTLS, o un ataque de downgrade de TLS.

4. Cuestiones políticas de la MTA-STS

mta_sts_policy_not_found

Este fallo se produce cuando el servidor de correo del remitente no puede encontrar una política MTA-STS para el dominio del destinatario. Revise su archivo de política MTA-STS. Debe comprobar su registro MTA-STS para asegurarse de que se ha publicado correctamente.

mta_sts_policy_invalid

Este fallo se produce cuando la política MTA-STS encontrada en DNS para el dominio del destinatario no es válida, contiene errores o no cumple la especificación MTA-STS. Revise su archivo de política MTA-STS. Especifique un modo de política MTA-STS adecuado. Puede ser Ninguno, Aplicar o Probando. Esto indica a los servidores de envío cómo tratar los mensajes de correo electrónico que sufren fallos de validación de la política MTA-STS. 

mta_sts_policy_fetch_error

Este fallo se produce cuando el servidor de correo del remitente encuentra un error al intentar recuperar la política MTA-STS de los registros DNS del dominio del destinatario. Debe validar los registros MTA-STS en su DNS para asegurarse de que la sintaxis del registro es correcta.

mta_sts_connection_failure

Este fallo se produce cuando el servidor de correo del remitente intenta establecer una conexión segura mediante MTA-STS, pero falla por motivos como certificados no fiables, conjuntos de cifrado no compatibles u otros problemas de TLS. Debe comprobar la validez de su certificado y asegurarse de que está actualizado con el último estándar TLS.

mta_sts_invalid_hostname

Este fallo se produce cuando el nombre de host del servidor de correo del destinatario, especificado en la política MTA-STS, no coincide con el nombre de host real del servidor. Debe comprobar los registros MX del archivo de política MTA-STS para asegurarse de que coinciden con el registro MX del dominio.

Mejores prácticas para la implementación de TLS-RPT

Supervisar regularmente los informes TLS

Los informes TLS deben supervisarse regularmente para asegurarse de que no se pierden mensajes no entregados. Para ello, puede supervisar manualmente su buzón de correo en busca de informes JSON o utilizar una herramienta de análisis de informes como PowerTLS-RPT.

Asegúrese de que la política MTA-STS está correctamente configurada

Para garantizar una correcta implementación de TLS-RPT, su política MTA-STS debe estar configurada correctamente y sin errores de sintaxis. Puede comprobar su registro utilizando nuestro Comprobador MTA-STS para este paso.

Afronte sin demora los fallos de cifrado

Una vez detectados los fallos de cifrado indicados en el informe TLS, es importante actuar con rapidez para evitar problemas de entregabilidad del correo electrónico en el futuro. 

Utilizar versiones seguras del protocolo TLS

Utilizar únicamente las versiones más recientes y compatibles del protocolo TLS es esencial para evitar fallos de cifrado no deseados. 

Informes SMTP TLS simplificados con PowerDMARC

La experiencia de informes SMTP TLS de PowerDMARC consiste en mejorar su seguridad al tiempo que le facilita la vida con un servicio alojado.

Informes TLS traducidos

Sus complejos informes TLS-RPT JSON se convierten en información simplificada que puede hojear en segundos o leer en detalle. 

Problemas de autodetección

La plataforma PowerDMARC señala y destaca el problema al que se enfrenta para que pueda resolverlo sin perder tiempo.

No hay una sola cosa que me guste de la plataforma PowerDMARC, tienen un diseño fácil de usar y entender con lo que yo llamaría características completas que permiten el control DMARC alojado, aplanamiento SPFy ser capaz de expandir fácilmente el SPF incluye para inspeccionar los detalles del registro e incluso soporte completo para MTA-STS y TLS-RPT.

Dylan B (Empresario)

Preguntas frecuentes sobre la seguridad de la capa de transporte

1. ¿Qué significa TLS?

TLS son las siglas de Transport Layer Security. 

2. ¿Quién emite los certificados TLS? 

Las Autoridades de Certificación (CA) pueden emitir certificados TLS. El proceso de emisión del certificado incluye la verificación de la identidad del titular del certificado. Una vez identificados, se emite el certificado. 

3. ¿Por qué necesito un certificado TLS?

Los certificados TLS desempeñan un papel fundamental en la seguridad de las comunicaciones a través de Internet. Ayudan a cifrar información sensible intercambiada entre servidores web en comunicación. Algunos de sus usos más comunes son la seguridad de las comunicaciones por correo electrónico y HTTPS.

4. ¿Cuál es la norma TLS actual?

TLS 1.3 es la última versión de Transport Layer Security. TLS-RPT puede implementarse utilizando cualquier versión de TLS. Esto puede incluir versiones anteriores del protocolo o versiones futuras. La versión suele venir determinada por criterios como las capacidades de los servidores que se comunican. 

Recursos adicionales

1. Generador de registros TLS-RPT 
2. Verificador de registros TLS-RPT
3. MTA-STS 
4. DMARC

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico de PowerDMARC

Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.

Últimos mensajes de Yunes Tarada (ver todos)

• Certificado de marca verificada frente a certificado de marca común: elegir el más adecuado - 10 de marzo de 2026
• Nivel de confianza de spam (SCL) -1 Bypass: qué significa y cómo gestionarlo - 4 de marzo de 2026
• «No supera la verificación DMARC y tiene una política DMARC de rechazo»: qué significa y cómo solucionarlo - 26 de febrero de 2026