TLS-RPT Generator

Cómo usar este generador TLS-RPT

Paso 1: Agregar los destinos de los informes

Indica dónde quieres recibir los informes de fallos TLS:

Email (recomendado para empezar)

mailto:tlsrpt@captaindns.com

Webhook HTTPS (para automatización)

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

Puedes agregar varios destinos: los informes se envían a todos.

Paso 2: Copiar el registro generado

El generador crea un registro RFC 8460 válido:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Paso 3: Publicar en el DNS

Crea un registro TXT en _smtp._tls.captaindns.com con el valor generado.

Ejemplo para captaindns.com:

• Tipo: TXT
• Host: _smtp._tls
• Valor: v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Paso 4: Verificar la publicación

Usa nuestro TLS-RPT Checker para confirmar que la configuración es correcta.

Qué reporta TLS-RPT en realidad

TLS-RPT es una herramienta de observabilidad pura: nunca modifica el comportamiento de un servidor; revela lo que realmente ocurrió durante las conexiones TLS entrantes hacia tus MX.

Los operadores emisores te señalan, entre otras cosas:

• un downgrade o un stripping de STARTTLS, donde la sesión cae a texto plano
• un certificado caducado, no confiable o autofirmado
• un certificado cuyo hostname no coincide con el MX esperado
• el fallo al recuperar o validar una política MTA-STS
• un fallo DANE: registro TLSA inválido o cadena DNSSEC rota

TLS-RPT no aplica ninguna regla. El rechazo a entregar un mensaje en texto plano proviene de MTA-STS o de DANE; TLS-RPT se limita a indicarte cuándo y por qué falló el cifrado, para que puedas corregirlo antes de pasar a enforce.

Formato del registro TLS-RPT

Componentes requeridos

Esquemas de URI soportados

mailto: - Entrega por email

rua=mailto:equipo-seguridad@captaindns.com

Los informes llegan como archivos adjuntos JSON comprimidos.

https: - Entrega webhook

rua=https://api.captaindns.com/tlsrpt/ingest

Los informes se envían por POST, en formato JSON, con la cabecera Content-Type: application/tlsrpt+gzip

Varios destinos

Sepáralos con comas:

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

Enviar los informes a un dominio externo

Un rua que apunta a un dominio distinto del tuyo funciona tal cual, sin ningún registro de autorización del lado destinatario.

Es una diferencia importante con DMARC. DMARC exige un registro _report._dmarc en el dominio externo antes de aceptar informes cross-domain. La RFC 8460 descartó deliberadamente este mecanismo (sección 7): el riesgo de amplificación con TLS-RPT es menor que con DMARC, y la confianza se garantiza de otra forma. Los informes mailto: van firmados con DKIM por el operador emisor, y los informes https: se apoyan en la posesión del DNS y del certificado del endpoint.

v=TLSRPTv1; rua=mailto:reports@tlsrpt-service.com

No se requiere ninguna acción en tlsrpt-service.com para que este rua sea válido.

Para mantenerlo simple, una dirección en tu propio dominio basta en la mayoría de los casos:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Ejemplos por proveedor DNS

Cloudflare

1. Ve a la configuración DNS de tu dominio
2. Agrega un registro:
   • Tipo: TXT
   • Nombre: _smtp._tls
   • Contenido: tu valor de registro generado
   • TTL: Auto

AWS Route 53

1. Abre la zona alojada de tu dominio
2. Crea un registro:
   • Nombre del registro: _smtp._tls
   • Tipo de registro: TXT
   • Valor: "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL: 3600

OVH / Google Domains

1. Ve a la zona DNS
2. Agrega una entrada:
   • Subdominio: _smtp._tls
   • Tipo: TXT
   • Destino: tu valor de registro generado
   • TTL: 3600

Entender los informes TLS-RPT

Un informe TLS-RPT es un documento JSON agregado, comprimido en gzip, que resume las sesiones TLS de un operador hacia tu dominio a lo largo de un día.

