Analizar y aprovechar tus informes TLS-RPT: detectar problemas antes de que afecten a tus emails

Por CaptainDNS
Publicado el 14 de febrero de 2026

Analizar un informe TLS-RPT: estructura JSON y tipos de errores TLS en email

TL;DR

Un informe TLS-RPT es un archivo JSON comprimido (gzip) enviado diariamente por los servidores emisores: detalla cada fallo de negociación TLS en tu dominio
Los 3 errores más frecuentes son certificate-host-mismatch, starttls-not-supported y sts-policy-fetch-error, cada uno con una causa y una corrección específica
Analiza el campo failure-details para identificar el servidor MX afectado, la IP del remitente y el tipo exacto del fallo
Utiliza el validador de sintaxis TLS-RPT para verificar tu configuración antes y después de la corrección

Has configurado TLS-RPT en tu dominio y los informes empiezan a llegar. Archivos JSON comprimidos, enviados por Google, Microsoft, Yahoo y otros proveedores. Los abres y encuentras bloques de datos estructurados con campos como policy-type, result-type, failed-session-count. ¿Qué significan estos datos? ¿Cómo transformarlos en acciones concretas?

Esta es la parte menos documentada de TLS-RPT. La RFC 8460 define el formato, pero no te dice cómo interpretar los resultados en un contexto operativo. Esta guía llena ese vacío: aprenderás a leer la estructura JSON de un informe, a identificar cada tipo de error y a seguir un workflow de diagnóstico para corregir los problemas antes de que afecten a la entrega de tus emails.

Si todavía no has configurado TLS-RPT, empieza por la guía completa TLS-RPT que cubre la configuración de la A a la Z (consulta la sección Guías relacionadas al final del artículo). Si buscas la configuración específica para tu proveedor (Microsoft 365, Google Workspace, OVHcloud), la guía de configuración por proveedor también está disponible al final del artículo.

Anatomía de un informe TLS-RPT

