¿Qué diferencia hay entre validator y record check de TLS-RPT?

El validator analiza una sintaxis que usted pega, antes de publicar en DNS, sin ninguna petición de red. El record check consulta el DNS en vivo para inspeccionar el registro publicado en _smtp._tls.dominio. Use el validator antes, el record check después.

¿Por qué validar la sintaxis TLS-RPT offline?

Un registro inválido es silenciosamente ignorado por los servidores emisores: usted no recibe ningún informe y solo lo descubre cuando ocurre un incidente. La validación offline detecta los problemas antes de que afecten su visibilidad sobre fallos TLS.

¿Cuáles son los errores de sintaxis TLS-RPT más comunes?

Errores típicos: versión ausente o incorrecta (TLSRPT1 en vez de TLSRPTv1), etiqueta rua ausente, esquema mailto: o https: olvidado antes del endpoint, dirección email mal formada y autorización cross-domain faltante para endpoints externos.

¿El validator verifica la autorización cross-domain?

Sí, si usted indica el campo dominio (modo record_and_domain). El validator analiza entonces cada endpoint externo (mailto o https apuntando a otro dominio) y verifica que existe un registro TLSRPT de autorización en el dominio destinatario.

¿Qué diferencia hay entre endpoints mailto y https?

Los endpoints mailto reciben los informes como adjuntos email (JSON comprimido gzip). Los endpoints https reciben los informes vía HTTP POST en un webhook. mailto es más simple de desplegar, https permite procesamiento automatizado.

¿Cómo corrijo un error 'versión inválida'?

La versión debe ser exactamente v=TLSRPTv1 (sensible a mayúsculas), al inicio del registro. Verifique la capitalización, los espacios y la ausencia de caracteres extraños. v=TLSRPT1 y v=tlsrptv1 son rechazados.

¿Debo también desplegar MTA-STS junto con TLS-RPT?

Sí, altamente recomendado. MTA-STS aplica el cifrado TLS, TLS-RPT le informa cuando la aplicación falla. Sin TLS-RPT, no sabrá si servidores externos no logran conectarse en TLS a su dominio.

¿Cómo validar la sintaxis TLS-RPT para Microsoft 365 y Google Workspace?

Pegue su registro TLS-RPT en el validator. La sintaxis es idéntica sea cual sea el proveedor. Para Microsoft 365 o Google Workspace, el registro debe publicarse en _smtp._tls.captaindns.com una vez validado. Combine con MTA-STS para forzar el cifrado.

TLS-RPT Validator gratis - Sintaxis offline

Por qué usar un validador offline

Un validador de sintaxis TLS-RPT analiza su registro sin publicar ni consultar DNS. Este enfoque offline cubre tres casos de uso clave que la auditoría en vivo no puede atender.

Casos de uso típicos:

Antes del despliegue → validar un borrador antes de publicar en DNS, para evitar un registro silenciosamente ignorado por los MTA.
Validación de borrador → verificar la sintaxis de un registro copiado desde un generador, una wiki interna o una plantilla compartida.
Depuración offline → reproducir y corregir un error sin tocar el DNS público, por ejemplo en un entorno aislado o pre-producción.
Revisión de configuración → examinar un registro recibido de un socio o exportado de una herramienta de terceros antes de aplicarlo.

El validador aplica la especificación RFC 8460: versión TLSRPTv1, etiqueta rua, formato de endpoints mailto: y https:, autorización cross-domain y ausencia de etiquetas desconocidas. No se realiza ninguna petición DNS. Sus datos permanecen en su navegador.

Cómo usar este validador en 3 pasos

Paso 1: pegar el registro

Copie el valor de su registro TLS-RPT en el campo previsto:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Puede pegar un borrador, un registro existente o la salida de un generador. El validador no efectúa ninguna conexión de red en este paso.

Paso 2: añadir un dominio (opcional)

Indicar un dominio activa la verificación de autorización cross-domain. El validador pasa al modo record_and_domain y analiza cada endpoint externo para verificar que existe un registro TLSRPT de autorización del lado destinatario.

