¿Por qué analizar tus informes TLS-RPT?
Google, Microsoft y Yahoo te envían cada día informes TLS-RPT. Estos archivos JSON revelan si el cifrado TLS funciona para los correos entrantes en tu dominio. Sin analizarlos, los fallos TLS pasan desapercibidos durante semanas - y tus correos circulan sin protección.
El problema: estos informes son archivos JSON comprimidos en gzip, ilegibles a simple vista. Un solo certificado expirado en un MX secundario puede comprometer miles de conexiones sin que lo detectes.
Tres razones para analizar tus informes TLS-RPT:
- Detectar certificados expirados - un certificado caducado en un MX secundario expone tus correos a interceptación.
- Validar tu política MTA-STS - si la política es inaccesible, los remitentes lo reportan. Inspecciona tu MTA-STS.
- Anticipar incidentes - un aumento súbito en la tasa de fallos indica un problema de configuración. Actúa antes de que los correos reboten o sean interceptados.
Cómo analizar un informe TLS-RPT en 3 pasos
Paso 1: Obtén el informe
Busca en tu bandeja de entrada los correos de noreply-smtp-tls-reporting@google.com, Microsoft o Yahoo. Descarga el archivo adjunto .json.gz o .json. Si no recibes informes, configura tu registro TLS-RPT primero.
Paso 2: Carga el archivo
Arrastra y suelta el archivo en la zona de carga de arriba. CaptainDNS acepta archivos .json y .json.gz de hasta 10 MB. La descompresión y el análisis son automáticos.
Paso 3: Lee el diagnóstico y actúa
CaptainDNS analiza el informe y genera un diagnóstico completo:
- Puntuación de salud sobre 100 - evalúa la salud TLS global de tu dominio en 4 niveles
- Desglose por política - resultados separados para MTA-STS y DANE con tasas de éxito
- Fallos explicados - cada fallo incluye gravedad, causa técnica y recomendación concreta
- Enlace directo a la herramienta - corrige cada problema con un clic desde el diagnóstico
Estructura de un informe TLS-RPT (RFC 8460)
Cada informe TLS-RPT sigue el esquema JSON definido por la RFC 8460. Conocer esta estructura es esencial para interpretar correctamente los diagnósticos.
- organization-name - el remitente del informe (Google Inc., Microsoft Corporation, etc.)
- date-range - el período cubierto, generalmente 24 horas
- policies - una o varias políticas evaluadas (MTA-STS, DANE o ambas)
Para cada política, el informe detalla:
| Campo | Descripción |
|---|---|
policy-type | Tipo de política (sts, tlsa o no-policy-found) |
policy-domain | Dominio afectado |
total-successful-session-count | Conexiones TLS exitosas |
total-failure-session-count | Conexiones TLS fallidas |
failure-details | Detalle de cada tipo de fallo |
12 tipos de fallos TLS analizados
CaptainDNS identifica los 11 códigos de fallo definidos por la RFC 8460, más la variante starttls-not-offered que emiten algunos remitentes. Cada fallo incluye su gravedad y la acción correctiva.
Fallos STARTTLS
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
starttls-not-supported | Crítica | El servidor MX no ofrece STARTTLS | Activa STARTTLS en la configuración del servidor MX |
starttls-not-offered | Crítica | Variante de starttls-not-supported usada por algunos remitentes | Activa STARTTLS en la configuración del servidor MX |
Fallos de certificado
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
certificate-expired | Alta | Certificado TLS expirado | Renueva con Let's Encrypt o con tu CA |
certificate-host-mismatch | Alta | CN/SAN no coincide con el hostname MX | Emite un certificado que incluya el hostname MX exacto |
certificate-not-trusted | Alta | CA no reconocida o certificado autofirmado | Utiliza un certificado de una CA pública reconocida |
Fallos de validación TLS
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
validation-failure | Media | Fallo TLS genérico, no cubierto por los demás códigos | Consulta failure-reason-code y revisa la configuración TLS del MX |
Fallos MTA-STS
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
sts-policy-fetch-error | Alta | Política MTA-STS inaccesible (HTTP 4xx/5xx) | Inspecciona tu política MTA-STS |
sts-policy-invalid | Alta | Contenido de la política inválido | Valida la sintaxis MTA-STS |
sts-webpki-invalid | Alta | Certificado HTTPS del servidor MTA-STS inválido | Renueva el certificado de mta-sts.dominio |
Fallos DANE
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
tlsa-invalid | Alta | Registro TLSA obsoleto o mal configurado | Verifica tus registros DANE/TLSA |
dnssec-invalid | Crítica | Cadena DNSSEC rota | Ejecuta el DNSSEC Checker para diagnosticar |
dane-required | Alta | DANE requerido pero no disponible | Genera registros TLSA válidos |
Casos de uso concretos
Tres incidentes reales que los administradores descubren gracias al analizador TLS-RPT.
Incidente 1: Certificado expirado en un MX secundario
Síntoma: El informe de Google reporta 200 fallos certificate-expired en mail2.ejemplo.com.
Diagnóstico: El certificado Let's Encrypt del MX secundario no se renovó. El cron de certbot estaba averiado.
Acción: Renueva el certificado y verifica la automatización del proceso de renovación.
Incidente 2: Política MTA-STS inaccesible
Síntoma: Microsoft reporta sts-policy-fetch-error con código HTTP 503.
Diagnóstico: El servidor que aloja https://mta-sts.ejemplo.com/.well-known/mta-sts.txt está fuera de servicio.
Acción: Restablece el servidor o activa el alojamiento MTA-STS gestionado de CaptainDNS para garantizar alta disponibilidad.
Incidente 3: Ninguna política TLS configurada
Síntoma: El informe muestra no-policy-found en un subdominio. Sin MTA-STS ni DANE, el correo transita sin cifrado obligatorio.
Diagnóstico: El subdominio carece de toda política de seguridad TLS.
Acción: Genera una política MTA-STS o despliega DANE/TLSA para proteger el subdominio.
FAQ
P: ¿Qué es un informe TLS-RPT y cómo se lee?
R: Un informe TLS-RPT es un archivo JSON enviado diariamente por servidores de correo (Google, Microsoft, Yahoo). Contiene las estadísticas de conexiones TLS hacia tu dominio: éxitos, fallos y causas. Estos archivos están en formato .json.gz y son ilegibles sin herramienta. Carga el archivo en CaptainDNS para obtener un diagnóstico visual inmediato.
P: ¿Por qué recibo correos de noreply-smtp-tls-reporting@google.com?
R: Tu dominio tiene un registro DNS TLS-RPT con una dirección mailto:. Google te envía un informe diario sobre las conexiones TLS hacia tu dominio. Es normal y deseable: estos informes son tu radar de seguridad TLS. Analízalos regularmente para detectar fallos a tiempo.
P: ¿Cuál es la diferencia entre un TLS-RPT checker y un TLS-RPT report analyzer?
R: El TLS-RPT checker verifica tu registro DNS (la configuración). El TLS-RPT report analyzer interpreta los archivos JSON que recibe (los resultados). Usa ambos: el checker para validar la configuración, el analyzer para supervisar los resultados.
Herramientas complementarias
El analizador de informes es una pieza del ecosistema. Combínalo con estas herramientas para una supervisión TLS de extremo a extremo.
| Herramienta | Utilidad |
|---|---|
| Generador TLS-RPT | Crear el registro DNS TLS-RPT para recibir informes |
| Inspector TLS-RPT | Verificar que tu registro DNS TLS-RPT está correctamente publicado |
| TLS-RPT Syntax Checker | Validar la sintaxis de un registro TLS-RPT |
| Inspector MTA-STS | Verificar el despliegue y accesibilidad de MTA-STS |
| DANE/TLSA Checker | Verificar los registros DANE/TLSA de tus servidores MX |
| Auditoría de dominio email | Auditoría completa: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DANE |
| Monitorización TLS-RPT | Supervisar y analizar automáticamente los informes TLS-RPT |
Recursos útiles
- RFC 8460 - SMTP TLS Reporting - especificación oficial del protocolo TLS-RPT
- RFC 8461 - MTA Strict Transport Security - protocolo MTA-STS, complementario a TLS-RPT
- RFC 7672 - SMTP Security via DANE - autenticación DANE para conexiones SMTP
- Google - Configurar TLS Reporting - guía oficial Google Workspace
¿Aún no recibes informes TLS-RPT? Crea tu registro TLS-RPT en menos de 2 minutos. ¿Ya tienes informes? Cárgalos arriba para obtener un diagnóstico completo. ¿Quieres una visión global? Lanza una auditoría de dominio email completa.