TLS-RPT para correo: Obtén visibilidad de fallos TLS (y arréglalos)

Qué es realmente TLS-RPT (y qué no es)

TLS-RPT (Transport Layer Security Reporting) es un estándar que permite a remitentes de correo informar a un propietario de dominio cuando tuvieron problemas al entregar correo a ese dominio mediante TLS.
La frase clave es “cuando tuvieron problemas”: es reporte de fallos, no una funcionalidad de seguridad por sí misma.

Publicas un registro DNS indicando al mundo dónde enviar los informes. Luego, grandes remitentes (y cualquier remitente que lo soporte) te enviarán informes periódicos (normalmente diarios) en formato JSON.
Esos informes describen intentos de entrega a tus hosts MX y por qué TLS no funcionó como se esperaba.

Qué no es

• No es imposición de cifrado. TLS-RPT no obliga a nadie a usar TLS. Eso lo hacen MTA-STS (basado en políticas) o DANE (basado en DNSSEC).
• No protege el contenido del mensaje. Trata del salto de transporte SMTP, no del cifrado de extremo a extremo como S/MIME o PGP.
• No es instantáneo. La mayoría de los informes se entregan por lotes. Obtienes señal, pero no un evento de pager en vivo.

Piensa en TLS-RPT como detectores de humo: no evitan incendios, pero te dicen dónde está el humo.

Por qué te debería importar (incluso si “ya tienes TLS”)

“Usamos STARTTLS” es el equivalente en correo de “tenemos copias de seguridad”. Bien. Ahora muéstrame una prueba de restauración.
STARTTLS es oportunista por defecto: si TLS falla, muchos remitentes volverán al texto plano a menos que la política diga lo contrario.
Sin telemetría, puedes ser degradado y no enterarte. O puedes romper la entrega entrante para un subconjunto de remitentes y descubrirlo solo cuando alguien no reciba un correo importante.

TLS-RPT te da:

• Visibilidad de fallos reales en todo el ecosistema: problemas de certificados, desajustes de nombre, versiones de protocolo, problemas de cifrado, rarezas en el banner SMTP, tiempos de espera de red y desajustes de política.
• Pruebas para depurar con terceros: “Tus informes muestran que fallas la validación contra mx2; aquí está el tipo de fallo y la ventana de tiempo.”
• Advertencia temprana cuando alguien cambia algo: un nuevo balanceador, una nueva cadena de certificados, un intermedio roto, un cambio DNS, una regla de firewall.
• Detección de seguridad para patrones de degradación o interceptación: si muchos remitentes repentinamente reportan fallos que antes no existían, algo está en el camino.

Broma #1: El correo es el sistema distribuido más antiguo que muchas empresas mantienen. Envejece como el vino—si el vino de vez en cuando no se prende fuego.

Hechos y pequeña historia que importan en producción

Puntos breves y concretos que cambian cómo operas esto:

1. SMTP precede al cifrado ubicuo por décadas. STARTTLS se añadió después, por eso “TLS oportunista” es una norma cultural por defecto.
2. TLS-RPT se estandarizó en 2018 (RFC 8460), en gran parte para hacer viable operativamente a MTA-STS a escala de Internet.
3. MTA-STS llegó porque la degradación de STARTTLS era real en la práctica: atacantes podían eliminar el anuncio STARTTLS o inducir fallos para forzar texto plano.
4. DANE existía antes (registros TLSA con DNSSEC), pero la adopción es desigual porque el despliegue de DNSSEC y la comodidad operativa varían mucho entre organizaciones.
5. Los grandes proveedores impulsaron la adopción de formatos de reporte porque necesitaban señales de bajo fricción a alto volumen, no tickets hechos a mano.
6. Los informes tratan sobre intentos de entrega, no sobre tus logs de MTA. Eso significa que capturan fallos que nunca alcanzaron tu infraestructura (por ejemplo, bloqueos de red o errores de negociación TLS antes de SMTP DATA).
7. Los informes se agregan: verás totales y tipos de fallo, no detalles forenses por mensaje. Esto es una característica, no un bug.
8. Los informes pueden revelar deriva del ecosistema: versiones antiguas de TLS y cifrados heredados siguen apareciendo en la cola larga, especialmente con appliances y MTAs antiguos.

