Por qué verificar su TLS-RPT
El transporte SMTP utiliza TLS de forma oportunista: si la negociación falla, la conexión cae a texto plano sin alerta. Sus emails salen sin cifrar y nadie le 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 le da por fin visibilidad. Cada MTA emisor que falla al establecer TLS envía un reporte JSON a la dirección rua que usted publica. Sin este mecanismo, está ciego.
Verificar la configuración antes de olvidarla en un rincón del DNS es esencial:
- Registro ausente → no sabe nada de los fallos TLS, sin trazabilidad de auditoría
- URI rua inválida → los MTAs no pueden entregar los reportes, se descartan
- Sin autorización externa → si delega a un analizador tercero, sus servidores rechazan los reportes
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 reportes durante la fase testing
Cómo usar este checker en 3 pasos
Paso 1: ingrese el dominio a analizar
Escriba el dominio exactamente como aparece en sus 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, recupera el TXT publicado y resuelve la autorización externa si es necesario.
Paso 2: analice los resultados
El checker muestra:
| Elemento | Descripción |
|---|---|
| Registro TXT | Contenido en bruto publicado en _smtp._tls.dominio |
| Versión | Debe ser exactamente TLSRPTv1 |
| URIs rua | Destinos de los reportes (mailto, https) |
| Autorización externa | Presencia de _report._tls.[tercero] si rua apunta fuera |
| Tags desconocidos | Campos fuera del RFC 8460 señalados como info |
| Coherencia MTA-STS | Presencia de un registro _mta-sts.dominio asociado |
Paso 3: corrija los problemas marcados
Los resultados se clasifican por gravedad:
- Crítico → el registro es inválido, no se enviará ningún reporte
- Advertencia → funciona pero expone a un riesgo o cobertura parcial
- Info → buena práctica no bloqueante (tag desconocido, MTA-STS ausente)
Corrija el DNS, espere la propagación, y relance el checker.
Qué es TLS-RPT
TLS-RPT (SMTP TLS Reporting, RFC 8460) es un mecanismo que:
- Publica una dirección de reporte en el DNS para el dominio receptor
- Pide a los MTAs emisores que envíen un reporte JSON cuando TLS falla
- 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, conteniendo 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 reportes 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
| Verificación | Error si... |
|---|---|
TXT presente en _smtp._tls.dominio | Ningún registro |
Empieza por v=TLSRPTv1 | Prefijo ausente o caja incorrecta |
| Registro único | Múltiples TXTs TLS-RPT detectados |
| Sin CNAME | _smtp._tls apunta a un CNAME (prohibido) |
Sintaxis del registro
| Verificación | Error si... |
|---|---|
Tag v= en primera posición | Versión ausente o no primera |
Tag rua= presente | Ningún destino definido |
Valor TLSRPTv1 exacto | Variantes como TLSRPT1 o tlsrptv1 |
URIs de reporte
| Verificación | Error si... |
|---|---|
mailto: válido | Dirección email mal formada, espacios prohibidos |
https: válido | Esquema ausente o URL malformada |
| Al menos una URI | Tag rua vacío |
Calidad del rua
- El dominio de la URI rua coincide con el dominio verificado → sin necesidad de autorización externa
- El dominio es diferente → verificar la presencia de
[dominio]._report._tls.[tercero](autorización cross-domain) - 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á reporte.
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. Identifique los duplicados, conserve el que desee aplicar, elimine 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: el RFC prohíbe CNAME en esta ubicación. Publicar un TXT directo en su lugar.
Autorización externa requerida (rua_unauthorized_external)
Causa: la dirección rua usa un dominio diferente del dominio TLS-RPT.
Solución: el dominio receptor (por ejemplo uriports.com) debe publicar:
captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"
Este registro autoriza la entrega de reportes para captaindns.com.
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 reportes TLS-RPT. Ver el MTA-STS Checker y la guía completa.
Autorización cross-domain y rua externa
El RFC 8460 retoma la convención DMARC (RFC 7489 §7.1): un dominio no puede pedir a otro dominio recibir sus reportes sin su consentimiento explícito.
El mecanismo
Su dominio: captaindns.com
URI rua: mailto:tls-reports@uriports.com
El dominio externo uriports.com debe publicar:
captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"
Sin este registro, los MTAs emisores conformes se niegan a reenviar los reportes a uriports.com (protegen a los analizadores terceros contra abusos de redirección).
Trampas comunes
- Confusión con DMARC: DMARC usa
_report._dmarc.[tercero], TLS-RPT usa_report._tls.[tercero]. Verifique el prefijo correcto. - Múltiples dominios monitorizados: un analizador multi-tenant (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) debe publicar un registro por dominio cliente (
cliente1.com._report._tls.postmarkapp.com,cliente2.com._report._tls.postmarkapp.com, etc.). - Sin wildcard permitido: se requiere un registro explícito por par (dominio monitorizado, dominio analizador).
- El checker señala automáticamente las rua externas sin autorización publicada.
TLS-RPT y MTA-STS: despliegue combinado
Los dos protocolos forman una defensa en profundidad:
| Protocolo | Rol | Ubicación |
|---|---|---|
| MTA-STS | Impone el cifrado TLS (RFC 8461) | _mta-sts.dominio + política HTTPS |
| TLS-RPT | Reporta los fallos (RFC 8460) | _smtp._tls.dominio |
Orden de despliegue recomendado
- Publicar TLS-RPT primero para recopilar reportes
- Desplegar MTA-STS en modo testing sin bloquear la entrega
- Observar de 2 a 4 semanas los reportes TLS-RPT para identificar los MX problemáticos
- Pasar MTA-STS a modo enforce cuando los reportes estén limpios
- 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. Ve los problemas sin poder evitarlos.
Sin TLS-RPT: MTA-STS impone TLS pero nunca sabrá que un MTA legítimo está bloqueado por su política. Riesgo de no entrega silenciosa.
Herramientas complementarias y recursos
| Herramienta | Utilidad |
|---|---|
| Validador sintaxis TLS-RPT | Validar la sintaxis de un registro ANTES de publicar |
| Generador TLS-RPT | Crear un registro TLS-RPT conforme RFC 8460 |
| MTA-STS Checker | Verificar el despliegue MTA-STS asociado |
| Hosting MTA-STS | Aloje gratis su política con TLS gestionado |
| DMARC Checker | Completar la autenticación email con DMARC |
| DANE TLSA Checker | Alternativa DNSSEC para seguridad TLS |
| Analizador de reportes TLS-RPT | Decodificar los reportes JSON recibidos |
| Monitorización TLS-RPT | Recibe y analiza automáticamente tus reportes TLS-RPT |
Recursos: