Decodificador de informes TLS — lee informes TLSRPT agregados en español claro
Pega un informe TLSRPT agregado JSON — el archivo diario que Gmail, Outlook y otros emisores principales envían a tu dirección rua cuando MTA-STS o DANE está configurado en tu dominio inbound. El decodificador parsea la sección de política, totaliza las sesiones exitosas vs fallidas, desglosa fallos por result-type (certificado expirado, STARTTLS no soportado, error de fetch de política STS y el resto del catálogo RFC 8460), identifica los MTAs emisores que experimentaron los fallos, y renderiza todo como una tabla legible en vez de una pantalla de JSON crudo. Sin subida; el parsing ocurre enteramente en tu navegador.
Pega un informe JSON TLSRPT
Copia el JSON de cualquier informe que hayas recibido — Gmail, Microsoft, Yahoo, o cualquier emisor RFC 8460. El parser corre en tu navegador; nada sale de tu máquina.
100% cliente · Nada se sube · Compatible con informes RFC 8460 de Gmail, Outlook, Yahoo y MTAs autoalojados
TLSRPT es el mecanismo de informe agregado diario para SMTP TLS — el ciclo de retroalimentación que te dice cuándo los emisores están fallando en entregar correo a tu dominio sobre canales cifrados
RFC 8460 — SMTP TLS Reporting, publicado en septiembre 2018 — define un formato de informe agregado JSON que los servidores de correo emisores usan para decir a los dominios receptores sobre fallos de negociación TLS. El flujo es directo: publicas un registro TXT en _smtp._tls.tudominio.com conteniendo v=TLSRPTv1; rua=mailto:tlsrpt@tudominio.com (o un endpoint https). Emisores principales — Gmail, Microsoft, Yahoo y la mayoría de MTAs modernos — leen ese registro cuando intentan entregar correo a tu dominio, registran cada evento TLS del día, y te envían un informe JSON agregado cubriendo 00:00-23:59 UTC, típicamente entregado unas horas después. Si todo está funcionando, los informes o no llegan en absoluto (el emisor no vio fallos) o llegan mostrando 100% de sesiones exitosas.
El informe en sí está estructurado. Los campos de nivel superior son organization-name (el emisor, ej., "Google Inc."), date-range (start-datetime y end-datetime, ambos ISO 8601), contact-info (un email en el emisor para seguimiento), report-id (un identificador único), y policies (un array de objetos política, uno por política que el emisor evaluó contra tu dominio). Cada objeto política lleva la política misma (tipo sts/tlsa/no-policy-found, las líneas de policy-string, el policy-domain, los MX hosts cubiertos), un summary (total-successful-session-count, total-failure-session-count), y un array failure-details con una entrada por cada tipo de fallo distinto — result-type (el código de fallo enumerado RFC 8460), sending-mta-ip (cuál de los MTAs del emisor topó con el fallo), receiving-mx-hostname (en cuál de tus MX hosts pasó el fallo), failed-session-count (cuántas sesiones toparon con este fallo específico), additional-information (URL de texto libre con más contexto, frecuentemente vacío), y failure-reason-code (detalle adicional definido por el emisor).
Por qué esto importa en 2026: un fallo TLS en correo inbound no rompe entrega por default — STARTTLS es oportunístico, así que un emisor que no puede negociar cifrado típicamente cae a texto plano en vez de rehusar enviar. El fallo es invisible desde tu lado; el correo sigue llegando, y no tienes idea de que tu certificado expiró o que tu política MTA-STS es inalcanzable. TLSRPT es el único ciclo de retroalimentación que hace esa invisibilidad visible. Si tienes MTA-STS en modo enforce y tu certificado expira un domingo por la tarde, el informe TLSRPT del lunes por la mañana es lo único que te lo dice. Para cuando el informe llega, ya perdiste un día de correo; sin el informe, perderías cada día hasta que alguien por casualidad note los errores SMTP en su cola saliente.
Los informes también importan para postura de cumplimiento en 2026. NIS2 y RGPD ambos enfatizan cifrado en tránsito como parte de medidas técnicas apropiadas; HIPAA explícitamente lo requiere para PHI. Para clientes en LATAM y España, la AEPD ha priorizado en sus guías 2024-2025 cifrado de transporte como medida razonable bajo Art. 32 RGPD; ANPD bajo LGPD, INAI bajo LFPDPPP, SIC bajo el régimen colombiano y AAIP bajo Ley 25.326 convergen en línea similar. Una configuración documentada monitoreada por TLSRPT es parte de la evidencia que un auditor de seguridad B2B quiere ver al revisar infraestructura de email. El decodificador arriba convierte el JSON diario en algo que realmente puedes leer — y reenviar al auditor o al ingeniero de guardia que necesita entenderlo sin parsear el RFC ellos mismos.
Cada código de fallo RFC 8460 que el decodificador puede mostrar, qué significa, y qué hacer
starttls-not-supported El emisor intentó STARTTLS en la conexión SMTP; tu MTA no anunció soporte STARTTLS en EHLO. O tu MTA está mal configurado (sin certificado TLS, módulo TLS desactivado) o el emisor conectó al host equivocado. Arreglo: confirma que STARTTLS está habilitado en cada MX listado en tu registro MX.
certificate-host-mismatch El certificado TLS que tu MTA presentó no incluye el hostname al que el emisor conectó (típicamente tu hostname MX). O los Subject Alternative Names del certificado están faltando el hostname MX, o el certificado equivocado está enlazado al listener. Arreglo: reemite el certificado para incluir cada hostname MX; verifica con openssl s_client -connect mx.ejemplo.com:25 -starttls smtp.
certificate-expired El certificado TLS está pasada su fecha notAfter. Emisores con MTA-STS enforce rehusarán entregar; emisores en modo oportunístico pueden caer a texto plano o rehusar enteramente dependiendo de política. Arreglo: renueva el certificado inmediatamente, automatiza renovación (Let's Encrypt + certbot, ACM, etc.), y pon monitoreo de expiración que alerte 30 días antes.
certificate-not-trusted El certificado es válido para el hostname y no expirado, pero está firmado por una autoridad que el emisor no confía — típicamente un cert auto-firmado o un cert emitido por una CA interna. Arreglo: reemplaza con un certificado de una CA públicamente confiable (Let's Encrypt es gratis y funciona para SMTP).
validation-failure Fallo general de validación TLS no cubierto por los códigos más específicos arriba — errores de negociación de protocolo, mismatches de cifrado, handshake abortado. Menos accionable desde el informe solo; si ves un pico de estos, captura trazas de paquete de la conexión fallida para diagnosticar.
tlsa-invalid El registro DANE TLSA existe para tu MX host pero no coincide con el certificado que tu MTA presentó. Específico de DANE; no relevante si solo usas MTA-STS. Arreglo: regenera el registro TLSA tras cada renovación de certificado (o usa automatización ACME-TLSA).
dnssec-invalid La validación DNSSEC falló durante el lookup DANE TLSA. O las firmas DNSSEC de tu zona están expiradas/inválidas, o el camino entre tú y tu proveedor DNS está mal configurado. Arreglo: confirma que la validación DNSSEC pasa vía dnsviz.net o herramienta similar; re-firma la zona si es necesario.
sts-policy-fetch-error El emisor intentó traer tu política MTA-STS en https://mta-sts.tudominio.com/.well-known/mta-sts.txt y la petición falló — error HTTP, problema de certificado, fallo de resolución DNS, o timeout. Arreglo: confirma que la URL de política devuelve 200 con el content-type correcto; verifica que el subdominio mta-sts resuelva; valida que el certificado HTTPS en ese endpoint sea válido.
sts-policy-invalid La política MTA-STS fue traída pero está malformada — faltan campos requeridos, valor mode inválido, o sintaxis que viola RFC 8461. Arreglo: valida la política con un checker MTA-STS; la política debe empezar con version: STSv1 y contener mode válido (enforce/testing/none), entradas mx, y max_age.
sts-webpki-invalid El certificado HTTPS para mta-sts.tudominio.com falló validación (expirado, hostname incorrecto, auto-firmado, CA no confiable). Arreglo: este es un certificado web regular — renueva o reemite de una CA públicamente confiable. El certificado del subdominio mta-sts es independiente del certificado de tu hostname MX; ambos necesitan ser válidos.
Fallos individuales raramente importan. Patrones a través de informes importan. Aquí qué buscar
Pico repentino de certificate-expired o certificate-not-trusted
Casi siempre indica una renovación que no propagó correctamente — el cert nuevo fue emitido pero el MTA no fue recargado, o el cert fue desplegado a un nodo del clúster pero no a los otros. Inicio repentino, causa clara; reinicia el servicio afectado y mira el informe del día siguiente mostrar el conteo bajar a cero.
sts-policy-fetch-error persistente
El subdominio mta-sts tiene un problema — o no resuelve, el endpoint HTTPS está caído, o el archivo de política está faltando. Persistente porque cada emisor re-trae la política en su propio caché expirado, así que un problema un día aparece en los informes del día siguiente a través de múltiples emisores. Arregla el endpoint; los fallos se irán durante varios días mientras los cachés de los emisores se refrescan.
Una sola IP MTA mostrando fallos mientras otras están limpias
Uno de tus MX hosts tiene una configuración diferente a los otros. Usualmente un nodo desfasado en un clúster — un servidor que no recibió la actualización de cert, una réplica que corre una versión vieja de Postfix, un MX backup con un archivo de política diferente. Mira el campo receiving-mx-hostname en los detalles de fallo para identificar el host específico.
starttls-not-supported de un emisor mayor después de meses de informes limpios
Casi siempre signo de un cambio operativo reciente — upgrade Postfix, parche OS, cambio de política de cifrado que rompió negociación TLS, regla de firewall que empezó a dropear el handshake cifrado. Los emisores mayores no cambiaron; tú sí. Mira los deploys en las 24 horas antes de que los fallos empezaran.
Informes vacíos — cero fallos consistentemente
El estado deseado. El registro TLSRPT está funcionando (recibes informes), TLS negocia con éxito (sin detalles de fallo), y tienes visibilidad sobre el canal. Mantén los informes fluyendo; el día que empieces a recibir informes no vacíos es el día que tienes una señal accionable.
Leer un informe es lo que esta herramienta hace. Leer cada informe cada día, alertar en regresiones, y triar fallos a causa raíz es lo que el flujo gestionado hace
Un informe TLSRPT a la semana es lo que la mayoría de dominios inbound ven cuando la configuración es saludable. Multiplica por cada emisor, multiplica por cada dominio que operas, y el trabajo de parsing escala más allá de lo que una persona puede sostener manualmente. Nuestro flujo de deliverability gestionada incluye ingest TLSRPT automatizado, diff diario contra el informe previo para atrapar regresiones, alertas en result-types específicos (certificate-expired y sts-policy-fetch-error siempre paginan; otros dependen del volumen), y el trabajo de remediación — coordinando renovaciones de cert, arreglando hosting de política MTA-STS, debuggeando el receiving-mx-hostname que falla — que convierte un informe en un arreglo.
El decodificador arriba te da la vista one-shot de un informe. Si estás viendo fallos y quieres entender si son ruido o una regresión real, la siguiente conversación es leer el informe en contexto con la semana previa de informes — y esa conversación va más rápida con alguien que ya hizo el diff y identificó el cambio.
Lo que los equipos preguntan al leer un informe TLSRPT por primera vez
Mi informe llega comprimido — ¿cómo lo descomprimo?
+
RFC 8460 especifica application/tlsrpt+gzip para el formato comprimido típico. En línea de comando: gunzip informe.json.gz. En macOS o Windows, doble clic en el archivo en el adjunto del correo típicamente lo expande. Una vez expandido, pega el JSON resultante en el decodificador arriba. El nombre del archivo usualmente sigue el patrón emisor.ejemplo!tudominio.com!1234567890!1234567891.json.gz — los dos números son timestamps Unix de inicio y fin para la ventana del informe.
No recibo informes TLSRPT. ¿Es bueno o malo?
+
Depende de si publicas el registro TXT. Si _smtp._tls.tudominio.com resuelve y devuelve un registro TLSRPTv1 válido, cero informes significa cero fallos — el estado deseado. Si el registro TXT falta o está malformado, recibes cero informes porque ningún emisor sabe dónde enviarlos, lo cual es el peor estado porque no tienes visibilidad de ninguna manera. Corre un checker MTA-STS/TLSRPT contra tu dominio para confirmar que el registro resuelve; si lo hace y los informes aún no llegan tras 48 horas, envíate correo de prueba desde una cuenta Gmail (u otro emisor mayor) y verifica el spool inbound — si el correo llega pero no llega TLSRPT, tu endpoint rua es el problema.
¿Debería correr MTA-STS en modo enforce o testing?
+
Empieza en modo testing, mira informes TLSRPT durante 2-4 semanas para confirmar cero fallos de emisores mayores, luego mueve a enforce. El riesgo de ir directo a enforce es que cualquier mala configuración — MX equivocado en el archivo de política, problema de validez de certificado, subdominio mta-sts inalcanzable — hace que emisores legítimos rehusen correo a tu dominio. El modo testing te da visibilidad sin la consecuencia de rechazo. Una vez que los informes están consistentemente limpios, cambia a enforce; la protección adicional contra ataques de downgrade y bypasses de validación de certificado vale la disciplina operativa de monitorear TLSRPT en adelante.
¿Por qué no recibo failure-details para cada sesión fallida?
+
TLSRPT es agregado por diseño — cada entrada failure-details resume múltiples sesiones compartiendo el mismo result-type, sending-mta-ip y receiving-mx-hostname, con el conteo en failed-session-count. Los emisores no están requeridos a reportar detalles a nivel de sesión para limitar tamaño de informe y proteger privacidad. Si necesitas detalle a nivel de sesión, correlaciona el informe con tus propios logs MTA: el campo date-range te dice la ventana, y el campo receiving-mx-hostname te dice cuál de tus MX servers verificar.
¿Pueden los emisores enviar informes TLSRPT falsos a mi endpoint rua?
+
Sí — TLSRPT no tiene verificación de delegación incorporada como la autorización de dominio de reporting de DMARC. RFC 8460 especifica que informes enviados vía SMTP deben ser firmados DKIM por el dominio reportante, así que puedes validar la firma para confirmar que el informe vino del emisor reclamado. Informes enviados vía HTTPS POST son autenticados solo por el certificado del endpoint. Trata el contenido del informe como input no confiable — no evalúes JSON, no pases valores a shell o SQL sin sanitización, y rate-limita el endpoint para prevenir DoS. El decodificador arriba corre enteramente en tu navegador, así que incluso JSON maliciosamente crafteado en el input no puede afectar nada fuera del tab.
¿Es TLSRPT lo mismo que informes DMARC RUA?
+
No — diferentes protocolos, diferentes capas. Los informes DMARC RUA cubren resultados de autenticación (resultados SPF y DKIM, alineación con el dominio From) y son enviados como XML. Los informes TLSRPT cubren resultados de cifrado de transporte (éxito o fallo de negociación TLS) y son enviados como JSON. Típicamente quieres ambos: DMARC te dice quién está firmando como tu dominio y si pasan alineación; TLSRPT te dice si los emisores te están alcanzando sobre un canal cifrado. Los dos informes son complementarios, y la mayoría de emisores que emiten uno también emiten el otro.