Cómo funciona TLS-RPT de extremo a extremo

Las piezas en movimiento

• Tu dominio: publica un registro TLS-RPT en _smtp._tls.
• Remitentes: MTAs que intentan entregar a tus hosts MX. Si soportan TLS-RPT, recogen telemetría de fallos.
• Tu receptor de informes: una dirección de correo (o endpoint HTTPS) que recibe informes JSON, a menudo comprimidos y adjuntos.
• Política de aplicación opcional: política MTA-STS (_mta-sts + archivo de política HTTPS) o registros TLSA de DANE. TLS-RPT se vuelve mucho más útil cuando algo se aplica.

El ciclo de vida

1. Publicas _smtp._tls.example.com TXT con un registro v=TLSRPTv1 apuntando a dónde deben ir los informes.
2. Un remitente intenta entregar a example.com, negocia STARTTLS y verifica las políticas que respeta (MTA-STS, DANE, reglas locales).
3. Si el remitente no puede establecer TLS cuando corresponde, o si falla una validación de política (por ejemplo, desajuste de certificado frente a expectativas de MTA-STS), registra el evento.
4. Periódicamente, el remitente te envía un informe describiendo recuentos de éxitos/ fallos y razones de fallo, agrupados por destino y tipos de resultado.
5. Lo ingieres en algo buscable (incluso si es “un buzón más un script”). Luego decides: arreglar tu configuración, arreglar tu DNS, arreglar tu cadena de certificados, o abrir un ticket con el equipo de red/seguridad.

Por qué esto es oro operativo

Los fallos SMTP a menudo son asimétricos. Tus logs pueden no mostrar nada porque la conexión nunca llegó a ti, o murió antes de que tu MTA escribiera una entrada significativa.
TLS-RPT te da la perspectiva del remitente. En sistemas distribuidos, esa es la mitad de la verdad que usualmente te falta.

Cita (idea parafraseada): Werner Vogels, sobre operaciones, enfatiza construir sistemas que “abracen el fallo” y lo hagan observable.
TLS-RPT es esa filosofía aplicada al transporte de correo.

Registros DNS que publicarás (con valores sensatos)

Fundamentos del registro TXT TLS-RPT

El registro vive en _smtp._tls.<domain>. Es un registro TXT cuyo valor comienza con v=TLSRPTv1 e incluye una o más URIs de informe mediante rua=.
Comúnmente se usa mailto: porque es fácil e interoperable.

Registros de ejemplo

Mailto mínimo:

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Varios destinatarios (útil durante el despliegue):

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,mailto:mailops@example.net"

Endpoint HTTPS (más difícil de operar correctamente, pero automatizable):

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=https://tlsrpt-api.example.com/v1/report"

Opiniones ganadas con experiencia

• Empieza con mailto a menos que tengas una razón fuerte para no hacerlo. Los endpoints HTTPS necesitan decisiones de autenticación, limitación de tasa, almacenamiento y revisión de seguridad. Mailto necesita un buzón y buena higiene.
• Usa un alias dedicado como tlsrpt@ que vaya a un sistema de tickets o a un buzón monitorizado, no al correo personal de alguien.
• No publiques TLS-RPT sin al menos higiene TLS básica. Recibirás informes, pero serán ruido hasta que arregles problemas obvios (cadenas malas, nombres incorrectos, protocolos antiguos).

Qué contienen los informes y cómo leerlos

Los informes TLS-RPT son documentos JSON que describen:

• Metadatos del informe: nombre de la organización que reporta, rango de fechas del informe.
• Políticas evaluadas: cosas como “no-policy-found” o “sts” con detalles.
• Resultados: recuentos de éxitos y fallos, además de tipos de fallo como fallo de negociación TLS, fallo de validación de certificado o desajuste de política.
• Endpoints: hosts MX de destino e IPs a los que el remitente intentó conectarse.

Qué deberías mirar primero

1. Detección de picos: ¿aumentaron los fallos respecto al día anterior?
2. Concentración: ¿es un solo host MX, una sola IP, una región, un remitente?
3. Clase de fallo: ¿handshake/protocolo frente a certificado/PKI frente a política?
4. Consistencia: ¿coinciden varios reportantes? Un remitente fallando puede ser un bug suyo. Muchos fallando suele ser problema tuyo (o de la red entre ambos).

