TLS-RPT: la guía completa para monitorizar la seguridad TLS de tus emails

⚡TL;DR

• TLS-RPT (RFC 8460) te envía un informe diario sobre cada fallo de cifrado TLS detectado por los servidores que te envían emails
• Sin TLS-RPT, no sabes si tus emails llegan en texto plano por un certificado caducado, un MX mal configurado o un ataque de downgrade
• Solo necesitas publicar un registro DNS TXT: _smtp._tls.captaindns.com con la directiva v=TLSRPTv1; rua=mailto:...
• TLS-RPT es el compañero indispensable de MTA-STS: te da la visibilidad necesaria antes de pasar al modo enforce

¿Tu dominio usa MTA-STS o estás pensando en activarlo? ¿Has configurado STARTTLS en tus servidores de correo? En ambos casos, queda una pregunta sin respuesta: ¿cómo saber si el cifrado TLS funciona realmente durante la entrega de tus emails?

Es exactamente el problema que resuelve TLS-RPT. Definido en la RFC 8460, SMTP TLS Reporting es un mecanismo que permite a los servidores emisores (Gmail, Microsoft, Yahoo y todos los proveedores que lo soportan) enviarte informes detallados sobre los fallos de negociación TLS que encuentran al intentar entregar emails a tu dominio.

Esta guía te explica qué es TLS-RPT, cómo funciona, cómo configurarlo en unos minutos y cómo interpretar los informes que recibirás. Tanto si eres administrador de sistemas, DevOps o responsable de la infraestructura de email, aquí encontrarás todo lo necesario para desplegar TLS-RPT en tu dominio.

¿Qué es TLS-RPT?

TLS-RPT, acrónimo de SMTP TLS Reporting, es un estándar de internet (RFC 8460) publicado en septiembre de 2018. Su función es simple: permitir al propietario de un dominio recibir informes sobre los intentos de conexión TLS que fallan cuando otros servidores intentan entregarle emails.

En la práctica, cuando Gmail intenta enviar un email a contact@captaindns.com, verifica si el servidor de recepción soporta TLS y si la negociación TLS tiene éxito. Si algo falla (certificado caducado, STARTTLS no soportado, política MTA-STS no respetada), Gmail registra ese fallo. Una vez al día, agrega todos los fallos y envía un informe JSON a la dirección especificada en tu registro TLS-RPT.

¿Por qué TLS-RPT es indispensable?

Sin TLS-RPT, estás a ciegas respecto a la calidad del cifrado de tus emails entrantes:

• Un certificado TLS caduca en tu servidor MX → los emails siguen llegando (en texto plano si MTA-STS no está en modo enforce), pero no lo sabes
• Un MX secundario no soporta STARTTLS → los emails hacia ese MX transitan sin cifrado
• Un ataque man-in-the-middle fuerza un downgrade → imposible de detectar sin informes

TLS-RPT cubre esa laguna. Recibes cada día un balance preciso: cuántas conexiones TLS tuvieron éxito, cuántas fallaron y por qué fallaron.

¿Qué diferencia hay entre TLS-RPT y los informes DMARC?

Los informes DMARC (RUA/RUF) y los informes TLS-RPT cubren ámbitos diferentes:

Criterio	Informes DMARC	TLS-RPT
Qué monitoriza	La autenticación de los emails (SPF, DKIM, alineación)	El cifrado del transporte (TLS)
RFC	RFC 7489	RFC 8460
Registro DNS	_dmarc.dominio	_smtp._tls.dominio
Formato del informe	XML (agregado) o texto (forense)	JSON
Frecuencia	Configurable (normalmente 24 h)	Siempre 24 h
Protocolo	Autenticación del remitente	Seguridad del canal de transporte

Ambos son complementarios: DMARC verifica quién envía el email, TLS-RPT verifica cómo se transporta. Un dominio seguro necesita los dos.

¿Cómo funciona TLS-RPT?

El mecanismo TLS-RPT se integra en el flujo normal de entrega de email:

1. Publicación del registro DNS

Publicas un registro TXT en _smtp._tls.captaindns.com que contiene la dirección donde recibir los informes.

