TLS-RPT en detalle: reportes de fallos de cifrado y debugging de MTA-STS

Cómo activar TLS-RPT, qué contienen los reportes JSON diarios y cómo diagnosticar fallos comunes de TLS, MTA-STS y certificados en tu MX.

Activar MTA-STS sin TLS-RPT es como poner una cerradura sin alarma: si alguien fuerza la puerta o si la cerradura se rompe, no te enteras. TLS-RPT (RFC 8460) es el complemento que pide a los receptores que envíen reportes diarios sobre los fallos de TLS hacia tu dominio. Sin esos reportes, no puedes saber si tu política está bloqueando entrega legítima por errores de configuración.

Qué reporta TLS-RPT

TLS-RPT solicita reportes en formato JSON con:

• Sesiones SMTP fallidas con TLS hacia tu MX, agrupadas por tipo de fallo.
• Sesiones que no se cifraron cuando tu política decía enforce.
• Detalles del receptor (IP, hostname) y del MX afectado.
• Causa concreta: certificado expirado, hostname mismatch, downgrade detectado, política inalcanzable, etc.

Los reportes son agregados por jornada UTC y se envían por email a la dirección que tú indiques o por HTTPS POST a una URL.

Activar TLS-RPT

Es un único registro TXT:

_smtp._tls.tudominio.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Verificar:

dig +short TXT _smtp._tls.tudominio.com

Devuelve:

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

Opciones de rua:

• mailto:direccion@dominio (lo más común).
• https://endpoint.tudominio.com/tls-reports.
• Múltiples destinos separados por coma: mailto:[email protected],mailto:[email protected].

Si el destino es un email, el JSON viene como adjunto .gz o .json.gz en mensajes con Content-Type: application/tlsrpt+gzip.

Estructura de un reporte

