La mayoría de las empresas asume que sus correos viajan cifrados de un servidor a otro. En la práctica, ese cifrado es opcional y un atacante bien ubicado puede desactivarlo sin que nadie lo note. MTA-STS y TLS-RPT existen justamente para cerrar esa puerta.
Cuando un servidor envía un correo a otro, usa un mecanismo llamado STARTTLS: pregunta al servidor receptor si soporta cifrado. Si la respuesta es sí, se abre una sesión TLS; si es no, el mensaje se envía en texto plano. Por eso se le llama cifrado oportunista: se usa solo si está disponible, y se descarta si no.
Ese "si no, lo mando igual" es el problema.
Un atacante activo en la ruta del correo —lo que se conoce como Attacker-in-the-Middle— puede interceptar la negociación e inyectar una respuesta falsa que dice "no soporto cifrado". El servidor emisor, siguiendo la regla, envía el mensaje sin cifrar, y el atacante lo lee completo. Es un ataque de downgrade clásico, y no requiere romper ningún cifrado: basta con impedir que ocurra.
Peor aún: incluso cuando hay un certificado de por medio, la mayoría de los servidores emisores, ante un certificado no confiable (vencido, con el nombre equivocado o de una CA desconocida), lo aceptan igual. Eso protege frente a un espía pasivo, pero no frente a uno activo.
MTA-STS (RFC 8461) le permite a tu dominio declarar una política pública: "mi correo se entrega solo con TLS y con un certificado válido de una CA de confianza". Los servidores que respetan la política:
max-age).En otras palabras: pasas de pedir cifrado a exigirlo.
Tiene un matiz honesto: la política se guarda en caché de forma "perezosa", así que el primer mensaje a un dominio todavía puede ser vulnerable hasta que la política queda almacenada. No es una bala de plata, pero cierra la ventana para todo el tráfico posterior.
TLS-RPT (RFC 8460) es el complemento: hace que otros servidores te envíen informes agregados cuando una entrega hacia tu dominio falla por problemas de TLS (por ejemplo, starttls-not-supported o certificate-not-trusted). Sin TLS-RPT, un problema de cifrado es invisible; con él, lo ves y lo corriges antes de que sea un incidente.
Aunque MTA-STS existe desde 2018, su adopción sigue siendo baja incluso entre grandes proveedores. Un análisis publicado en el blog de APNIC en 2024 mostró que:
Ese 2% parece poco hasta que lo cruzas con el volumen de correo corporativo: recuperaciones de contraseña, enlaces de acceso, documentos internos. Un solo mensaje interceptado puede ser suficiente.
Este frente es complementario al de autenticación del remitente. Si todavía no tienes DMARC resuelto, conviene partir por ahí: lo explicamos en DMARCbis explicado. Y si te interesa el ángulo regulatorio, un correo interceptado puede terminar siendo una brecha que hay que notificar, como vimos en la nota sobre la Ley 21.719.
Proteger el correo en tránsito no requiere cambiar de proveedor, sino configurar correctamente tu dominio:
En Digital Corp ayudamos a implementar MTA-STS y TLS-RPT de punta a punta, a interpretar los reportes y a dejar tu correo exigiendo cifrado real, no opcional.
¿Quieres saber cómo está tu dominio hoy? Puedes revisarlo gratis en tools.digitalcorplatam.com ↗, o escríbenos y lo vemos juntos.
Revisamos cómo está tu dominio hoy, implementamos MTA-STS y TLS-RPT de punta a punta y te dejamos los reportes interpretados.
Solicitar diagnóstico