2. Detección por el servidor emisor

Cuando Gmail (o cualquier otro servidor compatible) quiere enviar un email a tu dominio, realiza una consulta DNS a _smtp._tls.captaindns.com para comprobar si has configurado TLS-RPT.

3. Recopilación de los resultados TLS

En cada intento de entrega, el servidor emisor registra el resultado de la negociación TLS: éxito o fallo, con el tipo de error en su caso.

4. Agregación y envío del informe

Cada 24 horas, el servidor emisor agrega los resultados y envía un informe JSON a la dirección rua especificada en tu registro TLS-RPT.

¿Quién envía los informes?

Los principales proveedores que envían informes TLS-RPT:

Proveedor	Dirección de envío	Soportado
Google / Gmail	noreply-smtp-tls-reporting@google.com	Sí
Microsoft / Outlook	tlsrpt@microsoft.com	Sí
Yahoo / AOL	Variable	Sí
LinkedIn	Variable	Sí
Comcast	Variable	Sí

Si recibes un email de noreply-smtp-tls-reporting@google.com, no te preocupes: es un informe TLS-RPT legítimo enviado por Google. Contiene un archivo JSON comprimido (gzip) con el detalle de los resultados TLS de las últimas 24 horas.

La sintaxis del registro TLS-RPT

El registro TLS-RPT es un registro DNS TXT publicado en _smtp._tls.<dominio>.

Formato básico

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Tag	Obligatorio	Descripción
v	Sí	Versión del protocolo, siempre TLSRPTv1
rua	Sí	URI(s) de destino de los informes (mailto: o https:)

Ejemplos de configuraciones válidas

Informes por email (lo más habitual):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Informes por endpoint HTTPS:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://report.captaindns.com/tlsrpt"

Informes múltiples (email + HTTPS):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt"

Informes hacia un dominio externo

Cuando envías los informes a un dominio distinto al tuyo (por ejemplo, un servicio de monitorización de terceros), el dominio destinatario debe publicar un registro de autorización:

captaindns.com._report._tls.monitoring-tiers.com. TXT "v=TLSRPTv1"

Este mecanismo impide que un atacante redirija los informes hacia un dominio no autorizado. Verifica siempre que el dominio externo ha publicado este registro de autorización.

Consejos de configuración

• Buzón dedicado: usa una dirección de email dedicada (p. ej.: tlsrpt@captaindns.com) para no mezclar los informes con tu bandeja principal
• TTL razonable: un TTL de 300 a 3.600 segundos es adecuado para este registro
• HTTPS para alto volumen: si recibes muchos emails, un endpoint HTTPS es más adecuado que un buzón de correo para procesar los informes

Entender el informe JSON de TLS-RPT

Los informes TLS-RPT se envían en formato JSON, comprimidos en gzip. Esta es la estructura de un informe tipo:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-09T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-08T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 4523,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.1",
          "receiving-mx-hostname": "mail.captaindns.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Desglose del informe

Campo	Significado
organization-name	Quién envía el informe (Google, Microsoft, etc.)
date-range	Período cubierto (siempre 24 h)
policy-type	Tipo de política aplicada: sts (MTA-STS), tlsa (DANE) o no-policy-found
total-successful-session-count	Número de conexiones TLS exitosas
total-failure-session-count	Número de conexiones TLS fallidas
failure-details	Detalle de cada tipo de fallo

Los tipos de fallos TLS

Cada fallo se categoriza con un result-type. Estos son los principales:

Código	Descripción	Gravedad	Acción
starttls-not-supported	El servidor MX no soporta STARTTLS	Crítica	Activar STARTTLS en el servidor
certificate-expired	El certificado TLS del servidor ha caducado	Crítica	Renovar el certificado de inmediato
certificate-host-mismatch	El certificado no coincide con el hostname del MX	Crítica	Corregir el certificado o el hostname
certificate-not-trusted	Certificado no firmado por una CA de confianza	Alta	Usar un certificado de una CA reconocida
validation-failure	Fallo de validación TLS genérico	Alta	Verificar la configuración TLS completa
sts-policy-fetch-error	No se puede obtener la política MTA-STS	Media	Verificar el archivo mta-sts.txt
sts-policy-invalid	La política MTA-STS no es válida	Media	Corregir la sintaxis de la política
sts-webpki-invalid	El certificado HTTPS del servidor de la política no es válido	Media	Renovar el certificado del subdominio mta-sts
tlsa-invalid	Registro TLSA no válido (DANE)	Media	Corregir los registros TLSA
dnssec-invalid	Validación DNSSEC fallida	Alta	Verificar la configuración DNSSEC

