¿Por qué monitorear los informes TLS-RPT?
TLS-RPT (SMTP TLS Reporting, RFC 8460) ofrece visibilidad sobre los fallos de conexión TLS que afectan tu correo entrante. Sin este mecanismo, no tienes forma de saber cuándo los servidores emisores no logran cifrar el correo destinado a tu dominio.
Tres problemas frecuentes detectados vía TLS-RPT:
- Certificados expirados : Tu servidor MX presenta un certificado TLS inválido o expirado, bloqueando las conexiones cifradas. Resultado: correos rechazados en silencio por grandes proveedores como Google o Microsoft.
- MTA-STS mal configurado : Tu política MTA-STS no coincide con tus servidores MX reales. Resultado: emisores que no pueden validar tu política y degradan la conexión a texto plano.
- Degradación STARTTLS : Intermediarios de red eliminan la extensión STARTTLS, forzando el correo en texto plano. Resultado: comunicaciones sensibles expuestas sin que nadie lo detecte.
Cómo configurar el monitoreo TLS-RPT en 3 pasos
Paso 1: Agrega tu dominio
Inicia sesión y registra el dominio a monitorear. CaptainDNS genera un colector de informes HTTPS único y el registro DNS TLS-RPT correspondiente.
Paso 2: Verifica la propiedad del dominio
Agrega el registro TXT de verificación a tu DNS. La validación es automática una vez que se detecta el registro.
Paso 3: Publica el registro TLS-RPT
Agrega el registro TXT _smtp._tls proporcionado a tu DNS. Los servidores emisores comenzarán a enviar informes de fallos TLS a tu endpoint de CaptainDNS.
¿Qué es TLS-RPT?
TLS-RPT (SMTP TLS Reporting) es un estándar definido por la RFC 8460. Permite a los servidores de correo emisores reportar los fallos de negociación TLS al dominio destinatario.
Ejemplo de registro DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"
El registro _smtp._tls indica a los servidores emisores dónde enviar sus informes JSON cuando una conexión TLS falla hacia tu dominio.
¿Qué contiene un informe TLS-RPT?
| Campo | Descripción |
|---|---|
| Organización emisora | El proveedor de correo que envió el informe |
| Período | Marcas de tiempo de inicio y fin de la ventana de reporte |
| Políticas aplicadas | Políticas MTA-STS, DANE o STARTTLS detectadas |
| Sesiones exitosas | Número de conexiones TLS establecidas con éxito |
| Sesiones fallidas | Número de fallos de negociación TLS con detalles del error |
Casos de uso concretos
Incidente 1: Certificado expirado no detectado
Síntoma: Emisores importantes (Google, Microsoft) reportan fallos certificate-expired en sus informes TLS-RPT.
Diagnóstico: El panel de CaptainDNS muestra un pico de fallos en las últimas 24 horas, todos relacionados con un certificado Let's Encrypt expirado en el MX principal.
Acción: Renovar el certificado TLS del servidor de correo. Los informes siguientes confirman la resolución.
Impacto sin TLS-RPT: Habrías descubierto el problema cuando usuarios empezaran a quejarse de correos no recibidos, días o semanas después.
Incidente 2: Política MTA-STS desincronizada
Síntoma: Los informes reportan fallos sts-policy-invalid a pesar de tener una política MTA-STS publicada.
Diagnóstico: Los informes TLS-RPT revelan que la política MTA-STS hace referencia a un servidor MX que ya no existe.
Acción: Actualizar la política MTA-STS para reflejar los MX actuales.
Impacto sin TLS-RPT: La desincronización habría pasado desapercibida indefinidamente, exponiendo el correo a degradaciones silenciosas.
FAQ - Preguntas frecuentes
P: ¿Qué es un registro TLS-RPT?
R: Un registro TLS-RPT es un registro DNS TXT ubicado en _smtp._tls.tudominio.com. Contiene una directiva rua= que indica a los servidores emisores dónde enviar los informes de fallos TLS (RFC 8460).
P: ¿TLS-RPT y MTA-STS están relacionados?
R: Son complementarios pero independientes. MTA-STS impone una política de cifrado. TLS-RPT te informa cuando los emisores no pueden cumplir esa política. Implementar ambos juntos ofrece una protección completa.
P: ¿Cuántos dominios puedo monitorear?
R: Puedes monitorear hasta 10 dominios desde una sola cuenta. Cada dominio dispone de su propio colector de informes verificado.
P: ¿Qué riesgos hay sin TLS-RPT?
R: Sin TLS-RPT, eres ciego. Un certificado expirado puede bloquear correos entrantes durante días sin que recibas ninguna alerta. Una política MTA-STS mal configurada puede provocar que proveedores como Google o Microsoft degraden la conexión a texto plano, y nadie te lo notifica. TLS-RPT es el único mecanismo que te informa activamente cuando algo falla en el cifrado de tu correo.
Herramientas complementarias
| Herramienta | Utilidad |
|---|---|
| Verificación de sintaxis TLS-RPT | Validar la sintaxis de un registro TLS-RPT |
| Verificación de registro TLS-RPT | Verificar el registro TLS-RPT DNS de tu dominio |
| Generador TLS-RPT | Generar un registro DNS TLS-RPT |
| Lector de informes TLS-RPT | Analizar manualmente un informe JSON TLS-RPT |
| Alojamiento MTA-STS | Alojar gratuitamente tu política MTA-STS |
Recursos útiles
- RFC 8460 - SMTP TLS Reporting : Especificación oficial TLS-RPT
- RFC 8461 - MTA-STS : Estándar complementario para imponer el cifrado SMTP
- Google: Configurar los informes TLS : Guía de Google Workspace para TLS-RPT