Un reporte tiene esta forma:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-09T00:00:00Z",
    "end-datetime": "2026-05-10T00:00:00Z"
  },
  "contact-info": "[email protected]",
  "report-id": "abc-123-tudominio.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: enforce", "mx: mx.tudominio.com", "max_age: 604800"],
        "policy-domain": "tudominio.com",
        "mx-host": ["mx.tudominio.com"]
      },
      "summary": {
        "total-successful-session-count": 8421,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "74.125.24.27",
          "receiving-mx-hostname": "mx.tudominio.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Los datos clave:

• total-successful-session-count: sesiones cifradas correctamente bajo política.
• total-failure-session-count: sesiones fallidas.
• failure-details: lista por tipo de fallo.

Tipos de fallo y qué significan

certificate-expired

Tu certificado TLS del MX caducó. Renueva ya. Los receptores con MTA-STS enforce están rechazando entrega.

certificate-host-mismatch

El nombre en el certificado no coincide con el hostname del MX. Si tu MX es mx.tudominio.com pero el certificado es para mail.proveedor.com, falla. Solución: certificado SAN que cubra todos los hostnames de MX.

certificate-not-trusted

El certificado no encadena a una CA de confianza. Causas:

• Cadena intermedia mal servida (faltan intermedios).
• Certificado autofirmado.
• CA que el receptor no reconoce.

Verifica con:

openssl s_client -starttls smtp -connect mx.tudominio.com:25 -servername mx.tudominio.com < /dev/null

Y revisa la cadena devuelta.

sts-policy-fetch-error

El receptor no pudo obtener tu policy desde https://mta-sts.tudominio.com/.well-known/mta-sts.txt. Causas frecuentes:

• HTTPS roto o certificado expirado en el subdominio mta-sts..
• Redirecciones a HTTP.
• DNS sin resolver mta-sts.tudominio.com.
• Firewall bloqueando conexiones desde IPs de Gmail/Microsoft.

Verifica:

curl -v https://mta-sts.tudominio.com/.well-known/mta-sts.txt

sts-policy-invalid

El contenido del mta-sts.txt no parsea: campos mal formados, MX no listado, modo desconocido. Repasa la sintaxis:

version: STSv1
mode: enforce
mx: mx.tudominio.com
mx: mx2.tudominio.com
max_age: 604800

Cada campo en una línea, sin comas, terminando con salto de línea.

sts-webpki-invalid

El certificado HTTPS de mta-sts.tudominio.com falla validación pública (WebPKI). Distinto del certificado SMTP: este es el del servidor que sirve la política HTTP.

tlsa-invalid (DANE)

Si publicas TLSA para DANE y el receptor lo valida, este fallo indica que el TLSA en DNS no coincide con el certificado servido.

dnssec-invalid

El receptor intentó validar DNSSEC y falló. Tu zona puede tener firma rota o claves caducadas. Repasa con la guía de DNSSEC.

sts-policy-not-found

Hay TXT TLS-RPT pero no hay TXT MTA-STS en _mta-sts.tudominio.com. Inconsistencia.

starttls-not-supported

El MX no anunció STARTTLS. Tu servidor SMTP no soporta TLS o lo desactivó. Crítico: los receptores con enforce no entregarán.

validation-failure (genérico)

Fallo no clasificable. Revisa el additional-information del reporte si está presente.

Operativa diaria con TLS-RPT

Mailbox dedicado para reportes

Crea [email protected] y reenvía a un buzón dedicado (no el principal) o a un parser. El volumen suele ser de 5-30 mensajes por día si tu dominio recibe correo de Gmail, Microsoft, Yahoo y otros grandes.

Parser básico

Los reportes vienen como .gz adjuntos. Un script en Python descomprime y agrega:

import gzip, json, sys

with gzip.open(sys.argv[1], "rt") as f:
    data = json.load(f)

for policy in data["policies"]:
    s = policy["summary"]
    print(f"OK: {s['total-successful-session-count']}, "
          f"FAIL: {s['total-failure-session-count']}")
    for fail in policy.get("failure-details", []):
        print(f"  {fail['result-type']} x{fail['failed-session-count']}")

Ejecutas sobre el adjunto y obtienes el resumen.

Umbrales de alerta

Cero fallos es ideal pero no realista. Algunos receptores tienen problemas transitorios (DNS lento, certificados intermedios). Umbrales razonables:

• Verde: < 0,1 % de sesiones fallidas.
• Amarillo: 0,1 - 1 %.
• Rojo: > 1 % o cualquier certificate-expired / starttls-not-supported.

Correlacionar con tus logs

Cuando llega un reporte con total-failure-session-count > 0, busca en tus logs SMTP de ese día sesiones desde IPs del receptor (Google: 74.125.0.0/16, Microsoft: rangos publicados en su SPF). Si encuentras sesiones rechazadas o renegociaciones TLS, tienes evidencia local del fallo.

Casos prácticos

Caso 1: certificado caduca

Lunes, 03:00 UTC: certificado del MX caduca. Martes, 09:00 UTC: llegan reportes TLS-RPT de Google, Microsoft y Yahoo, todos con certificate-expired. Si tu MTA-STS está en testing, no se rechazó nada pero quedó registrado. Si está en enforce, hubo entrega rechazada durante 30 horas.

Acción: renovar y monitorizar más estrechamente.

Caso 2: cambio de MX sin actualizar política

Jueves: rotas MX a un proveedor nuevo. Viernes: reportes con sts-policy-invalid porque el mx: listado ya no resuelve. Hay que actualizar mta-sts.txt y publicar nuevo id en el TXT MTA-STS para invalidar caché.

Caso 3: HTTPS de mta-sts caído

Domingo: certificado del subdominio mta-sts.tudominio.com caduca (a veces es un certificado distinto del del MX). Lunes: reportes con sts-webpki-invalid y sts-policy-fetch-error. Receptores con caché vieja siguen entregando; los nuevos no pueden recoger política y caen a TLS oportunista o rechazo según su implementación.

Errores frecuentes

Publicar TLS-RPT y no leer los reportes

Activarlo sin proceso de revisión es perder el dato. Como mínimo, alguien debe abrir el buzón una vez por semana y mirar resumen.

Confundir reportes TLS-RPT con reportes DMARC

DMARC reporta autenticación; TLS-RPT reporta cifrado en tránsito. Son canales separados con _dmarc y _smtp._tls respectivamente.

Usar el mismo buzón para DMARC y TLS-RPT sin filtros

Mezclar volúmenes hace que se pierda información. Buzones separados o reglas de filtrado por subject (Report Domain: para DMARC, TLS-RPT o Content-Type: application/tlsrpt+gzip).

Ignorar el modo testing de MTA-STS

Antes de pasar a enforce, mantén la política en testing 30-60 días, lee TLS-RPT, arregla todos los fallos. Pasar a enforce con fallos abiertos rechaza entrega legítima.

Reportes que no llegan

Si esperas reportes y no llegan, verifica:

• Sintaxis correcta del TXT (v=TLSRPTv1).
• Buzón existe y acepta mensajes grandes (algunos reportes superan 1 MB).
• Tu volumen de correo entrante es suficiente para que receptores generen reportes (pocos receptores y poco volumen = pocos reportes).

Combinar con otras señales

TLS-RPT es una de varias fuentes:

• Reportes DMARC dan visibilidad sobre autenticación.
• Postmaster Tools sobre reputación en Gmail.
• TLS-RPT sobre cifrado.
• Logs SMTP propios sobre la realidad de tu MX.

La intersección de las cuatro te da diagnóstico completo.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing en España de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.