Interpretando temas comunes de fallo

• Desajuste de nombre de certificado: tu nombre MX no coincide con el certificado, o estás presentando el certificado equivocado en un nodo.
• CA desconocida / cadena no confiable: intermediarios faltantes o una cadena empresarial presentada por accidente.
• Alertas de versión TLS: algunos remitentes no usarán versiones antiguas de TLS; otros no pueden usar configuraciones solo nuevas.
• Desajustes de política: MTA-STS dice “enforce”, pero tu servidor no cumple los requisitos.
• Fallos de conexión: firewall, enrutamiento, fallos grises o comprobaciones de salud de balanceador que mienten.

Broma #2: Depurar TLS es como la arqueología. Retiras capas hasta encontrar un error perfectamente preservado de hace tres años.

Guía de diagnóstico rápido

Cuando veas fallos TLS-RPT, resiste la tentación de empezar a cambiar suites de cifrado como si sacudieras una máquina expendedora.
Triaguea primero. Arregla después.

Primero: delimita el radio de impacto

• ¿Es un destino MX o todos?
• ¿Es una sola organización remitente o muchas?
• ¿Es una IP detrás de un balanceador?
• ¿Empezó después de un despliegue, rotación de certificados, cambio DNS o cambio de firewall?

Segundo: clasifica el fallo

• Fallas de handshake: versión de protocolo, desajuste de cifrado, STARTTLS eliminado, tiempos de espera.
• Fallas PKI: cadena, expiración, desajuste de hostname, comportamiento de revocación.
• Fallas de política: desajuste MTA-STS, desajuste DANE, “sin política” cuando esperabas una.
• Fallas de red: accesibilidad TCP/25, enrutamiento asimétrico, NAT hairpin, interferencia IDS.

Tercero: reproduce desde afuera

• Prueba STARTTLS con openssl s_client contra cada host MX y cada IP.
• Verifica la resolución DNS y el orden MX desde múltiples resolvers.
• Comprueba qué certificado se presenta realmente por nodo (a los balanceadores les encantan los despliegues parciales).
• Si MTA-STS está involucrado, confirma la accesibilidad y corrección del archivo de política.

Cuarto: decide qué cambiar

• Si no puedes reproducir externamente, sospecha una diferencia de política o validación en el remitente.
• Si solo es una IP, drénala y arregla la deriva de configuración.
• Si es relacionado con la cadena, arregla la cadena servida antes de rotar el certificado leaf otra vez (rotar el leaf no arreglará intermediarios faltantes).
• Si son tiempos de espera, revisa timers de firewall y del balanceador para idle/handshake.

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando TLS-RPT empieza a sonar. Cada una incluye: comando, qué significa la salida y la decisión que tomas.
Asume herramientas Linux y un mundo Postfix-ish típico; adapta según sea necesario.

Task 1: Confirmar que el registro TLS-RPT existe y es exactamente lo que crees

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Qué significa: Los remitentes saben dónde enviar informes y tu registro se parsea.

Decisión: Si falta o está mal formado, arregla primero el DNS. Sin registro, no hay informes, no hay visibilidad.

Task 2: Revisar registros MX y detectar split-horizon o cambios obsoletos

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Qué significa: Los destinos de entrega son predecibles y están ordenados.

Decisión: Si aparece un MX inesperado, o cambiaron prioridades, reconcilia con tu diseño previsto y tus suposiciones de política TLS.

Task 3: Resolver cada MX a todos los A/AAAA (la deriva multi-IP es común)

cr0x@server:~$ dig +short A mx1.example.com
203.0.113.10
203.0.113.11

Qué significa: Tienes múltiples frontends detrás de un nombre MX.

Decisión: Prueba TLS contra cada IP. Un nodo malo puede envenenar tu reputación y tu entrega.

Task 4: Validar accesibilidad TCP/25 desde donde estás

cr0x@server:~$ nc -vz mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!

Qué significa: La conectividad básica existe desde este punto de vista.

Decisión: Si esto falla, deja de culpar a TLS. Tienes un problema de enrutamiento/firewall/proveedor o estás probando desde una red que bloquea el 25 saliente.