TLS-RPT y MTA-STS: el dúo indispensable

TLS-RPT cobra todo su sentido cuando se combina con MTA-STS. Te explicamos por qué:

El flujo de trabajo recomendado

1. Configurar TLS-RPT: publica tu registro _smtp._tls para empezar a recibir informes
2. Activar MTA-STS en modo testing: publica tu política MTA-STS con mode: testing
3. Analizar los informes: durante 1 a 2 semanas, los informes TLS-RPT te muestran si hay conexiones TLS que fallan
4. Corregir los problemas: certificados caducados, MX no cubiertos, configuraciones TLS incorrectas
5. Pasar al modo enforce: una vez que los informes confirmen cero fallos, cambia MTA-STS a mode: enforce

Sin TLS-RPT, pasar al modo enforce es como navegar a ciegas: corres el riesgo de rechazar emails legítimos sin saberlo.

TLS-RPT también funciona con DANE

TLS-RPT no se limita a MTA-STS. También reporta los fallos relacionados con los registros DANE TLSA (RFC 7672). Si tu dominio usa DNSSEC y publica registros TLSA, los informes TLS-RPT incluirán los resultados de validación DANE con el policy-type: tlsa.

Configurar TLS-RPT en 5 minutos

Paso 1: Elegir la dirección de informes

Crea una dirección de email dedicada para recibir los informes:

• tlsrpt@captaindns.com (recomendado)
• O usa un endpoint HTTPS si tienes un sistema de procesamiento automatizado

Paso 2: Generar el registro DNS

Usa nuestro generador TLS-RPT para crear el registro adaptado a tu dominio. Obtendrás un registro listo para copiar.

Paso 3: Publicar el registro DNS

Añade el registro TXT en tu zona DNS:

Campo	Valor
Host	_smtp._tls
Tipo	TXT
Valor	v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com
TTL	3600

Paso 4: Verificar la configuración

Usa nuestro validador de sintaxis TLS-RPT para comprobar que tu registro está correctamente formateado.

Paso 5: Esperar los primeros informes

Los informes llegan normalmente entre 24 y 48 horas después de publicar el registro. Google suele ser el primero en enviar informes.

Errores comunes y resolución de problemas

No recibes informes pasadas 48 horas

• Verifica que el registro está publicado en _smtp._tls.captaindns.com (no en _smtp-tls ni smtp._tls)
• Comprueba la sintaxis: v=TLSRPTv1 (no v=TLSRPTv2 ni v=TLSRPT1)
• Asegúrate de que el buzón de recepción existe y acepta archivos adjuntos gzip
• Verifica que tu dominio recibe suficientes emails para generar informes

Los informes llegan pero están vacíos

Si total-failure-session-count siempre es 0, es una buena noticia: tu configuración TLS funciona correctamente. Los informes confirman que todas las conexiones TLS tienen éxito.

Emails de noreply-smtp-tls-reporting@google.com

Esos emails son legítimos. Google envía un informe TLS-RPT diario para cada dominio que ha publicado un registro _smtp._tls. El archivo adjunto (.json.gz) contiene el informe. No marques estos emails como spam.

Plan de acción recomendado

1. Publica tu registro TLS-RPT: 5 minutos con el generador TLS-RPT (ver paso 2 más arriba)
2. Configura MTA-STS en modo testing: activa la política MTA-STS para que los informes TLS-RPT incluyan los resultados de validación
3. Analiza los informes durante 2 semanas: identifica los fallos TLS y corrígelos
4. Pasa MTA-STS al modo enforce: una vez que los informes estén limpios, activa el rechazo de conexiones TLS fallidas
5. Monitoriza de forma continua: los informes diarios te alertan de cualquier nuevo problema (certificado caducado, cambio de MX, etc.)