Anatomía de un informe

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "contact-info": "postmaster@google.com",
  "report-id": "2024011512345",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.captaindns.com", "max_age: 604800"],
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 8432,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.captaindns.com",
      "failed-session-count": 3
    }]
  }]
}

Los tipos de fallo (result-type)

El registro IANA define 11 valores posibles para result-type:

Los tipos de política (policy-type)

Cada sesión se vincula a uno de los 3 policy-type:

Transporte y cadencia

Todos los informes van comprimidos en gzip. Existen dos canales de entrega, según el esquema de tu rua:

• HTTPS: el informe se envía por POST con la cabecera Content-Type: application/tlsrpt+gzip (o application/tlsrpt+json). El endpoint confirma la recepción con un estado 2xx.
• Email: el mensaje es un multipart/report; report-type="tlsrpt" con un adjunto application/tlsrpt+gzip. Lleva las cabeceras TLS-Report-Domain y TLS-Report-Submitter, un asunto con la forma Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345, y va firmado con DKIM con el selector s=tlsrpt.

Cadencia: cada operador emisor envía un informe agregado por día, cubriendo la ventana de 00:00 a 24:00 UTC. Si la entrega falla, reintenta hasta 24 horas.

Quién envía los informes

Los grandes operadores emiten informes TLS-RPT: Google, Microsoft y Yahoo lo hacen de forma sistemática; Apple y Comcast también figuran entre ellos. Cada operador produce su propio informe independiente, así que puedes recibir varios al día, uno por emisor.

TLS-RPT con MTA-STS y DANE

TLS-RPT es el bucle de observabilidad de MTA-STS y de DANE. Estos protocolos aplican el cifrado; TLS-RPT te muestra el efecto de esa aplicación, tanto antes como después del paso a producción.

Orden de despliegue recomendado

1. Publicar TLS-RPT, y MTA-STS en mode: testing
2. Analizar los informes durante 2 a 4 semanas
3. Pasar MTA-STS a mode: enforce
4. Mantener la vigilancia con TLS-RPT

Pasar a enforce sin TLS-RPT es avanzar a ciegas: si una política rompe la entregabilidad, solo lo sabrás por las quejas de los usuarios.

Herramientas relacionadas

• Generar una política MTA-STS
• Verificar el estado MTA-STS
• Verificar el estado TLS-RPT
• Verificar los registros DANE TLSA

Buenas prácticas y errores comunes

Buenas prácticas

• Apunta el rua hacia un buzón o un endpoint dedicado, capaz de absorber el volumen y de parsear el JSON. Nunca un buzón humano: los informes llegan cada día, en JSON gzip, desde cada operador.
• Usa una herramienta de agregación para convertir esos informes en tendencias accionables en vez de abrirlos uno a uno.

Errores a evitar

• Dos registros TXT en _smtp._tls invalidan la configuración. Mantén un único registro con un único valor.
• Codifica en porcentaje los caracteres ,, ! y ; cuando aparezcan en una URI (por ejemplo en un mailto: con parámetros), de lo contrario el parsing del registro se rompe.

Casos de uso concretos

Cada escenario a continuación se traduce en un result-type preciso en tus informes:

• Un MX de respaldo que nunca se configuró para TLS: starttls-not-supported. Lo detectas antes de que un atacante lo aproveche.
• El certificado de un socio ha caducado: certificate-expired en las sesiones afectadas.
• Un MX presenta un certificado emitido para el hostname equivocado: certificate-host-mismatch.
• Un downgrade activo de STARTTLS (ataque en la red) hace caer las sesiones cifradas: pico de starttls-not-supported.
• Tu propia política MTA-STS está rota o inaccesible: sts-policy-fetch-error o sts-policy-invalid, antes de que bloquee correo legítimo.
• Un DANE mal configurado: tlsa-invalid (TLSA que ya no coincide tras una rotación de certificado) o dnssec-invalid (cadena DNSSEC rota).

Herramientas complementarias

Recursos útiles

• RFC 8460 - SMTP TLS Reporting (especificación oficial)
• RFC 8461 - MTA-STS (protocolo complementario)
• Google - Configurar TLS reporting
• Postfix - Documentación TLS