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

El validator analiza una sintaxis que pegas, antes de publicar en DNS, sin leer la configuración que ya está activa. El record check consulta el DNS en vivo para inspeccionar el registro publicado en _smtp._tls.dominio. Usa 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: no recibes ningún informe y solo lo descubres cuando ocurre un incidente. La validación offline detecta los problemas antes de que afecten a tu 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 de la URI, dirección email mal formada, y etiqueta desconocida heredada de DMARC como ruf= que no existe en TLS-RPT.

¿Hace falta autorización para enviar los informes a otro dominio?

No. A diferencia de DMARC, TLS-RPT no exige ningún registro de autorización del lado destinatario para una rua externa: la RFC 8460 descartó ese mecanismo. Una URI que apunta a un servicio de terceros es válida tal cual, y el validador nunca rechaza un registro por culpa de una rua externa.

¿Qué diferencia hay entre URIs mailto y https?

Las URIs mailto reciben los informes como adjuntos email (JSON comprimido gzip). Las URIs 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. Verifica 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 te informa cuando la aplicación falla. Sin TLS-RPT, no sabrás si servidores externos no logran conectarse en TLS a tu dominio.

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

Pega tu 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. Combina 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 tu registro sin publicar ni consultar DNS. Este enfoque offline cubre cuatro 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 depender del DNS público, por ejemplo sobre un registro de preproducción que todavía no está publicado.
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 sobre la sintaxis: versión TLSRPTv1, etiqueta rua, formato de las URIs mailto: y https:, y ausencia de etiquetas desconocidas. La validación se ejecuta en nuestros servidores: el registro que pegas se envía a CaptainDNS para analizarlo. Eso sí, no se publica nada, no se emite ninguna consulta DNS y no se contacta con ninguna URI rua.

Cómo usar este validador en 2 pasos

Paso 1: pegar el registro

Copia el valor de tu registro TLS-RPT en el campo previsto:

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

Puedes pegar un borrador, un registro existente o la salida de un generador. El validador no lee ninguna fuente externa: solo analiza el texto que le facilitas.

Paso 2: 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

Corrige 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
Identificación de URIs externas	ninguna	automática
Detección del valor publicado	estática	estado real
Datos enviados al servidor	el registro pegado	dominio analizado

Flujo recomendado:

Diseña el registro → validator para verificar la sintaxis
Publica el TXT en el DNS → espera 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.

Un solo campo, un solo modo

El formulario tiene una única casilla: el propio registro TLS-RPT. Ni dominio, ni segundo modo. Esto es lo que se comprueba:

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

Esa sobriedad viene de la RFC 8460. DMARC reclama un registro de autorización _report._dmarc en el destinatario en cuanto los informes salen hacia otro dominio; el §7 de la RFC 8460 descartó deliberadamente ese mecanismo para TLS-RPT. No hay entonces nada con lo que contrastar tus URIs rua: una dirección en un proveedor tercero de recogida de informes vale tal cual.

Para saber cuáles de tus URIs ya publicadas salen de tu dominio, el record check las localiza a partir del dominio consultado.

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 una o más URIs separadas 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

Formato de las URIs rua

Cada URI 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

Varias URIs son posibles, separadas por ,:

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

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

URIs rua: mailto vs https

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

URIs 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@)
ninguna autorización del lado destinatario necesaria, incluso para una dirección en un dominio distinto al del registro

URIs 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)
ninguna autorización del lado destinatario necesaria, incluso para un host en un dominio distinto al del registro

URIs externas (rua hacia otro dominio)

Cuando una URI apunta a un dominio diferente del analizado (por ejemplo un colector de informes de terceros), TLS-RPT no exige ninguna autorización del lado destinatario:

A diferencia de DMARC y su registro _report._dmarc, la RFC 8460 no define ningún mecanismo de verificación: su §7 descartó deliberadamente cualquier autorización cross-domain
Una URI externa es, por tanto, válida tal cual; los servidores emisores envían los informes sin control previo del lado destinatario

El validador nunca las rechaza. Tampoco las distingue del resto: sin dominio de referencia, no tiene con qué compararlas.

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 ninguna URI rua.

Corrección: añade al menos una URI:

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

URI mailto inválida

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

URI https inválida

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

URI externa: no es un error

A tener en cuenta: una URI rua que apunta a otro dominio (servicio tercero de recogida) es perfectamente válida. A diferencia de DMARC, TLS-RPT no impone ningún registro de autorización del lado destinatario: el validador nunca rechaza un registro a causa de una rua externa.

Puedes, por tanto, apuntar con total confianza hacia un proveedor tercero:

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

Etiqueta desconocida

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

Corrección: elimina 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 cobra todo su sentido 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 → aplicas TLS pero no sabes si algunos servidores fallan silenciosamente
TLS-RPT sin MTA-STS → recibes informes útiles pero sin refuerzo del cifrado
MTA-STS + TLS-RPT → aplicas y mides, con visibilidad completa

Despliegue recomendado:

Valida tu política MTA-STS con el MTA-STS Syntax Checker
Valida tu registro TLS-RPT con este validator
Publica TLS-RPT primero (para recoger informes desde la fase testing de MTA-STS)
Publica MTA-STS en mode: testing
Supervisa los informes TLS-RPT durante 2 a 4 semanas
Pasa 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 informes 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 tus 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)
Consideraciones de seguridad - rua externa (§7)