Autenticación del correo electrónico: SPF, DKIM y DMARC

El protocolo SMTP básico (diseñado en la década de 1970) no incorpora autenticación del remitente. Cualquier servidor de correo puede afirmar que envía correo desde cualquier dominio: una técnica denominada suplantación del correo electrónico. Los atacantes la utilizan para enviar correos de phishing que parecen proceder de organizaciones legítimas (su banco, su director ejecutivo o un proveedor conocido). Para abordar este problema se desarrollaron tres estándares de autenticación del correo electrónico basados en DNS: SPF, DKIM y DMARC. Cada uno aborda un aspecto diferente del problema de la suplantación y funcionan mejor cuando se implementan conjuntamente.

SPF es un registro TXT de DNS que especifica qué servidores de correo están autorizados a enviar correo en nombre de un dominio. Cuando un servidor de correo receptor recibe un mensaje que afirma proceder de example.com, consulta el registro SPF de example.com y verifica que la dirección IP del servidor emisor figure en él. Si la IP no está autorizada, el mensaje se puede marcar como spam o rechazar. SPF comprueba la dirección From del sobre (el comando SMTP MAIL FROM), no el encabezado From visible para los usuarios.

SPF tiene dos limitaciones importantes. En primer lugar, el reenvío rompe SPF: cuando se reenvía un correo, la IP del servidor que lo reenvía no figura en el registro SPF del dominio original, lo que hace que SPF falle en correos reenviados legítimos. En segundo lugar, SPF solo autentica la dirección From del sobre (invisible para los usuarios), no el encabezado From visible en los clientes de correo. Los atacantes aún pueden suplantar el encabezado From visible mientras utilizan una dirección From del sobre que supera SPF; por eso SPF por sí solo no es suficiente. DKIM y DMARC abordan estas deficiencias.

DKIM añade una firma criptográfica a los correos salientes. El servidor de correo emisor utiliza una clave privada para firmar encabezados específicos del correo y el cuerpo del mensaje, y añade un encabezado DKIM-Signature. La clave pública se publica como un registro TXT de DNS bajo un subdominio selector. Los servidores receptores recuperan la clave pública y verifican la firma, confirmando que el correo no se ha manipulado durante el tránsito y que se originó en un servidor con acceso a la clave privada. A diferencia de SPF, las firmas DKIM sobreviven al reenvío porque se transportan en los encabezados del correo.

DKIM utiliza selectores para permitir varias claves públicas simultáneas para un dominio, lo que resulta útil para ejecutar varios servicios de correo (Google Workspace y una plataforma de marketing) o para rotar claves sin interrupciones. El nombre del selector se incluye en el encabezado DKIM-Signature, de modo que los servidores receptores saben qué registro DNS deben consultar. Las organizaciones deben rotar las claves DKIM anualmente o cuando se sospeche que una clave está comprometida. Longitud de la clave: se recomiendan claves RSA de al menos 2048 bits; las claves de 1024 bits están obsoletas y se pueden descifrar con la capacidad de cómputo moderna.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) se basa en SPF y DKIM y añade una comprobación de alineación (el dominio del encabezado From visible debe coincidir con el dominio autenticado por SPF o DKIM) y una política que indica a los servidores receptores qué hacer cuando los mensajes no superan la autenticación. Las políticas DMARC son none (solo supervisar), quarantine (entregar en la carpeta de spam) o reject (no entregar). DMARC también permite los informes agregados (RUA) y los informes forenses (RUF), que se envían al propietario del dominio para mostrar quién está enviando mensajes en su nombre.

La alineación es lo que hace que DMARC sea eficaz contra la suplantación de encabezados. Para la alineación de SPF, el dominio del campo From del sobre SMTP debe coincidir con el dominio del encabezado From visible. Para la alineación de DKIM, el dominio de firma (d= en DKIM-Signature) debe coincidir con el dominio del encabezado From. En el modo estricto, los dominios deben coincidir exactamente. En el modo relajado, se aceptan los subdominios. Un correo electrónico supera DMARC si supera SPF O DKIM con la alineación adecuada; no es necesario que supere ambos. Esta combinación cierra la brecha que SPF por sí solo deja abierta para la suplantación del encabezado visible.

Las organizaciones deben implementar DMARC progresivamente para evitar interrumpir el correo legítimo. Etapa 1: implemente SPF y DKIM para todos los flujos de correo. Etapa 2: publique un registro DMARC p=none con informes RUA. Analice los informes (herramientas: DMARC Analyzer, dmarcian) para descubrir todas las fuentes legítimas de envío durante 2-4 semanas. Etapa 3: cambie a p=quarantine; pct=10 y aumente gradualmente pct hasta el 100 %. Etapa 4: cambie a p=reject cuando todos los flujos legítimos superen las comprobaciones. Pasar rápidamente a reject antes de descubrir todos los flujos de correo provoca que se rechacen mensajes legítimos.

BIMI es un estándar emergente basado en DMARC. Cuando un dominio tiene una política DMARC de quarantine o reject, los clientes de correo (Gmail, Apple Mail) pueden mostrar el logotipo verificado de la marca junto al nombre del remitente en la bandeja de entrada. BIMI requiere un Verified Mark Certificate (VMC) emitido por un proveedor aprobado que confirme la propiedad de la marca registrada. Aunque BIMI todavía no forma parte del examen Security+, representa la dirección que está tomando la autenticación del correo electrónico: permite distinguir visualmente y de un vistazo a los remitentes verificados de los suplantados.

Los tres estándares forman un sistema completo de autenticación del correo electrónico. SPF verifica que el servidor de envío esté autorizado por el propietario del dominio. DKIM verifica la integridad del mensaje y que la organización remitente posee la clave privada. DMARC vincula ambos con el encabezado From visible, aplica una política cuando se producen fallos y proporciona informes. Ningún estándar individual es suficiente: SPF por sí solo no puede evitar la suplantación del encabezado visible; DKIM por sí solo no obliga a rechazar los mensajes que fallan; y DMARC por sí solo, sin SPF ni DKIM, no tiene nada que comprobar. Los tres deben implementarse conjuntamente para obtener una protección completa contra la suplantación de dominios.

Una medida práctica de defensa en profundidad contra el phishing y el BEC consiste en añadir un banner de advertencia de correo electrónico externo a todos los mensajes que se originan fuera de la organización. Este banner, que normalmente inserta el SEG, alerta a los empleados de que el correo procede de un remitente externo, incluso cuando el nombre mostrado parece corresponder al de un compañero o directivo. Los banners son especialmente eficaces para señalar intentos de BEC en los que el atacante utiliza un dominio parecido o suplanta el nombre mostrado. El banner debe distinguirse visualmente (mediante un encabezado o pie de página de color) e incluir instrucciones para informar de mensajes sospechosos.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que SPF utiliza registros TXT de DNS para autorizar las IP de envío, pero solo comprueba el From del sobre, no el encabezado visible; que DKIM añade firmas criptográficas que verifican la integridad del mensaje y se mantienen al reenviarlo; y que DMARC vincula SPF y DKIM con el encabezado From visible mediante comprobaciones de alineación y una política aplicable (none/quarantine/reject), además de proporcionar informes. A continuación, exploraremos las puertas de enlace de correo electrónico seguras y los controles antispam.