Task 5: Hablar SMTP y verificar que STARTTLS se anuncia

cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -w 3 mx1.example.com 25
220 mx1.example.com ESMTP
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
221 Bye

Qué significa: El servidor ofrece STARTTLS, así que TLS oportunista es posible.

Decisión: Si STARTTLS falta inesperadamente, revisa la configuración del MTA, ajustes de offload TLS y cualquier proxy SMTP delante.

Task 6: Realizar un handshake STARTTLS e inspeccionar el certificado presentado

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 

CONNECTED(00000003)
depth=2 C=US, O=Example Root CA, CN=Example Root CA G2
verify return:1
depth=1 C=US, O=Example Issuing CA, CN=Example Issuing CA R3
verify return:1
depth=0 CN=mx1.example.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
---
250 2.0.0 Ready to start TLS

Qué significa: TLS negocia, la cadena verifica, SNI funciona y tu endpoint sirve el certificado esperado.

Decisión: Si la verificación falla (CA desconocida, emisor local no encontrado, desajuste de hostname), arregla la cadena servida y la selección de certificado en ese nodo o en el balanceador.

Task 7: Revisar las fechas de validez del certificado (evitar expiraciones “sorpresa”)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 2>/dev/null | openssl x509 -noout -dates -subject
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
subject=CN = mx1.example.com

Qué significa: El certificado es actualmente válido y tiene una fecha de expiración clara.

Decisión: Si la expiración está cerca, planifica la rotación con antelación. TLS-RPT te dirá del fallo después del hecho; lo que quieres es prevenirlo.

Task 8: Confirmar la cadena completa de certificados servida (falta de intermedio es clásico)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++} {print > ("cert" i ".pem")}'

cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer < "$f"; done
== cert1.pem ==
subject=CN = mx1.example.com
issuer=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
== cert2.pem ==
subject=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
issuer=C=US, O=Example Root CA, CN=Example Root CA G2

Qué significa: Estás sirviendo al menos leaf + intermedio. Bien.

Decisión: Si solo ves el leaf, arregla el MTA o el terminador TLS para servir la cadena. Muchos remitentes no buscarán intermediarios de forma fiable.

Task 9: Verificar qué cifrados/protocolos soporta tu endpoint SMTP (y si cortas remitentes heredados)

cr0x@server:~$ nmap --script ssl-enum-ciphers -p 25 mx1.example.com
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-03 10:11 UTC
Nmap scan report for mx1.example.com (203.0.113.10)
PORT   STATE SERVICE
25/tcp open  smtp
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLSv1.3:
|     ciphers:
|       TLS_AES_256_GCM_SHA384 - A
|_  least strength: A

Qué significa: Soportas TLS moderno. Buena postura de seguridad.

Decisión: Si tu negocio requiere interoperabilidad heredada, considera si quitar TLSv1.0/1.1 causó fallos reales de entrega. Usa TLS-RPT para cuantificar antes de aflojar.

Task 10: En Postfix, confirmar que los ajustes TLS en tiempo de ejecución son los que pretendías

cr0x@server:~$ postconf -n | egrep '(^smtpd_tls_|^smtp_tls_|^smtpd_tls_security_level|^smtp_tls_security_level)'
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_loglevel = 1

Qué significa: TLS entrante se ofrece (may), las rutas de certificado están establecidas y los protocolos antiguos están deshabilitados.

Decisión: Si smtpd_tls_cert_file apunta al archivo equivocado en un host, tendrás fallos TLS-RPT concentrados en esa IP. Arregla la deriva; no discutas con las matemáticas.

Task 11: Revisar logs de correo en busca de errores de handshake TLS en el servidor

cr0x@server:~$ sudo grep -E 'TLS|STARTTLS|SSL_accept|handshake' /var/log/maillog | tail -n 10
Jan 03 10:01:44 mx1 postfix/smtpd[22131]: Anonymous TLS connection established from mail-oi1-f180.google.com[209.85.167.180]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
Jan 03 10:02:09 mx1 postfix/smtpd[22155]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading

Qué significa: Tienes al menos una anormalidad de handshake. “Unexpected EOF” a menudo indica middleboxes o clientes abortando.