Un informe TLS-RPT es un archivo JSON enviado como adjunto comprimido (.json.gz). Cada proveedor que te envía emails genera su propio informe, una vez al día. Esta es la estructura completa de un informe típico:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-12T00: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",
        "mx-host": ["mail.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.captaindns.com",
          "receiving-ip": "203.0.113.10",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Los 4 bloques del informe

Cada informe contiene exactamente 4 niveles de información:

1. Encabezado del informe: quién lo envía y cuándo:

organization-name: el proveedor emisor (Google, Microsoft, Yahoo)
date-range: el periodo cubierto (siempre 24 horas)
report-id: identificador único del informe

2. Bloque policy: qué política TLS fue evaluada:

policy-type: el tipo de política (sts para MTA-STS, tlsa para DANE, no-policy-found si no hay ninguna)
policy-string: el contenido de la política MTA-STS o DANE aplicada
policy-domain: tu dominio
mx-host: los servidores MX afectados

3. Bloque summary: el balance numérico:

total-successful-session-count: conexiones TLS exitosas
total-failure-session-count: conexiones TLS fallidas

4. Bloque failure-details: el detalle de cada fallo (el más importante):

result-type: el tipo exacto del error
sending-mta-ip: la IP del servidor que intentó enviarte el email
receiving-mx-hostname: tu servidor MX afectado
receiving-ip: la IP de tu servidor MX
failed-session-count: número de fallos de este tipo

Anatomía de un informe TLS-RPT: los 4 bloques de datos JSON (encabezado, política, balance, detalles de fallos)

¿Cómo recibir y descomprimir los informes?

Los informes llegan por email desde direcciones como noreply-smtp-tls-reporting@google.com. El archivo adjunto tiene un nombre con el formato:

google.com!captaindns.com!2026-02-12T00:00:00Z!2026-02-13T00:00:00Z.json.gz

Para descomprimirlo:

# Linux / macOS
gunzip google.com\!captaindns.com\!2026-02-12T00:00:00Z\!2026-02-13T00:00:00Z.json.gz

# O visualizar directamente sin extraer
zcat rapport.json.gz | python3 -m json.tool

Si recibes los informes por HTTPS (endpoint https://), el servidor recibe directamente el JSON comprimido en POST con el Content-Type application/tlsrpt+gzip.

Los tipos de fallos TLS-RPT (result-type)

El campo result-type en failure-details identifica con precisión lo que ha fallado. La RFC 8460 define 11 tipos de fallos, divididos en 3 categorías:

Fallos relacionados con el certificado TLS

result-type	Causa	Acción correctiva
`certificate-host-mismatch`	El certificado TLS del servidor MX no corresponde al hostname	Renueva el certificado con el CN/SAN correcto para tu MX
`certificate-expired`	El certificado TLS ha expirado	Renueva inmediatamente el certificado
`certificate-not-trusted`	El certificado no está firmado por una CA reconocida	Usa un certificado firmado por una CA pública (Let's Encrypt, DigiCert)

Fallos relacionados con STARTTLS

result-type	Causa	Acción correctiva
`starttls-not-supported`	El servidor MX no ofrece STARTTLS	Activa STARTTLS en la configuración de tu servidor de correo
`validation-failure`	Fallo genérico de validación TLS	Verifica la cadena de certificados completa y la configuración TLS

Fallos relacionados con las políticas MTA-STS y DANE

result-type	Causa	Acción correctiva
`sts-policy-fetch-error`	Imposible recuperar la política MTA-STS	Verifica que `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` sea accesible
`sts-policy-invalid`	La política MTA-STS tiene un formato incorrecto	Corrige la sintaxis del archivo `mta-sts.txt`
`sts-webpki-invalid`	El certificado HTTPS del servidor MTA-STS es inválido	Renueva el certificado del subdominio `mta-sts.captaindns.com`
`tlsa-invalid`	El registro DANE TLSA es inválido	Corrige el registro TLSA en tu zona DNS
`dnssec-invalid`	La validación DNSSEC ha fallado	Corrige tu cadena DNSSEC
`dane-required`	DANE es obligatorio pero el servidor no lo soporta	Despliega DANE o elimina los registros TLSA

Los 3 errores más frecuentes en detalle

certificate-host-mismatch

Es el error más común. Aparece cuando el certificado TLS presentado por tu servidor MX no contiene el hostname esperado en su campo CN (Common Name) o SAN (Subject Alternative Name).

Escenario típico: tu MX es mail.captaindns.com pero el certificado está emitido para *.otrodominio.com (alojamiento compartido) o para captaindns.com sin el subdominio mail.

Diagnóstico:

# Verificar el certificado de tu MX
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -servername mail.captaindns.com 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Corrección: obtén un certificado que incluya el FQDN exacto de tu MX en el SAN. Con Let's Encrypt:

certbot certonly --standalone -d mail.captaindns.com

starttls-not-supported

El servidor MX no ofrece el comando STARTTLS en su banner SMTP. Los emails se transmiten en texto plano.

Diagnóstico:

# Comprobar si STARTTLS está anunciado
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>&1 | head -5
# Si aparece "CONNECTED", STARTTLS funciona
# Si hay error, STARTTLS no está soportado

Corrección: activa STARTTLS en tu servidor de correo. Para Postfix:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

sts-policy-fetch-error

El servidor emisor no pudo recuperar tu política MTA-STS en la URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Causas frecuentes:

El subdominio mta-sts.captaindns.com no tiene registro DNS A/AAAA
El servidor HTTPS no responde o devuelve un error 404/500
El certificado HTTPS del subdominio mta-sts ha expirado

Diagnóstico:

# Comprobar el acceso a la política
curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Para un diagnóstico completo de tus problemas MTA-STS, consulta nuestra guía de troubleshooting MTA-STS.

Diagnóstico paso a paso: del error a la corrección

Cuando recibes un informe con fallos, sigue este workflow en 5 pasos:

Paso 1: Identifica la gravedad

Observa la ratio fallos/éxitos en el bloque summary:

total-successful-session-count: 1842
total-failure-session-count: 3

Una ratio inferior al 1 % de fallos es normal: puede tratarse de intentos desde servidores mal configurados del lado del remitente. Por encima del 5 %, hay un problema que investigar.

Paso 2: Identifica el result-type

El campo result-type en failure-details te indica exactamente qué ha fallado. Consulta la tabla de los 11 tipos anterior.

Paso 3: Identifica el servidor MX afectado

El campo receiving-mx-hostname te indica qué servidor está impactado. Si tienes varios MX (primario + backup), solo uno puede estar mal configurado.

Paso 4: Verifica con las herramientas CaptainDNS

Utiliza el verificador TLS-RPT de CaptainDNS para confirmar que tu registro DNS es correcto y que las políticas asociadas (MTA-STS, DANE) se detectan correctamente.

Paso 5: Corrige y monitoriza

Aplica la corrección correspondiente al result-type y después monitoriza los informes de las siguientes 48 a 72 horas para confirmar que el error desaparece.

Workflow de diagnóstico TLS-RPT: de la recepción del informe a la corrección del error

Casos prácticos: analizar un informe real

Caso 1: informe limpio (sin fallos)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "report-id": "2026-02-12_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 2156,
        "total-failure-session-count": 0
      },
      "failure-details": []
    }
  ]
}