FAQ

¿Qué es TLS-RPT y para qué sirve?

TLS-RPT (SMTP TLS Reporting, RFC 8460) es un mecanismo que permite al propietario de un dominio recibir informes diarios sobre los fallos de negociación TLS durante la entrega de emails. Te da visibilidad completa sobre la calidad del cifrado de tus emails entrantes.

¿Cómo se configura un registro TLS-RPT?

Publica un registro DNS TXT en _smtp._tls.captaindns.com con el valor v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Usa un generador TLS-RPT para crear el registro y luego añádelo a tu zona DNS. Los primeros informes llegan en 24 a 48 horas.

¿Por qué recibo emails de noreply-smtp-tls-reporting@google.com?

Esos emails son informes TLS-RPT legítimos enviados por Google. Tu dominio tiene un registro _smtp._tls configurado, y Google te envía diariamente un informe JSON comprimido con los resultados de negociación TLS de los emails que te ha enviado.

¿Cuál es la diferencia entre TLS-RPT y los informes DMARC?

DMARC monitoriza la autenticación de los emails (SPF, DKIM, alineación), mientras que TLS-RPT monitoriza el cifrado del transporte (TLS). DMARC verifica quién envía el email, TLS-RPT verifica cómo se transporta. Ambos son complementarios y se recomienda usarlos juntos.

¿Es obligatorio TLS-RPT si uso MTA-STS?

No, TLS-RPT no es técnicamente obligatorio para MTA-STS. Pero se recomienda encarecidamente: sin TLS-RPT, no sabrás si hay conexiones TLS que fallan. Es especialmente crítico antes de pasar MTA-STS al modo enforce, ya que los informes te permiten identificar y corregir los problemas previamente.

¿Con qué frecuencia se envían los informes TLS-RPT?

Los informes TLS-RPT se envían una vez al día (período de 24 horas). Cada proveedor compatible (Google, Microsoft, Yahoo, etc.) envía su propio informe de forma independiente. Por lo tanto, puedes recibir varios informes al día, uno por proveedor.

¿Cómo se lee un informe TLS-RPT en JSON?

Un informe TLS-RPT es un archivo JSON comprimido en gzip. Contiene la organización emisora, el período cubierto y, para cada política TLS (MTA-STS o DANE): el número de sesiones exitosas, el número de fallos y el detalle de cada tipo de fallo (certificado caducado, STARTTLS no soportado, etc.).

¿Se pueden usar mailto: y https: a la vez en TLS-RPT?

Sí, puedes especificar varias URIs de informes separadas por comas. Por ejemplo: rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. El endpoint HTTPS es recomendable para dominios con alto volumen de emails.

Glosario

• TLS-RPT: SMTP TLS Reporting, mecanismo de informes sobre fallos TLS definido en la RFC 8460.
• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461), política que impone el cifrado TLS para la recepción de emails.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672), mecanismo alternativo a MTA-STS que usa DNSSEC y los registros TLSA para validar los certificados TLS.
• STARTTLS: extensión SMTP que permite cifrar una conexión inicialmente en texto plano. Oportunista por defecto (no rechaza si el cifrado falla).
• Ataque de downgrade: ataque en el que un intermediario fuerza la conexión a permanecer en texto plano eliminando el comando STARTTLS de la respuesta del servidor.
• RUA: Reporting URI for Aggregated reports, la dirección donde se envían los informes TLS-RPT.

---

Verifica tu configuración ahora: usa nuestro verificador TLS-RPT para analizar el registro _smtp._tls de tu dominio en unos segundos.

---

Guías de TLS-RPT relacionadas

• Configurar TLS-RPT para Microsoft 365, Google Workspace y OVHcloud (próximamente)
• Analizar y aprovechar tus informes TLS-RPT (próximamente)

Fuentes

• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• Google SMTP TLS Reporting documentation