Decisión: Si TLS-RPT muestra muchos fallos de múltiples remitentes y ves errores de handshake del lado del servidor, investiga dispositivos de red (firewalls/IDS) y límites de tasa.

Task 12: Confirmar qué archivo de certificado está usando realmente tu terminador TLS (estilo Nginx/HAProxy)

cr0x@server:~$ sudo haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid

Qué significa: Al menos el config se parsea. Eso es el piso, no el techo.

Decisión: Si TLS-RPT apunta a un desajuste de certificado, verifica las rutas de archivo crt por frontend y el comportamiento de reload. Recargas parciales crean caos de “algunos clientes fallan”.

Task 13: Validar la presencia DNS de MTA-STS (si afirmas aplicar TLS)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T001"

Qué significa: Has publicado un id de versión de política MTA-STS.

Decisión: Si TLS-RPT dice “no policy found” pero esperabas enforcement, tu registro DNS falta, está mal o no es visible públicamente.

Task 14: Comprobar que el archivo de política MTA-STS es accesible y correcto

cr0x@server:~$ curl -sS -D- https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,25p'
HTTP/2 200
content-type: text/plain
content-length: 128

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

Qué significa: La política es accesible por HTTPS y nombra tus hosts MX.

Decisión: Si esto devuelve 404, redirige extrañamente o lista nombres MX incorrectos, arréglalo inmediatamente. De lo contrario, los remitentes que aplican MTA-STS te tratarán como “TLS requerido pero no satisfactible”.

Task 15: Comprobar postura DNSSEC/DANE (si lo usas) y evitar configuraciones a medias

cr0x@server:~$ dig +short TLSA _25._tcp.mx1.example.com
3 1 1 aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899

Qué significa: Existe un registro TLSA para SMTP en el puerto 25 hacia mx1.

Decisión: Si publicas TLSA sin DNSSEC fiable, puedes crear fallos confusos para remitentes que validan. O lo haces correctamente, o no lo hagas.

Task 16: Descomprimir e inspeccionar un adjunto JSON TLS-RPT que recibiste

cr0x@server:~$ ls -1
tlsrpt-report-2026-01-02.json.gz

cr0x@server:~$ gzip -dc tlsrpt-report-2026-01-02.json.gz | head -n 30
{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-01-02T00:00:00Z",
    "end-datetime": "2026-01-03T00:00:00Z"
  },
  "report-id": "abc123",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce"
        ],
        "mx-host": [
          "mx1.example.com",
          "mx2.example.com"
        ]
      },
      "summary": {
        "total-successful-session-count": 984,
        "total-failure-session-count": 27
      }
    }
  ]
}

Qué significa: El informe confirma que evaluó la política STS y contó éxitos vs fallos.

Decisión: Profundiza en los detalles de fallo. Si hay fallos no cero bajo enforce, trátalo como un incidente: algún correo podría estar diferido o rebotado.

Tres mini-historias corporativas desde el campo

1) Incidente causado por una suposición equivocada: “El balanceador presenta el mismo certificado en todas partes”

Una SaaS mediana ejecutaba dos hosts MX detrás de un balanceador regional. El equipo tenía un proceso limpio de rotación para certificados web y supuso que el correo era “lo mismo”.
En su modelo mental, SMTP era solo otro servicio TCP con TLS y un certificado. Rotas el paquete de certificados centralmente, recargas el balanceador, listo.

Entonces empezaron a llegar informes TLS-RPT: varios grandes remitentes reportaron “certificate validation failure” para un host MX, pero no para el otro.
El on-call miró la región primaria, probó STARTTLS desde su portátil y funcionó. Cerraron el ticket como “falla del remitente”.

Al día siguiente, el conteo de fallos se duplicó. El patrón era extraño: algunos remitentes tenían éxito, otros fallaban, y no estaba correlacionado con la hora del día.
TLS-RPT tenía la respuesta visible: los fallos estaban anclados a una IP de destino, no al nombre MX. El balanceador tenía un backend obsoleto que aún servía una cadena antigua sin un intermedio.

La suposición equivocada fue sutil: creían “el balanceador termina TLS, así que los nodos backend no importan”. En realidad, tenían passthrough TLS para SMTP para preservar IPs cliente.
El balanceador era un router elegante, no un endpoint TLS. Un backend tenía un fullchain.pem desactualizado.