Interpretación: 2 156 conexiones TLS exitosas, cero fallos. Tu configuración funciona perfectamente. Este informe confirma que:

Tu certificado TLS es válido y corresponde al hostname MX
STARTTLS está activo en tu servidor
Tu política MTA-STS es accesible y se respeta

Caso 2: fallo de certificado en un MX secundario

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com", "mail2.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 890,
        "total-failure-session-count": 47
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "40.107.22.89",
          "receiving-mx-hostname": "mail2.captaindns.com",
          "receiving-ip": "198.51.100.20",
          "failed-session-count": 47
        }
      ]
    }
  ]
}

Interpretación: 47 fallos en mail2.captaindns.com (MX secundario) con un error certificate-host-mismatch. El MX primario (mail.captaindns.com) funciona correctamente. El certificado del MX secundario no contiene mail2.captaindns.com en su SAN.

Acción: renueva el certificado de mail2.captaindns.com incluyendo este hostname en el SAN.

Caso 3: política MTA-STS inaccesible

{
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 156
      },
      "failure-details": [
        {
          "result-type": "sts-policy-fetch-error",
          "failed-session-count": 156
        }
      ]
    }
  ]
}

Interpretación: 156 fallos, todos del tipo sts-policy-fetch-error. El servidor emisor detectó tu registro MTA-STS (_mta-sts.captaindns.com) pero no pudo descargar la política en https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Acción: verifica que el subdominio mta-sts.captaindns.com apunte a un servidor HTTPS funcional con un certificado válido.

Automatizar el análisis de tus informes

Volumen bajo: buzón dedicado

Para un dominio que recibe menos de 1 000 emails al día, una dirección dedicada es suficiente:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Crea un filtro en tu cliente de correo para clasificar los informes automáticamente. Consúltalos una vez por semana buscando total-failure-session-count superiores a cero.

Volumen alto: endpoint HTTPS

Para dominios con mucho tráfico, configura un endpoint HTTPS que reciba los informes en POST:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://reports.captaindns.com/tls-rpt"

El endpoint recibe el JSON comprimido en gzip con el Content-Type application/tlsrpt+gzip. Puedes parsear los informes automáticamente y disparar alertas cuando total-failure-session-count supere un umbral.

Verificar tu configuración con CaptainDNS

Antes de modificar tu configuración TLS o MTA-STS, utiliza el generador TLS-RPT para crear un registro correcto. Después de la corrección, verifica con el verificador TLS-RPT que todo esté en orden.

Plan de acción recomendado

Descomprime y lee tu primer informe: abre un archivo .json.gz recibido de Google o Microsoft e identifica los 4 bloques (encabezado, policy, summary, failure-details)
Verifica la ratio fallos/éxitos: una tasa de fallos superior al 5 % requiere investigación
Identifica el result-type: utiliza la tabla de los 11 tipos de fallos para entender la causa exacta
Corrige el problema en el servidor afectado: certificado, STARTTLS o política MTA-STS según el tipo de error
Monitoriza los informes siguientes: confirma la desaparición del error en las 48 a 72 horas posteriores a la corrección

FAQ

¿Qué es un informe TLS-RPT y qué contiene?

Un informe TLS-RPT es un archivo JSON comprimido (gzip) enviado diariamente por los servidores de correo que te envían emails. Contiene el nombre de la organización emisora, el periodo cubierto (24 horas), la política TLS evaluada (MTA-STS o DANE), el número de conexiones TLS exitosas y fallidas, y el detalle de cada tipo de fallo con las IP y hostnames afectados.

¿Cómo leer la estructura JSON de un informe TLS-RPT?

El informe JSON tiene 4 niveles: el encabezado (organization-name, date-range), el bloque policy (policy-type, policy-string), el bloque summary (contadores de éxitos/fallos) y el bloque failure-details (result-type, sending-mta-ip, receiving-mx-hostname). Descomprime el archivo .json.gz con gunzip o zcat, y formatea con python3 -m json.tool para una lectura legible.

¿Cuáles son los tipos de errores (result-type) en un informe TLS-RPT?

