¿Por qué monitorear los informes TLS-RPT?
El monitoreo TLS-RPT hace visibles los fallos de cifrado SMTP que tu servidor nunca registra. Es el único canal normalizado (RFC 8460) por el que los emisores te devuelven lo que se rompió del lado del transporte. Sin él, un correo rechazado por culpa de TLS no deja ningún rastro en el destinatario. Tu reputación se degrada. Tus usuarios no esperan nada porque ignoran que el mensaje existió.
Tres averías reaparecen en casi todos los informes.
Un certificado caducado en el MX hace fallar la negociación cifrada, y los emisores en modo estricto rechazan el mensaje en lugar de entregarlo en claro. Una política MTA-STS que apunta a un MX desaparecido produce el mismo resultado: conexión rechazada, correo que nunca llega. Y lo peor sigue siendo la degradación STARTTLS, cuando un equipo de red retira el anuncio STARTTLS del diálogo SMTP. El correo pasa entonces en claro. Nadie lo sabe. El informe TLS-RPT, en cambio, lo ve.
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 que devuelve los fallos de negociación TLS al dominio destinatario. Los servidores emisores reportan cada conexión cifrada que falla. Basta un solo registro DNS para activarlos.
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?
Un informe TLS-RPT es un documento JSON que agrega, sobre una ventana de 24 horas, todos los intentos de conexión TLS de un emisor hacia tu dominio. Cuenta las sesiones exitosas y las fallidas, y detalla cada fallo por tipo. CaptainDNS decodifica ese JSON y lo muestra en claro.
| 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 |
Tipos de fallos TLS-RPT (RFC 8460)
| Tipo de fallo | Descripción |
|---|---|
starttls-not-supported | El servidor destinatario no soporta STARTTLS |
certificate-expired | El certificado TLS presentado por el MX ha expirado |
certificate-host-mismatch | El certificado no coincide con el nombre de host del MX |
certificate-not-trusted | La cadena de certificados no es confiable para el emisor |
validation-failure | Fallo de validación TLS genérico |
sts-policy-invalid | La política MTA-STS no pudo ser validada |
sts-webpki-invalid | El host de la política MTA-STS tiene un certificado Web PKI inválido |
tlsa-invalid | El registro DANE TLSA es inválido o no coincide |
dane-required | DANE es requerido pero no pudo ser validado |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protege | Cifrado del transporte (SMTP TLS) | Autenticación del remitente (SPF/DKIM) |
| Reporta | Fallos de conexión TLS, errores de certificado | Fallos de alineación de autenticación |
| RFC | RFC 8460 | RFC 7489 |
| Registro DNS | _smtp._tls TXT | _dmarc TXT |
| Amenazas detectadas | Certificados expirados, eliminación STARTTLS, errores DANE/MTA-STS | Suplantación, phishing, imitación de dominio |
Ambos protocolos son complementarios. Implementa el monitoreo DMARC junto con TLS-RPT para una visibilidad completa de la seguridad del correo.
¿Quién envía informes TLS-RPT?
Los grandes proveedores de correo emiten informes TLS-RPT en cuanto intentan una conexión TLS hacia tu dominio. Por sí solos, Google y Microsoft encaminan la mayoría del correo entrante de un dominio profesional típico. ¿Recibes correo de alguno de ellos? Entonces un registro TLS-RPT publicado ya te da una cobertura útil.
- Google (Gmail, Workspace): Envía informes agregados diarios cubriendo todos los intentos de conexión
- Microsoft (Outlook, Exchange Online): Reporta fallos de negociación TLS para los inquilinos de Microsoft 365
- Yahoo: Entrega datos TLS-RPT para la infraestructura de Yahoo Mail y AOL
- Apple (iCloud Mail): Reporta fallos TLS para la entrega de iCloud Mail
- Comcast: uno de los primeros ISP en adoptar los informes TLS-RPT
Casos de uso concretos
La mayoría de los incidentes TLS se resuelven en una hora cuando los ves, y se prolongan semanas cuando no los ves. Aquí tienes dos averías reales que el monitoreo TLS-RPT sacó a la luz.
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.
En los dos casos, el disparador es el mismo: un informe TLS-RPT leído en el momento justo. Agrega tu dominio a CaptainDNS, publica el registro _smtp._tls, y esas señales llegan a tu panel sin ningún servidor que gestionar.
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: ¿El monitoreo TLS-RPT de CaptainDNS es gratuito?
R: Sí, el servicio de monitoreo TLS-RPT es completamente gratuito. Creemos que cada dominio debería poder monitorear su seguridad TLS sin restricciones técnicas.
P: ¿Cómo configuro mi dominio para enviar los informes aquí?
R: Agrega un registro TXT a _smtp._tls.tudominio.com con el valor v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{tu-token}. El registro exacto se proporciona cuando agregas tu dominio.
P: ¿Qué formatos de informes son compatibles?
R: Aceptamos los informes TLS-RPT en formato JSON tal como lo define la RFC 8460, comprimidos (gzip) o no. Los informes se aceptan vía HTTPS POST.
P: ¿Cómo funciona la verificación de dominio?
R: Agregas un registro TXT de verificación proporcionado por CaptainDNS a tu DNS. Una vez detectado, la propiedad del dominio se confirma y el monitoreo de informes se activa.
P: ¿Necesito MTA-STS para usar TLS-RPT?
R: No, TLS-RPT funciona de forma independiente. Sin embargo, combinar MTA-STS con TLS-RPT es lo recomendado: MTA-STS impone el cifrado, TLS-RPT te informa cuando los emisores no pueden cumplir con esa política.
P: ¿Con qué frecuencia llegan los informes?
R: Los informes se analizan y están disponibles en tu panel en segundos tras la recepción. La mayoría de los proveedores de correo envían informes diariamente.
P: ¿Cuáles son los riesgos sin TLS-RPT?
R: Sin TLS-RPT, eres ciego. Los fallos TLS ocurren silenciosamente: sin rebote, sin notificación, sin registro accesible. Pueden pasar días o semanas antes de que te des cuenta de que los correos de Google, Microsoft u otros proveedores importantes están siendo rechazados o enviados sin cifrar.
P: ¿Qué tipos de fallos TLS reporta TLS-RPT?
R: TLS-RPT cubre todos los tipos de fallo definidos en la RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid y dane-required. Cada tipo indica un problema específico en la cadena de negociación TLS o validación de política.
P: ¿Cuál es la diferencia entre TLS-RPT y DMARC?
R: TLS-RPT y DMARC protegen capas diferentes. DMARC (RFC 7489) verifica la autenticación del remitente mediante alineación SPF y DKIM y combate la suplantación y el phishing. TLS-RPT (RFC 8460) monitorea el cifrado del transporte y reporta cuando las conexiones SMTP TLS fallan, los certificados expiran o STARTTLS es degradado. Ambos son esenciales.
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 |
| Monitoreo DMARC | Supervisar y analizar informes agregados DMARC |
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