Monitoreo TLS-RPT gratuito

¿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?

Tipos de fallos TLS-RPT (RFC 8460)

TLS-RPT vs DMARC

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?

Principales proveedores de correo que envían informes TLS-RPT cuando detectan fallos TLS al conectarse a tu dominio:

• 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 implementar el reporting TLS-RPT

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: ¿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

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