La RFC 8460 define 11 tipos de fallos repartidos en 3 categorías: errores de certificado (certificate-host-mismatch, certificate-expired, certificate-not-trusted), errores STARTTLS (starttls-not-supported, validation-failure) y errores de política (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required). Cada tipo indica con precisión qué ha fallado durante la negociación TLS.

¿Qué significa certificate-host-mismatch en un informe TLS-RPT?

El error certificate-host-mismatch significa que el certificado TLS presentado por tu servidor MX no corresponde al hostname esperado. Por ejemplo, si tu MX es mail.captaindns.com pero el certificado está emitido para otro dominio. Corrígelo obteniendo un certificado cuyo SAN (Subject Alternative Name) incluya el FQDN exacto de tu MX.

¿Cómo corregir un error starttls-not-supported?

El error starttls-not-supported significa que tu servidor MX no anuncia el comando STARTTLS, por lo que los emails se transmiten en texto plano. Activa STARTTLS en la configuración de tu servidor: para Postfix, añade smtpd_tls_security_level = may con las rutas hacia tu certificado y clave privada en main.cf. Después verifica con openssl s_client -connect mail.captaindns.com:25 -starttls smtp.

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

Los informes TLS-RPT se envían una vez al día (periodo de 24 horas). Cada proveedor que te envía emails (Google, Microsoft, Yahoo, etc.) genera su propio informe de forma independiente. Por lo tanto, puedes recibir varios informes al día, uno por proveedor emisor. Los primeros informes llegan entre 24 y 48 horas después de publicar tu registro TLS-RPT.

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

Los informes DMARC monitorizan la autenticación de los emails (SPF, DKIM, alineación del dominio), mientras que los informes TLS-RPT monitorizan el cifrado del transporte (negociación TLS entre servidores). DMARC verifica quién envía el email, TLS-RPT verifica cómo se transporta. Los informes DMARC están en formato XML, los informes TLS-RPT en formato JSON. Ambos son complementarios para proteger tu dominio.

Glosario

TLS-RPT: SMTP TLS Reporting (RFC 8460), mecanismo de informes diarios sobre fallos de negociación TLS durante la entrega de emails.
result-type: campo JSON en failure-details que identifica el tipo exacto de fallo TLS (certificate-host-mismatch, starttls-not-supported, etc.).
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 utiliza DNSSEC y los registros TLSA.
STARTTLS: extensión SMTP que permite cifrar una conexión inicialmente en texto plano. Oportunista por defecto.
SAN: Subject Alternative Name, campo del certificado TLS que lista los hostnames válidos.
policy-type: campo JSON que indica el tipo de política evaluada (sts, tlsa o no-policy-found).

Verifica tu configuración ahora: Utiliza nuestro verificador TLS-RPT para comprobar que tu registro _smtp._tls es correcto y que las políticas asociadas se detectan correctamente.

Analizar y aprovechar tus informes TLS-RPT: detectar problemas antes de que afecten a tus emails

Anatomía de un informe TLS-RPT

Los 4 bloques del informe

¿Cómo recibir y descomprimir los informes?

Los tipos de fallos TLS-RPT (result-type)

Fallos relacionados con el certificado TLS

Fallos relacionados con STARTTLS

Fallos relacionados con las políticas MTA-STS y DANE

Los 3 errores más frecuentes en detalle

certificate-host-mismatch

starttls-not-supported

sts-policy-fetch-error

Diagnóstico paso a paso: del error a la corrección

Casos prácticos: analizar un informe real

Caso 1: informe limpio (sin fallos)

Caso 2: fallo de certificado en un MX secundario

Caso 3: política MTA-STS inaccesible

Automatizar el análisis de tus informes

Volumen bajo: buzón dedicado

Volumen alto: endpoint HTTPS

Verificar tu configuración con CaptainDNS

Plan de acción recomendado

FAQ

¿Qué es un informe TLS-RPT y qué contiene?

¿Cómo leer la estructura JSON de un informe TLS-RPT?

¿Cuáles son los tipos de errores (result-type) en un informe TLS-RPT?

¿Qué significa certificate-host-mismatch en un informe TLS-RPT?

¿Cómo corregir un error starttls-not-supported?

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

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

Glosario

Guías de TLS-RPT relacionadas

Fuentes

Artículos relacionados

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

¿MTA-STS no funciona? Guía completa de resolución de problemas

Configurar TLS-RPT: guía paso a paso para Microsoft 365, Google Workspace y OVHcloud