La solución fue aburrida: unificar el despliegue de certificados, aplicar gestión de configuración en nodos de correo y añadir una comprobación externa STARTTLS por IP.
TLS-RPT no solo reportó un fallo; proporcionó la pista topológica que los logs del servidor no dieron, porque muchas conexiones fallidas nunca llegaron al nodo que estaban tailando.

2) Optimización que salió mal: “Quitar TLSv1.2 para reducir CPU y simplificar política”

Un grupo IT empresarial decidió “modernizar” su perímetro de correo. Vieron que el uso de TLSv1.3 aumentaba y querían simplificar configuraciones, reducir la proliferación de listas de cifrados y alinearse con estándares internos.
Alguien propuso: deshabilitar TLSv1.2 completamente en SMTP entrante. Menos negociación, menos complejidad, menos superficies de ataque.

En papel, esto parecía limpio. En laboratorio, MTAs modernos negociaron TLSv1.3 al instante. Las gráficas de CPU mejoraron un poco. El equipo de seguridad dio el visto bueno.
El cambio se lanzó un viernes por la tarde, porque por supuesto así fue.

Lunes por la mañana: un puñado de socios comerciales no pudieron enviarles correos. No todo el mundo. Lo suficiente para provocar molestias ejecutivas.
Sus propios logs mostraban menos conexiones entrantes de lo normal, pero no un indicio claro. Los MTAs que no pudieron negociar simplemente no entregaron.

Llegaron informes TLS-RPT al día siguiente con una clase de fallo consistente: fallos de negociación, clusterizados por un conjunto de organizaciones asociadas y MTAs antiguos.
Esos socios no eran “inseguros” en sentido malicioso; simplemente estaban detrás de appliances que aún no soportaban TLSv1.3.

El equipo volvió a habilitar TLSv1.2, mantuvo cifrados débiles deshabilitados y puso un plan con fecha límite: rastrear quién aún necesita TLSv1.2, notificarles y medir la reducción del tail.
La optimización no estaba mal en espíritu. Estaba mal en la secuencia. TLS-RPT convirtió una discusión política en una migración medible.

3) Práctica aburrida pero correcta que salvó el día: “Probar STARTTLS en cada IP, cada día”

Una empresa financiera trató el correo como un sistema regulado. No es glamuroso, pero es consistente. Tenían MTA-STS en modo enforce y un buzón TLS-RPT que alimentaba un pequeño parser.
El parser no hacía machine learning. Contaba fallos y alertaba cuando cruzaban un umbral.

Una noche, el equipo de firewall aplicó una actualización de reglas. No iba dirigida al correo. Iba dirigida a “servicios entrantes desconocidos”.
TCP/25 permaneció abierto, pero el nuevo perfil de inspección empezó a terminar conexiones que negociaban TLSv1.3 con ciertas extensiones.

Sus comprobaciones externas diarias lo detectaron de inmediato: STARTTLS funcionaba en una IP, fallaba en otra, y el fallo se correlacionaba exactamente con el límite del cluster de firewall.

Los informes TLS-RPT al día siguiente lo confirmaron desde múltiples remitentes: fallos de handshake concentrados en el mismo rango de IP.

Porque tenían una práctica aburrida y correcta—comprobaciones sintéticas por IP más alertas de tendencias TLS-RPT—tuvieron una narrativa de incidente clara y una solicitud de reversión rápida.
El equipo de firewall revirtió el perfil, el correo fluyó y nadie tuvo que adivinar si esto era “un problema de Google”.

La moraleja no es “los firewalls son malos”. Es “asume que tu red puede cambiar comportamiento en silencio, luego instrumenta en consecuencia”.
TLS-RPT es instrumentación que obtienes desde el mundo exterior, que es exactamente donde viven tus usuarios.

Errores comunes: síntoma → causa raíz → solución

1) Informes muestran “certificate validation failure” en un solo host MX

Síntoma: Los fallos se concentran en mx2 o en una sola IP detrás de él.

Causa raíz: Deriva en despliegue de certificados, mapeo SNI incorrecto o un nodo sirviendo una cadena incompleta.

Solución: Prueba cada objetivo A/AAAA con openssl s_client, luego estandariza rutas de certificados y comportamiento de recarga entre nodos.

