← RFC Reference

RFC 8460: Informe TLS de SMTP (TLSRPT)

Por Qué Existe

Dos estándares obligan TLS para correo servidor a servidor: MTA-STS (RFC 8461) y DANE (RFC 7672). Ambos le dicen a los servidores remitentes "debes establecer una conexión TLS válida antes de entregar correo a este dominio." Pero cuando falla la negociación TLS, el servidor remitente retrocede a texto sin cifrar (malo) o rechaza la entrega (correo perdido). De cualquier forma, el dominio receptor no sabe que hay un problema.

TLSRPT cierra esta brecha de visibilidad. Los propietarios de dominios publican un registro DNS solicitando reportes TLS, y los MTA remitentes agregan sus resultados de conexión TLS en reportes JSON diarios entregados por correo electrónico o HTTPS.

Sin TLSRPT, podrías implementar MTA-STS con un error de certificado sin darte cuenta de que un porcentaje significativo del correo entrante se está rechazando o entregando de forma insegura.

Cómo Funciona

Paso 1: Publica un Registro DNS de TLSRPT

Añade un registro TXT en _smtp._tls.tudominio.com especificando dónde deben enviarse los reportes:

Paso 2: Servidores Remitentes Recopilan Datos

Cuando un MTA remitente entrega correo a tu dominio, registra el resultado de la negociación TLS: sesión exitosa con certificado válido, fallo de protocolo de enlace, desajuste de certificado, fallo de política MTA-STS, fallo de validación DANE, etc.

Paso 3: Entrega de Reporte Diario

Una vez al día, el MTA remitente agrega sus resultados y envía un reporte JSON. Cuando se entrega por correo electrónico, llega como un mensaje multipart/report con report-type=tlsrpt:

Content-Type: multipart/report; report-type=tlsrpt;
    boundary="TLSRPT-001"

--TLSRPT-001
Content-Type: text/plain

SMTP TLS report for example.com
Report period: 2026-03-10T00:00:00Z to 2026-03-11T00:00:00Z

--TLSRPT-001
Content-Type: application/tlsrpt+json

{
  "organization-name": "Sender Corp",
  "date-range": {
    "start-datetime": "2026-03-10T00:00:00Z",
    "end-datetime": "2026-03-11T00:00:00Z"
  },
  "contact-info": "postmaster@sendercorp.com",
  "report-id": "2026-03-10-example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce",
        "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 9450,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12
    }]
  }]
}

--TLSRPT-001--

Detalles Técnicos Clave

Formato de Registro DNS

Tipos de Resultados de Fallo

Tipos de Política

Errores Comunes

• Publicar MTA-STS sin TLSRPT. MTA-STS en modo enforce hará que los servidores remitentes rechacen correo cuando falle TLS. Sin TLSRPT, no tienes visibilidad en esos fallos. Siempre implementa ambos juntos.
• Ignorar los reportes. Recibir reportes TLSRPT solo es útil si realmente los analizas y monitoreas. Configura procesamiento automatizado o usa un servicio que agregue y alerte sobre fallos.
• Usar solo entrega HTTPS. Aunque HTTPS POST es más limpio para procesamiento automatizado, algunos MTA remitentes solo soportan entrega por correo electrónico. Proporciona tanto una URI mailto: como https: si es posible.
• Ubicación incorrecta del registro DNS. El registro debe estar en _smtp._tls.tudominio.com, no en _tls.tudominio.com o _tlsrpt.tudominio.com. El prefijo es específicamente _smtp._tls.
• Dejar que los certificados expiren. El fallo más común reportado vía TLSRPT es certificate-expired. Automatiza la renovación de certificados (por ejemplo, con Let's Encrypt) y monitorea fechas de vencimiento.
• No verificar nombre de host MX vs. certificado. Tu certificado TLS debe cubrir los nombres de host listados en tu política MTA-STS y registros MX. Si tu MX es mail.example.com pero tu certificado es para example.com, los remitentes reportarán certificate-host-mismatch.

Impacto en Entregabilidad

• Visibilidad en fallos TLS. Sin TLSRPT, los fallos de negociación TLS son invisibles. No sabes que el correo de un remitente importante se está rechazando porque tu certificado expiró la semana pasada.
• Requisito previo para cumplimiento seguro de MTA-STS. La ruta recomendada de implementación es: publicar MTA-STS en modo testing, habilitar TLSRPT, monitorear reportes de fallos, corregir problemas, luego cambiar a enforce. Saltarse el paso de monitoreo arriesga pérdida de correo.
• Detectar ataques de intermediario. Un aumento repentino en certificate-not-trusted o starttls-not-supported desde una red específica podría indicar un ataque de eliminación STARTTLS. TLSRPT lo hace visible.
• Evidencia de cumplimiento. Para dominios que manejan comunicaciones sensibles, los reportes TLSRPT proporcionan evidencia de que TLS se está negociando exitosamente para la gran mayoría de conexiones entrantes.

Related RFCs