Sin dominio, solo se analiza la sintaxis pura (modo record_only).

Paso 3: analizar el veredicto

Los resultados se clasifican por nivel de gravedad:

Error → problema bloqueante, el registro será ignorado o rechazado por los servidores emisores
Aviso → funcional pero mejora recomendada
Válido → sintaxis conforme RFC 8460

Corrija cada alerta antes de publicar el registro en el DNS público.

Validator o record check: cuándo usar cada herramienta

Las dos herramientas son complementarias. No se sustituyen: intervienen en momentos diferentes del ciclo de vida de un registro TLS-RPT.

Dimensión	Validator (esta herramienta)	Record check
Momento de uso	antes del despliegue	después del despliegue
Lookup DNS	ninguno	resolución `_smtp._tls` en vivo
Fuente del registro	manual (pegado)	DNS público
Verificación cross-domain	opcional (vía domain)	sistemática
Detección del valor publicado	estática	estado real
Datos enviados al servidor	ninguno	dominio analizado

Flujo recomendado:

Diseñe el registro → validator para verificar la sintaxis
Publique el TXT en el DNS → espere la propagación
Record check para confirmar el estado en vivo

El validador detecta errores de captura antes de la publicación. El record check detecta desviaciones y confirma que el registro servido por el DNS corresponde al diseño previsto.

Modos de validación

El validador admite dos modos según los campos rellenados.

Modo record_only

Usted pega únicamente el registro TLS-RPT. Validación pura de sintaxis:

versión TLSRPTv1 exacta, en primera posición
presencia de la etiqueta rua=
formato de endpoints (mailto: o https:)
direcciones email bien formadas en endpoints mailto:
etiquetas desconocidas reportadas como avisos

Ninguna petición de red. Ideal para validar un borrador antes de la publicación.

Modo record_and_domain

Usted pega el registro y un dominio. Además de la validación de sintaxis, el validador realiza una verificación de autorización cross-domain para los endpoints externos:

detecta cada endpoint cuyo dominio difiere del dominio analizado
busca el registro TLSRPT de autorización del lado destinatario
señala los endpoints externos que carecen de autorización

Este modo ayuda a detectar configuraciones en las que usted apunta hacia un proveedor tercero (análisis gestionado de informes) sin que haya publicado la autorización del lado servidor.

Reglas de sintaxis verificadas

El validador aplica las reglas de la RFC 8460 §3 sobre el registro TXT en _smtp._tls.dominio:

Campo	Regla
v	debe ser exactamente `TLSRPTv1` (sensible a mayúsculas), en primera posición
rua	obligatorio, contiene uno o más endpoints separados por `,`
Formato global	pares `clave=valor` separados por `;`
Etiquetas desconocidas	toleradas pero reportadas como avisos
Espacios	tolerados alrededor del `;` y después del `=`

Ejemplo válido:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Formatos de endpoint rua

Cada endpoint en rua= debe usar un esquema reconocido:

Esquema	Formato	Uso
`mailto:`	`mailto:direccion@dominio`	informes recibidos como adjuntos email
`https:`	`https://host/ruta`	informes enviados a un webhook

Varios endpoints son posibles, separados por ,:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt

Cada endpoint recibe los mismos informes agregados (uno cada 24 horas y por emisor).

Endpoints rua: mailto vs https

La elección entre mailto: y https: impacta la complejidad del despliegue y el procesamiento de los informes.

Endpoints mailto

rua=mailto:tls-reports@captaindns.com

Características:

informes recibidos como adjuntos email (JSON comprimido gzip)
configuración simple, sin desarrollo necesario
a menudo una dirección dedicada (tlsrpt@, reports@)
sin autorización cross-domain necesaria si el email está en el mismo dominio que el registro

Endpoints https

rua=https://tlsrpt.captaindns.com/v1/report

Características:

informes enviados por HTTP POST a un webhook
permite procesamiento automatizado en tiempo real
requiere un endpoint HTTPS válido (certificado reconocido)
sin autorización cross-domain necesaria si el host está en el mismo dominio que el registro