2) Informes muestran “no policy found” pero crees que MTA-STS está habilitado

Síntoma: Los reportantes dicen que no encontraron STS; esperabas evaluación “sts”.

Causa raíz: Falta el registro TXT _mta-sts, subdominio equivocado o DNS no visible públicamente por split-horizon.

Solución: Verifica con dig TXT _mta-sts.example.com desde un resolver público y asegúrate de que coincida con el dominio usado por los remitentes.

3) Informes muestran “policy validation failure” tras un cambio benigno de DNS

Síntoma: Modo enforce de STS empieza a fallar justo después de cambios en MX.

Causa raíz: El archivo de política MTA-STS todavía lista nombres MX antiguos, o cambiaste prioridad/hostname sin actualizar la política.

Solución: Actualiza el archivo de política (líneas mx:), incrementa el id de política en _mta-sts y valida la obtención por HTTPS.

4) Pico repentino de “TLS negotiation failure” en muchos remitentes

Síntoma: Muchos reportantes, muchos fallos, comenzando en la misma ventana.

Causa raíz: Cambios en firewall/IDS, bug del balanceador, o deshabilitaste TLSv1.2 y cortaste remitentes antiguos.

Solución: Reproduce desde afuera, compara comportamiento por IP, revisa logs de cambios de red. Si endureciste protocolos, revierte y migra gradualmente.

5) No recibes ningún informe

Síntoma: El buzón TLS-RPT permanece vacío durante semanas.

Causa raíz: No hay registro TLS-RPT, registro mal formado, el buzón rechaza adjuntos grandes, o estás esperando que todos los remitentes del mundo lo soporten.

Solución: Confirma el registro DNS, asegúrate de que el buzón acepta el formato/tamaño del informe y verifica al menos un remitente importante en tu mix entrante.

6) Los informes llegan pero son “ruido” inútil

Síntoma: Muchos tipos de fallo con recuentos pequeños; no puedes decidir qué importa.

Causa raíz: Estás viendo informes crudos sin agregación, baselines o agrupamiento por destino.

Solución: Construye una tubería mínima: descomprime JSON, agrupa por MX/IP/tipo-de-fallo, alerta en deltas, no en absolutos.

7) Activar MTA-STS en enforce causa diferimientos en la entrega

Síntoma: Algunos remitentes difieren/rebotan porque la política dice “debe usar TLS” y no pueden validarlo.

Causa raíz: Tu postura TLS no es realmente consistente: desajuste de nombre, cadena mala, fallos intermitentes, política lista MX incorrectos o endpoint HTTPS de política inestable.

Solución: Ejecuta en mode: testing primero, arregla fallos usando TLS-RPT y luego cambia a enforce cuando esté estable.

Listas de verificación / plan paso a paso

Fase 1: Hacer fluir los informes (1–2 días)

1. Crea un buzón dedicado: tlsrpt@yourdomain. Enrútalo a una cola monitorizada (sistema de tickets o buzón compartido).
2. Publica TXT TLS-RPT: _smtp._tls.yourdomain con v=TLSRPTv1; rua=mailto:....
3. Confirma DNS desde fuera de tu red (múltiples resolvers, no solo el interno).
4. Confirma que el buzón acepta adjuntos y no descarta silenciosamente correos automatizados.

Fase 2: Establecer una línea base (primera semana)

1. Recolecta informes por 7 días sin cambiar nada. Estás construyendo una línea base, no ganando un concurso de belleza.
2. Agrega por nombre MX de destino, IP de destino y tipo de fallo.
3. Identifica las 1–3 principales categorías de fallo. Ignora la cola larga hasta que lo principal esté arreglado.
4. Ejecuta comprobaciones externas STARTTLS contra cada IP MX diariamente.

Fase 3: Arreglar sistemáticamente (continuo)

1. Arregla la cadena de certificados y desajustes de nombre primero. Son de alto impacto y deterministas.
2. Arregla la alineación de políticas después: asegura que la política MTA-STS coincida con el inventario MX actual y que el endpoint HTTPS sea estable.
3. Ajusta protocolos/cifrados con cuidado. Usa TLS-RPT para medir el impacto en compatibilidad antes y después.
4. Cuando esté estable, considera MTA-STS en mode: enforce si tu modelo de amenaza y negocio lo justifican.

