Envío de correo mediante un relay: comprobar TLS y autenticación

Muchas aplicaciones no envían correos directamente a Internet, sino que los entregan a un relay interno: el ERP sus confirmaciones de pedido, el sistema de monitorización sus alertas, el sistema de tickets sus notificaciones. El equipo de correo opera el relay; del lado de la aplicación, la responsabilidad recae en el responsable de aplicaciones. Por eso, durante una auditoría o un análisis de necesidades de protección, la pregunta llega a esta persona: ¿la aplicación se conecta al relay de forma cifrada y se autentica correctamente?

La respuesta se encuentra en dos lugares para los que no se necesita ninguna herramienta de correo ni acceso al relay: en la configuración SMTP de la propia aplicación y en la cabecera de un único correo de prueba. El equipo de correo es responsable de lo que ofrece el propio relay y de cómo cifra los correos hasta el destinatario; del lado de la aplicación, basta con demostrar el propio tramo.

Dónde se encuentran los ajustes

Según la aplicación, la configuración SMTP se encuentra en uno de tres lugares: en la interfaz de administración (normalmente en «Correo electrónico», «Notificaciones», «SMTP» o «Servidor saliente»), en un archivo de configuración o en variables de entorno del despliegue (típicamente SMTP_HOST, SMTP_PORT, SMTP_USER y variantes). Siempre se buscan los mismos datos: nombre del servidor, puerto, una opción de cifrado y las credenciales.

Los tres ajustes que importan

Primero, el puerto y el modo TLS. Ambos deben coincidir, ya que tras los valores de selección hay dos procedimientos diferentes: con STARTTLS la conexión comienza en texto claro y luego pasa a TLS; con TLS implícito (normalmente denominado «SSL/TLS» o «SSL» en las interfaces), está cifrada desde el principio.

Una combinación errónea (por ejemplo, «SSL/TLS» en el puerto 587) provoca interrupciones de conexión, no texto claro inadvertido. Los ajustes de riesgo son las dos últimas filas de la tabla, pues en ellas la aplicación envía sin cifrar y sin mostrar un mensaje de error.

Segundo, la validación del certificado. Muchas aplicaciones ofrecen una opción como «No validar certificado», «Allow insecure» o verify=false, que suele activarse en proyectos de implantación porque el relay utiliza un certificado interno. La conexión sigue estando cifrada, pero la aplicación acepta cualquier extremo. Si la opción está activada, debe constar como hallazgo en el informe; la solución correcta es confiar en la CA interna en lugar de desactivar la validación.

Tercero, la autenticación. Los relays conocen dos modelos: SMTP AUTH con nombre de usuario y contraseña, o autorización por IP sin cuenta. La variante aplicable figura en la autorización del relay del equipo de correo. Para SMTP AUTH, hay tres puntos en la lista de comprobación: la autenticación se realiza mediante una cuenta de servicio dedicada de la aplicación (no con una cuenta personal que se desactivará con la próxima salida), la contraseña se almacena como secreto en lugar de en texto claro en un archivo de configuración, y la opción TLS está activa, ya que los procedimientos habituales PLAIN y LOGIN transmiten de otro modo las credenciales en texto claro.

Cómo se denominan los ajustes en entornos habituales

Por experiencia, dos puntos de esta tabla son los hallazgos más frecuentes: en Java, starttls.enable por sí solo activa únicamente TLS oportunista; solo starttls.required evita el retorno al texto claro. En Nodemailer, secure:false no significa «sin cifrar», sino «sin TLS implícito»; sin requireTLS:true, STARTTLS también sigue siendo oportunista.

Contraprueba: un correo de prueba y su cabecera Received

La configuración indica el estado objetivo, pero no demuestra lo que ocurre en la conexión. La prueba figura en la cabecera Received, que el relay añade al recibir cada correo. Basta con enviar un correo de prueba desde la aplicación al propio buzón; allí hay que mostrar la cabecera del mensaje (Outlook: Archivo, Propiedades, Encabezados de Internet; Gmail: Mostrar original) y leer la línea Received inferior, ya que las cabeceras crecen de abajo arriba:

Received: from app01.example.com (app01.example.com [10.1.2.3])
        by relay.example.com (Postfix) with ESMTPSA id 4XyZk12Fzq
        (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
        Thu, 28 Aug 2026 09:15:04 +0200

La palabra clave después de with es el resumen del resultado de la comprobación. Los identificadores están estandarizados (registro de IANA «Mail Transmission Types»):

Postfix y Exchange añaden entre paréntesis la versión TLS y el cifrado, lo que también permite identificar versiones de protocolo obsoletas. Para analizar cabeceras largas con varias estaciones, el analizador de cabeceras de correo de este sitio web le evita el trabajo manual; funciona completamente de forma local en el navegador y la cabecera no sale de su ordenador.

Si la cabecera sigue sin estar clara o un balanceador de carga anterior modifica el registro de la conexión, es el momento de solicitar información al equipo de correo: el registro del relay documenta para cada entrega si se negoció TLS y con qué cuenta se autenticó la aplicación.

Lista de comprobación breve para el informe de auditoría

1. Se ha localizado y documentado la configuración SMTP de la aplicación (interfaz, archivo de configuración o variables de entorno).
2. El puerto y el modo TLS coinciden (587/STARTTLS o 465/SSL-TLS); no hay ningún ajuste «Ninguno» ni «TLS si está disponible».
3. La validación del certificado está activa; una opción «No validar certificado» activada se ha registrado como hallazgo.
4. Se ha aclarado el modelo de autenticación: SMTP AUTH con cuenta de servicio y almacenamiento de secretos, o autorización por IP según la autorización del relay.
5. La cabecera Received del correo de prueba muestra ESMTPSA (con cuenta) o ESMTPS (con autorización por IP); ESMTPA y ESMTP son hallazgos.
6. Si se exige cifrado hasta el destinatario: se ha dirigido como requisito al equipo de correo, ya que el tramo a partir del relay queda fuera de la aplicación.