¿Por qué analizar sus informes TLS-RPT?
Google, Microsoft y Yahoo le envían cada día informes TLS-RPT. Estos archivos JSON revelan si el cifrado TLS funciona para los correos entrantes en su dominio. Sin analizarlos, los fallos TLS pasan desapercibidos durante semanas - y sus 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 usted lo detecte.
Tres razones para analizar sus informes TLS-RPT:
- Detectar certificados expirados - un certificado caducado en un MX secundario expone sus correos a interceptación.
- Validar su política MTA-STS - si la política es inaccesible, los remitentes lo reportan. Inspeccione su MTA-STS.
- Anticipar incidentes - un aumento súbito en la tasa de fallos indica un problema de configuración. Actúe antes de que los correos reboten o sean interceptados.
Cómo analizar un informe TLS-RPT en 3 pasos
Paso 1: Obtenga el informe
Busque en su bandeja de entrada los correos de noreply-smtp-tls-reporting@google.com, Microsoft o Yahoo. Descargue el archivo adjunto .json.gz o .json. Si no recibe informes, configure su registro TLS-RPT primero.
Paso 2: Cargue el archivo
Arrastre y suelte 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: Lea el diagnóstico y actúe
CaptainDNS analiza el informe y genera un diagnóstico completo:
- Puntuación de salud sobre 100 - evalúa la salud TLS global de su 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 12 códigos de fallo definidos por la RFC 8460. 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 | Active STARTTLS en la configuración del servidor MX |
Fallos de certificado
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
certificate-expired | Alta | Certificado TLS expirado | Renueve con Let's Encrypt o su CA |
certificate-host-mismatch | Alta | CN/SAN no coincide con el hostname MX | Emita un certificado que incluya el hostname MX exacto |
certificate-not-trusted | Alta | CA no reconocida o certificado autofirmado | Utilice un certificado de una CA pública reconocida |
Fallos MTA-STS
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
sts-policy-fetch-error | Alta | Política MTA-STS inaccesible (HTTP 4xx/5xx) | Inspeccione su política MTA-STS |
sts-policy-invalid | Alta | Contenido de la política inválido | Valide la sintaxis MTA-STS |
sts-webpki-invalid | Alta | Certificado HTTPS del servidor MTA-STS inválido | Renueve el certificado de mta-sts.dominio |
Fallos DANE
| Código | Gravedad | Causa | Acción |
|---|---|---|---|
tlsa-invalid | Alta | Registro TLSA obsoleto o mal configurado | Verifique sus registros DANE/TLSA |
dnssec-invalid | Crítica | Cadena DNSSEC rota | Ejecute el DNSSEC Checker para diagnosticar |
dane-required | Alta | DANE requerido pero no disponible | Genere 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: Renueve el certificado y verifique 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: Restablezca el servidor o active 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: Genere una política MTA-STS o despliegue 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 su dominio: éxitos, fallos y causas. Estos archivos están en formato .json.gz y son ilegibles sin herramienta. Cargue el archivo en CaptainDNS para obtener un diagnóstico visual inmediato.
P: ¿Por qué recibo correos de noreply-smtp-tls-reporting@google.com?
R: Su dominio tiene un registro DNS TLS-RPT con una dirección mailto:. Google le envía un informe diario sobre las conexiones TLS hacia su dominio. Es normal y deseable: estos informes son su radar de seguridad TLS. Analícelos 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 su registro DNS (la configuración). El TLS-RPT report analyzer interpreta los archivos JSON que recibe (los resultados). Use 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. Combine 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 su 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 sus servidores MX |
| Auditoría de dominio email | Auditoría completa: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DANE |
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
¿No recibe informes TLS-RPT todavía? Cree su registro TLS-RPT en menos de 2 minutos. ¿Ya tiene informes? Cárguelos arriba para obtener un diagnóstico completo. ¿Quiere una visión global? Lance una auditoría de dominio email completa.