Fase 4: Hacerlo operacional (para que sobreviva la rotación de personal)

1. Crea un runbook on-call con la “Guía de diagnóstico rápido” arriba.
2. Añade alertas: delta de tasa de fallos por MX/IP y “apareció un nuevo tipo de fallo”.
3. Monitorea la expiración de certificados de endpoints de correo como lo haces para endpoints web.
4. Revisa TLS-RPT semanalmente en reuniones de gestión de cambios. El objetivo es detectar regresiones, no admirar gráficas.

Preguntas frecuentes

1) ¿Necesito MTA-STS para usar TLS-RPT?

No. TLS-RPT funciona por sí solo. Pero es más valioso cuando también publicas una política de aplicación (MTA-STS o DANE), porque los fallos se vuelven accionables y relevantes para seguridad.

2) ¿TLS-RPT me dirá si un mensaje se entregó en texto plano?

Reporta fallos para negociar TLS o no cumplir expectativas de política. No te dará garantías por mensaje y no enumerará entregas en texto plano a menos que la política exigiera TLS y haya fallado.

3) ¿Por qué veo fallos de solo un remitente?

Distintos remitentes validan de forma distinta. Algunos son estrictos con cadenas, otros cachean políticas STS de forma diferente, otros tienen rutas de red que tocan tu nodo malo. Usa pruebas por IP para descartar tu lado primero.

4) ¿Es seguro recibir informes TLS-RPT por correo?

Mayormente sí, pero trátalos como entrada no confiable. Son adjuntos generados por máquinas y pueden ser grandes. Almacénalos de forma segura, limita la exposición del buzón y sanea antes de parsear.

5) ¿Debería usar un endpoint HTTPS en lugar de mailto?

Si ya gestionas infraestructura de ingestión fiable y quieres automatización, HTTPS puede ser excelente. Si no, mailto es la opción pragmática. No construyas un webhook frágil para un sistema que revisas rara vez.

6) ¿Qué tan pronto empezaré a recibir informes tras publicar el registro DNS?

Típicamente en uno o dos días, dependiendo de la cadencia de los remitentes y de los TTL de DNS. No es telemetría en tiempo real; son informes programados.

7) ¿TLS-RPT ayuda a detectar ataques de degradación?

Puedes detectarlo. Si tienes MTA-STS en enforce (o DANE) y de pronto ves fallos de negociación TLS a gran escala, ese patrón puede indicar interferencia. No es prueba, pero sí una señal fuerte.

8) ¿Cuál es la causa raíz más común detrás de fallos TLS-RPT?

Problemas de certificados—especialmente cadenas incompletas y desajustes en un nodo detrás de un nombre MX. La deriva de infraestructura es imbatible.

9) ¿TLS-RPT puede romper mi flujo de correo?

No. Publicar un registro TLS-RPT solo pide informes. Las decisiones de aplicación vienen de MTA-STS o DANE, no de TLS-RPT.

10) ¿Cómo priorizo arreglos cuando los informes muestran muchos tipos de fallo?

Ordena por impacto: fallos que afectan a muchos remitentes o a un remitente de alto volumen primero, luego fallos ligados a un MX/IP (victorias rápidas), luego ajuste de políticas y por último endurecimiento de protocolos.

Conclusión: próximos pasos que realmente reducen el riesgo

TLS-RPT es uno de esos estándares de correo que parece diseñado por personas a las que las despertaron a las 2 a.m.
No asegurará SMTP mágicamente, pero evitará que operes a ciegas.

1. Publica _smtp._tls con un buzón dedicado tlsrpt@.
2. En una semana, agrega informes por MX/IP/tipo de fallo y establece una línea base.
3. Arregla primero los problemas deterministas: cadena, desajuste de nombre, deriva por nodo.
4. Si usas MTA-STS, valida la ruta HTTPS de la política y mantenla sincronizada con cambios en MX.
5. Automatiza dos cosas: comprobaciones sintéticas STARTTLS por IP y alertas sobre deltas de fallo en TLS-RPT.

No necesitas perfección. Necesitas bucles de retroalimentación. TLS-RPT te da uno desde el mundo exterior—el mundo que tu correo realmente tiene que atravesar.