¿Por qué monitorizar los informes TLS-RPT?
La monitorización 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 la monitorización TLS-RPT en 3 pasos
Paso 1: Agrega tu dominio
Inicia sesión y añade tu dominio. CaptainDNS proporciona una dirección de email para recibir informes del monitor y una URL HTTPS alternativa.
Paso 2: Verifica la propiedad del dominio
Añade el TXT de verificación de CaptainDNS para demostrar la propiedad del dominio. La verificación del dominio y la activación no confirman la recepción de informes.
Paso 3: Publica el registro TLS-RPT
Consulta la configuración del monitor para publicar el TXT _smtp._tls recomendado con su destino mailto. Revisa los destinatarios conservados antes de sustituir un TXT existente. Si falla la consulta DNS, añade solo el fragmento a rua= sin eliminar otros destinatarios, o reintenta para obtener el valor completo.
¿Qué es TLS-RPT?
TLS-RPT (SMTP TLS Reporting), definido por la RFC 8460, permite a los remitentes participantes comunicar los resultados de las conexiones TLS. El TXT indica el destino de los informes, sin garantizar su envío.
Ejemplo de registro DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Ejemplo ilustrativo: sustituye TOKEN por el token de la configuración de tu monitor. Si ya existe un TXT, consulta la recomendación del monitor para revisar los destinatarios que se conservarán. El fragmento mailto por sí solo no es un TXT completo.
¿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 informe |
| 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 |
Los 11 tipos de fallos TLS-RPT (RFC 8460)
El §4.3 de la RFC 8460 define 11 valores de result-type, y la monitorización los reporta todos. Algunos emisores emiten además starttls-not-offered, una variante de starttls-not-supported ajena a la RFC: se trata igual.
| 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 |
tlsa-invalid | El registro DANE TLSA es inválido o no coincide |
dnssec-invalid | La cadena DNSSEC necesaria para DANE está rota o ausente |
dane-required | DANE es requerido pero no pudo ser validado |
sts-policy-fetch-error | Imposible recuperar la política MTA-STS (HTTPS o DNS) |
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 |
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 la monitorización DMARC junto con TLS-RPT para una visibilidad completa de la seguridad del correo.
¿Quién envía informes TLS-RPT?
Los informes proceden de remitentes compatibles con TLS-RPT que intentan entregar correo a tu dominio. Su disponibilidad y frecuencia dependen del tráfico y de la implementación de cada remitente. Publicar el TXT no garantiza informes de un proveedor concreto.
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 la monitorización 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 los 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.
CaptainDNS analiza los informes recibidos sin que tengas que gestionar un servidor ni descodificar JSON. El envío depende de los remitentes y del tráfico hacia tu dominio.
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: ¿La monitorización TLS-RPT de CaptainDNS es gratuita?
R: La primera herramienta de tu cuenta es gratuita. Cada dominio TLS-RPT cuenta como una herramienta: después, 3 €/mes sin IVA. Sin costes ocultos ni período de prueba.
P: ¿Cómo configuro mi dominio para enviar los informes aquí?
R: Consulta la configuración del monitor para publicar el TXT _smtp._tls recomendado con su destino mailto. Revisa los destinatarios conservados antes de sustituir un TXT existente. Si falla la consulta DNS, añade solo el fragmento a rua= sin eliminar otros destinatarios, o reintenta para obtener el valor completo.
P: ¿Qué formatos de informes son compatibles?
R: Aceptamos informes TLS-RPT JSON definidos por la RFC 8460, con o sin compresión gzip, por email y HTTPS POST. El email es el destino recomendado; HTTPS sigue siendo compatible.
P: ¿Cómo funciona la verificación de dominio?
R: Añade el TXT de verificación de CaptainDNS para demostrar la propiedad del dominio. La verificación del dominio y la activación no confirman la recepción de informes.
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 remitentes compatibles con TLS-RPT suelen enviar informes por períodos de 24 horas. La recepción depende de esos remitentes y del tráfico. No hay un plazo garantizado para el primer informe; los informes recibidos se analizan después en el panel.
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 se rechazan o se envían sin cifrar.
P: ¿Qué tipos de fallos TLS reporta TLS-RPT?
R: TLS-RPT cubre los 11 tipos de fallo definidos en la RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid y sts-webpki-invalid. 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) monitoriza 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 tu política MTA-STS (primera herramienta gratis, después 3 €/mes sin IVA) |
| Monitoring 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