Autorización cross-domain

Cuando un endpoint apunta a un dominio diferente del analizado (por ejemplo un colector de informes de terceros), la RFC 8460 §3.3 exige una autorización del lado destinatario:

el destinatario publica un registro TLSRPT en [dominio-fuente]._report._tls.[dominio-destinatario]
sin esta autorización, los servidores emisores no enviarán los informes

El validador señala los endpoints externos que carecen de esta autorización, siempre que haya rellenado el campo dominio.

Ejemplos inválidos

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

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

- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report

Errores de sintaxis comunes y correcciones

Versión ausente o incorrecta

Causa: etiqueta v= faltante, o valor distinto de TLSRPTv1.

Corrección:

- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Etiqueta rua faltante

Causa: el registro contiene v=TLSRPTv1 sin ningún endpoint rua.

Corrección: añada al menos un endpoint:

- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Endpoint mailto inválido

Causa: esquema mailto: olvidado, dirección email mal formada o truncada.

Corrección:

- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Endpoint https inválido

Causa: esquema http: en vez de https:, o URL incompleta.

Corrección: solo los endpoints HTTPS son aceptados por la RFC 8460.

- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report

Cross-domain no autorizado

Causa: un endpoint externo (otro dominio que el analizado) apunta hacia un destinatario que no ha publicado un registro TLSRPT de autorización.

Corrección: solicite al proveedor tercero publicar el registro de autorización, o use un endpoint en su propio dominio:

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

Etiqueta desconocida

Causa: presencia de una etiqueta no definida por la RFC 8460 (por ejemplo ruf=, que no existe en TLS-RPT a diferencia de DMARC).

Corrección: elimine la etiqueta desconocida:

- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

TLS-RPT y MTA-STS: despliegue combinado

TLS-RPT brilla con MTA-STS. Los dos protocolos forman un dúo inseparable para la seguridad del transporte SMTP.

Protocolo	Rol
MTA-STS	aplica el cifrado TLS para el correo entrante
TLS-RPT	reporta fallos y anomalías de conexión TLS

Por qué desplegarlos juntos:

MTA-STS sin TLS-RPT → usted aplica TLS pero no sabe si algunos servidores fallan silenciosamente
TLS-RPT sin MTA-STS → usted recibe informes útiles pero sin refuerzo del cifrado
MTA-STS + TLS-RPT → usted aplica Y mide, con visibilidad completa

Despliegue recomendado:

Valide su política MTA-STS con el MTA-STS Syntax Checker
Valide su registro TLS-RPT con este validator
Publique TLS-RPT primero (para recoger informes desde la fase testing de MTA-STS)
Publique MTA-STS en mode: testing
Supervise los informes TLS-RPT durante 2 a 4 semanas
Pase MTA-STS a mode: enforce una vez resueltos los problemas

Herramientas complementarias y recursos

Herramienta	Cuándo usarla
TLS-RPT record check	auditoría en vivo del registro publicado en DNS
Monitorización TLS-RPT	recibe y analiza automáticamente tus reportes TLS-RPT
TLS-RPT generator	crear un registro TLS-RPT conforme RFC 8460
MTA-STS syntax checker	validar la política MTA-STS asociada offline
DMARC record check	completar la seguridad de autenticación email
Propagación DNS	confirmar la propagación tras la publicación

Guías relacionadas

TLS-RPT: la guía completa para supervisar el cifrado TLS de sus emails - comprender el protocolo y su integración con MTA-STS.
Desplegar TLS-RPT en Microsoft 365, Google Workspace y OVHcloud - procedimiento paso a paso por proveedor.
Analizar los informes TLS-RPT: guía práctica - leer y aprovechar los informes recibidos.

Especificaciones

RFC 8460 - SMTP TLS Reporting (especificación oficial)
RFC 8461 - MTA-STS (protocolo complementario)
Formato del registro TLS-RPT (§3)
Autorización cross-domain (§3.3)