¿Qué es TLS-RPT (informe de TLS)?
El TLS-RPT es el registro que les pide a los proveedores del mundo entero que envíen, todos los días, un informe de lo que funcionó y de lo que falló al entregar correo de forma cifrada en su dominio. No protege nada por sí solo: es el instrumento de medición de la capa de transporte, y es lo que vuelve seguro exigir cifrado obligatorio, porque muestra quién estaba fallando antes de que la exigencia empiece a rechazar mensajes. Definido en el RFC 8460 bajo el nombre SMTP TLS Reporting, publicado en un registro _smtp._tls.
Cómo funciona el TLS-RPT
Quien intenta entregar correo en su dominio es quien ve si el cifrado funcionó. El TLS-RPT es el pedido formal para que esos proveedores del otro lado cuenten lo que vieron.
Usted publica la dirección de destino
Un registro de texto en _smtp._tls.sudominio.com, con el contenido v=TLSRPTv1 y un rua=mailto: seguido de la dirección que recibirá los informes, le dice al mundo adónde mandarlos. El destino también puede ser una dirección web.
Cada proveedor remitente mide sus entregas
Al entregarle, el servidor del remitente registra si logró establecer el canal cifrado, si el certificado validó y si su política fue encontrada y aplicada.
El informe llega una vez por día
Los proveedores agrupan el resultado del día entero y envían un archivo con los conteos de éxito y de falla, el tipo de cada falla y las direcciones involucradas.
Usted lo lee y corrige antes de exigir
Ese contenido es el que dice si se puede subir la política al modo obligatorio sin rechazar remitentes legítimos, y es el que delata un certificado a punto de volverse un problema.
Fuente: RFC 8460, la especificación oficial del informe de TLS del SMTP publicada por el IETF, que define el registro _smtp._tls, el formato del informe y los tipos de falla que nombra, reunidos allí en dos bloques: falla en la negociación del canal y falla de política.
Por qué tanta gente lo publica y nunca lo lee
- El informe está hecho para máquinas, no para personas. El archivo es dato estructurado, normalmente comprimido, y llega a un buzón de correo. Sin una herramienta que lo traduzca a texto legible, se acumula sin que nadie lo lea.
- Leer el informe de TLS suele quedar detrás de una capa paga. El informe de autenticación, del DMARC, tiene servicios gratuitos de sobra que devuelven un resumen legible; en esas mismas plataformas, la lectura del informe de TLS aparece con frecuencia solo en los planes pagos. Existe alternativa gratuita y existe herramienta abierta, pero hay que buscarla, y eso empuja el tema al final de la fila.
- Solo ve a quien lo implementa. Un proveedor que no adoptó el estándar no manda informe, así que el silencio de un origen no prueba que esté entregando bien: prueba solamente que no reporta.
- Mira hacia atrás, no hacia el presente. El informe cierra un día entero en horario UTC y encima sale con algunas horas de retraso deliberado, para no sobrecargar a quien lo recibe. Sirve para diagnóstico y tendencia, y no como alarma en tiempo real de una entrega que acaba de fallar.
Las tres familias de falla que el informe permite distinguir
- Falla de negociación El caso más directo: el servidor del otro lado no ofreció el cambio a canal cifrado. En el informe aparece con el nombre starttls-not-supported, y es la señal de que la entrega siguió, o habría seguido, en texto plano.
- Falla de certificado El canal sí pudo cifrarse, pero la identidad no cerró: el informe separa cada caso por su nombre, certificate-expired para el vencido, certificate-host-mismatch para el emitido con otro nombre y certificate-not-trusted para el de emisor no confiable. Es la familia que más susto genera en la víspera de exigir, y la más fácil de corregir con anticipación.
- Falla de política El remitente no pudo buscar su política de canal obligatorio, o la encontró inválida: son los nombres sts-policy-fetch-error y sts-policy-invalid. El informe distingue aquí los dos caminos de exigencia que el estándar prevé: el que publica la política en un sitio, donde la causa suele ser el certificado o la disponibilidad de ese sitio, y el que la publica en el propio DNS firmado (DANE), donde la causa está en el registro. En ninguno de los dos casos el problema está en el servidor de correo.
- Y la otra cara de la moneda No es una cuarta familia, es el contrapunto de las tres: el informe también cuenta los éxitos. Es ese conteo, y no la ausencia de reclamos, lo que autoriza subir la exigencia: usted pasa a saber cuántas entregas por día ya están ocurriendo de la forma correcta.
Exigir sin medir es apostar
El orden en que entran estas tres piezas es lo que separa un endurecimiento tranquilo de un incidente autoinfligido. Exigir canal cifrado sin informe es decidir a oscuras: usted no sabe qué socios, clientes o sistemas todavía entregan de un modo que la exigencia va a rechazar, y la primera noticia del problema llega por teléfono, con alguien diciendo que el correo rebotó. Con el informe encendido antes, la misma decisión se vuelve contabilidad: durante semanas usted ve quién falla, por qué motivo y en qué volumen, corrige lo que es suyo, avisa a quien hay que avisar, y solo entonces aprieta. Y el perjuicio de esa versión no es técnico: es el pedido que no llegó al cliente, la factura que nadie recibió y el socio que concluyó que su empresa dejó de responder. Es el mismo principio de la autenticación del remitente, donde la política de observación existe para medir antes de bloquear. El instrumento no protege, pero es el que permite proteger sin romper nada.
Cómo sacarle valor al informe de TLS
Publicar el registro es la parte fácil y es donde la mayoría se detiene. El valor está en los cuatro pasos siguientes:
- Apunte el informe a un destino que alguien realmente sigaUn buzón que nadie abre convierte la etapa de medición en espera. Conviene un buzón monitoreado o un servicio que lo reciba y lo procese, nunca el correo personal de quien lo configuró.
- Asegúrese de que alguien puede leer de verdad lo que llegaEl archivo es dato estructurado y comprimido. Antes de publicar, decida cómo se va a transformar en algo legible, sea con una herramienta o con un proceso interno. Sin eso, el registro es decorativo.
- Mire primero la familia de certificadoEs la que más aparece y la que más frena entregas cuando la exigencia entra en vigor. Un certificado por vencer, o con un nombre que no coincide, es un problema conocido y con fecha.
- Use el conteo de éxitos para decidir cuándo exigirLa pregunta no es si aparecieron fallas, es si las que quedan vienen de orígenes que usted reconoce y acepta perder. Cuando ya no haya sorpresas, el modo obligatorio deja de ser riesgo.
- Mantenga el informe encendido después de exigirDeja de ser preparación y se vuelve monitoreo: los certificados vencen, los servidores cambian, los socios reconfiguran. El informe es el que avisa antes que el cliente.
En la práctica
El informe de TLS es el instrumento de vuelo de la entrega de correo: no hace volar al avión, pero volar sin él a oscuras es lo que lo derriba. Publicar la exigencia de canal cifrado antes de tener el informe funcionando es exactamente ese vuelo a ciegas, y el costo aparece en la forma más cara posible, que es el mensaje legítimo que deja de llegar sin que nadie sepa por qué.
Cómo Zamak trata el informe de TLS
Zamak Technologies enciende el informe antes de cualquier exigencia, apunta el destino a donde de hecho se lee y usa el conteo de éxitos y fallas para decidir cuándo el modo obligatorio deja de ser riesgo, junto al equipo que ya administra el entorno. El STARTTLS explica por qué la medición es necesaria y el MTA-STS es la exigencia que ella vuelve segura. La verificación de suplantación de correo da el retrato inicial de lo que su dominio publica hoy. Ese seguimiento forma parte de la Seguridad de Correo Gestionada y de la Ciberseguridad gestionada del Método Zamak.