TLS-RPT Checker

Por qué verificar tu TLS-RPT

El transporte SMTP utiliza TLS de forma oportunista: si la negociación falla, la conexión cae a texto plano sin alerta. Tus emails salen sin cifrar y nadie te avisa. Peor aún, un MITM puede suprimir activamente STARTTLS para forzar esta caída.

TLS-RPT (RFC 8460) no corrige el fallo de cifrado (eso lo hace MTA-STS), pero te da por fin visibilidad. Cada MTA emisor que falla al establecer TLS envía un informe JSON a la dirección rua que publicas. Sin este mecanismo, estás ciego.

Verificar la configuración antes de olvidarla en un rincón del DNS es esencial:

• Registro ausente → no sabes nada de los fallos TLS, sin trazabilidad de auditoría
• URI rua inválida → los MTAs no pueden entregar los informes, se descartan
• Múltiples registros → los MTAs emisores ignoran un TLS-RPT duplicado, no se envía ningún informe

Casos de uso comunes:

• Después de publicar → confirmar que el registro está correctamente propagado
• Auditoría de seguridad email → validar la cobertura TLS y la visibilidad de fallos
• Antes de MTA-STS enforce → asegurar que TLS-RPT recopila informes durante la fase testing

Cómo usar este checker en 3 pasos

Paso 1: introduce el dominio a analizar

Escribe el dominio exactamente como aparece en tus direcciones de email:

• captaindns.com (dominio principal)
• marketing.captaindns.com (subdominio si envía desde un subdominio)

La herramienta consulta automáticamente _smtp._tls.dominio y recupera el TXT publicado.

Paso 2: analiza los resultados

El checker muestra:

Paso 3: corrige los problemas marcados

Los resultados se clasifican por gravedad:

• Crítico → el registro es inválido, no se enviará ningún informe
• Advertencia → funciona pero expone a un riesgo o cobertura parcial
• Info → buena práctica no bloqueante (tag desconocido, MTA-STS ausente)

Corrige el DNS, espera la propagación y relanza el checker.

Qué es TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) es un mecanismo que:

1. Publica una dirección de informe en el DNS para el dominio receptor
2. Pide a los MTAs emisores que envíen un informe JSON cuando TLS falla
3. Proporciona una traza de los fallos de cifrado (certificado expirado, downgrade, mismatch)

La arquitectura es deliberadamente mínima: un único registro TXT publicado en _smtp._tls.dominio, que contiene la versión y una o más URIs rua=.

Ejemplo de registro TLS-RPT:

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Este registro indica a los MTAs emisores (Gmail, Outlook, etc.) que envíen sus informes de fallo TLS a tls-reports@captaindns.com.

Diferencia con MTA-STS: TLS-RPT es el compañero de MTA-STS, no una alternativa. MTA-STS impone el cifrado TLS; TLS-RPT señala los fallos. Los dos protocolos viven en ubicaciones distintas (_mta-sts.dominio para STS, _smtp._tls.dominio para RPT) y funcionan en tándem.

Qué verifica el checker

Cinco dimensiones se analizan en paralelo para producir una puntuación 0-100:

Registro DNS publicado

Sintaxis del registro

URIs de informe

Calidad del rua

• El dominio de la URI rua coincide con el dominio verificado (destino interno)
• El dominio es diferente (destino externo): válido sin ninguna autorización del lado destinatario
• La URI https responde con HTTPS válido (sondeo ligero del lado servidor)

Higiene global

• Presencia simultánea de MTA-STS (bonus +2 a la puntuación)
• Ningún tag desconocido contaminando el registro
• Política coherente con el despliegue mail del dominio

Diagnósticos comunes y soluciones

Registro ausente (missing_record)

Causa: ningún TXT existe en _smtp._tls.captaindns.com.

Solución: publicar

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Tag rua faltante (rua_missing)

Causa: el registro contiene v=TLSRPTv1 pero ningún destino.

Solución: añadir al menos una URI: v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sin rua, ningún MTA enviará informe.

URI rua inválida (rua_invalid_uri)

Causa: la URI está mal formada (falta mailto:, espacio en la dirección, esquema desconocido).

Ejemplos de corrección:

- rua=tls-reports@captaindns.com         # Falta mailto:
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto: tls-reports@captaindns.com # Espacio prohibido tras mailto:
+ rua=mailto:tls-reports@captaindns.com

Múltiples registros (multiple_records)

Causa: más de un TXT TLS-RPT existe en _smtp._tls.captaindns.com.

Solución: el RFC 8460 §3 impone un solo registro. Identifica los duplicados, conserva el que quieras aplicar, elimina los demás.

CNAME en _smtp._tls (cname_on_smtp_tls)

Causa: _smtp._tls.dominio es un CNAME que apunta a otra parte.

Solución: ningún RFC prohíbe el CNAME en esta ubicación. El checker lo reporta como advertencia, no como error: Microsoft 365 ignora un _smtp._tls con alias. Un TXT directo sigue siendo la configuración segura.

MTA-STS compañero ausente (mta_sts_companion_missing)

Causa: TLS-RPT está publicado pero MTA-STS no.

Solución: desplegar MTA-STS para dar sentido a los informes TLS-RPT. Ver el MTA-STS Checker y la guía completa.

Enviar los informes a un dominio externo

Puedes dirigir tus informes TLS-RPT hacia un dominio que no controlas, por ejemplo un analizador de terceros. A diferencia de DMARC, la RFC 8460 no define ningún registro de autorización del lado destinatario: una rua hacia un dominio externo funciona sin publicación adicional.

El mecanismo

Tu dominio: captaindns.com URI rua: mailto:tls-reports@uriports.com

No se requiere ningún registro en uriports.com. El informe se envía directamente. La confianza se apoya en dos salvaguardas previstas por la RFC 8460 §7:

• mailto: el informe va firmado con DKIM por el MTA emisor, lo que autentica su origen.
• https: el dominio de destino controla su propio punto de recogida (posesión del DNS).

La RFC 8460 §7 descartó deliberadamente cualquier mecanismo de verificación adicional, ya que el riesgo de amplificación es menor que con DMARC.

Errores comunes

• No trasladar el mecanismo DMARC: DMARC exige un registro [dominio]._report._dmarc.[tercero] para autorizar una rua hacia un dominio externo. TLS-RPT no tiene equivalente. Publicar un registro _report._tls es inútil y ningún MTA lo espera.
• Verificar el destino: asegúrate simplemente de que la dirección mailto o la URL https de recogida es correcta y operativa.

TLS-RPT y MTA-STS: despliegue combinado

Los dos protocolos forman una defensa en profundidad:

Orden de despliegue recomendado

1. Publicar TLS-RPT primero para recopilar informes
2. Desplegar MTA-STS en modo testing sin bloquear la entrega
3. Observar de 2 a 4 semanas los informes TLS-RPT para identificar los MX problemáticos
4. Pasar MTA-STS a modo enforce cuando los informes estén limpios
5. Mantener TLS-RPT indefinidamente para vigilancia continua

Sin MTA-STS: TLS-RPT señala los fallos pero ninguna política obliga a los MTAs emisores a usar TLS. Ves los problemas sin poder evitarlos.

Sin TLS-RPT: MTA-STS impone TLS pero nunca sabrás que un MTA legítimo está bloqueado por tu política. Riesgo de no entrega silenciosa.

Herramientas complementarias y recursos

Recursos:

• TLS-RPT: la guía completa
• Configurar TLS-RPT en Microsoft 365, Google Workspace y OVHcloud
• Analizar los informes TLS-RPT en el día a día
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS