Cuando un correo electrónico se envía desde el servidor remitente, directamente al servidor receptor, SPF y DKIM (si se configuran correctamente) autentican el correo electrónico normalmente y suelen validarlo eficazmente como legítimo o no autorizado. Sin embargo, este no es el caso si el correo electrónico pasa a través de un servidor de correo intermediario antes de ser entregado al destinatario, como en el caso de los mensajes reenviados. Este blog pretende explicarle el impacto del reenvío de correo electrónico en los resultados de autenticación DMARC.
Como ya sabemos, DMARC utiliza dos protocolos estándar de autenticación de correo electrónico, a saber, SPF (Sender Policy Framework) y DKIM (DomainKeys Identified Mail), para validar los mensajes entrantes. Vamos a hablar de ellos brevemente para comprender mejor su funcionamiento antes de pasar a ver cómo puede afectarles el reenvío.
Marco normativo del remitente
El SPF está presente en su DNS como un registro TXT, mostrando todas las fuentes válidas que están autorizadas a enviar correos electrónicos desde su dominio. Cada correo electrónico que sale de su dominio tiene una dirección IP que identifica a su servidor y al proveedor de servicios de correo electrónico utilizado por su dominio que se alista en su DNS como un registro SPF. El servidor de correo del receptor valida el correo electrónico contra su registro SPF para autenticarlo y, en consecuencia, marca el correo electrónico como SPF aprobado o no aprobado.
Correo identificado con DomainKeys
DKIM es un protocolo estándar de autenticación de correo electrónico que asigna una firma criptográfica, creada mediante una clave privada, para validar los correos electrónicos en el servidor receptor, en el que el receptor puede recuperar la clave pública del DNS del remitente para autenticar los mensajes. Al igual que el SPF, la clave pública DKIM también existe como un registro TXT en el DNS del propietario del dominio.
El impacto del reenvío de correo electrónico en sus resultados de autenticación DMARC
Durante el reenvío del correo electrónico, éste pasa por un servidor intermediario antes de llegar al servidor receptor. En primer lugar, es importante tener en cuenta que el reenvío de correo electrónico se puede hacer de dos maneras: o bien los correos electrónicos pueden ser reenviados manualmente, lo que no afecta a los resultados de la autenticación, o bien pueden ser reenviados automáticamente, en cuyo caso el procedimiento de autenticación se ve afectado si el dominio no tiene el registro de la fuente de envío intermediario en su SPF.
Naturalmente, durante el reenvío de correo electrónico suele fallar la comprobación SPF, ya que la dirección IP del servidor intermediario no coincide con la del servidor remitente, y esta nueva dirección IP no suele incluirse en el registro SPF del servidor original. Por el contrario, el reenvío de correos electrónicos no suele afectar a la autenticación DKIM de correos electrónicos, a menos que el servidor intermediario o la entidad de reenvío realice ciertas alteraciones en el contenido del mensaje.
Tenga en cuenta que para que un correo electrónico pase la autenticación DMARC, se requerirá que el correo electrónico pase la autenticación y alineación SPF o DKIM. Como sabemos que el SPF falla inevitablemente durante el reenvío de correo electrónico, si en caso de que la fuente de envío sea neutral en cuanto a DKIM y confíe únicamente en el SPF para la validación, el correo electrónico reenviado se convertirá en ilegítimo durante la autenticación DMARC.
¿La solución? Muy sencilla. Debe optar inmediatamente por el cumplimiento total de DMARC en su organización, alineando y autenticando todos los mensajes entrantes tanto con SPF como con DKIM.
Lograr el cumplimiento de DMARC con PowerDMARC
Es importante tener en cuenta que para lograr el cumplimiento de DMARC, los correos electrónicos deben ser autenticados contra SPF o DKIM o ambos. Sin embargo, a menos que los mensajes reenviados sean validados contra DKIM, y se basen sólo en SPF para la autenticación, DMARC fallará inevitablemente como se discutió en nuestra sección anterior. Por ello, PowerDMARC le ayuda a lograr el cumplimiento completo de DMARC al alinear y autenticar eficazmente los mensajes de correo electrónico con los protocolos de autenticación SPF y DKIM. De este modo, incluso si los mensajes reenviados auténticos no superan el SPF, la firma DKIM puede utilizarse para validarlo como legítimo y el correo electrónico pasa la autenticación DMARC, llegando posteriormente a la bandeja de entrada del receptor.
Casos excepcionales: ¿Fallo de DKIM y cómo resolverlo?
En ciertos casos, la entidad reenviadora puede alterar el cuerpo del correo haciendo ajustes en los límites MIME, la implementación de programas antivirus o la recodificación del mensaje. En estos casos, tanto la autenticación SPF como la DKIM fallan y los correos legítimos no se entregan.
En caso de que tanto SPF como DKIM fallen, PowerDMARC es capaz de identificar y mostrar eso en nuestras vistas agregadas detalladas y protocolos como Authenticated Received Chain pueden ser aprovechados por los servidores de correo para autenticar dichos correos. En ARC, la cabecera Authentication-Results puede pasarse al siguiente "salto" en la línea de entrega del mensaje, para mitigar eficazmente los problemas de autenticación durante el reenvío del correo electrónico.
En el caso de un mensaje reenviado, cuando el servidor de correo electrónico del receptor recibe un mensaje que ha fallado en la autenticación DMARC, intenta validar el correo electrónico por segunda vez, contra la Cadena Autenticada Recibida proporcionada para el correo electrónico, extrayendo los Resultados de Autenticación ARC del salto inicial, para comprobar si fue validado como legítimo antes de que el servidor intermediario lo reenviara al servidor receptor.
Así pues, regístrese en PowerDMARC hoy mismo y consiga que su organización cumpla con la normativa DMARC.
- Puede Blockchain ayudar a mejorar la seguridad del correo electrónico? - 9 de mayo de 2024
- Proxies de centros de datos: Desvelando el caballo de batalla del mundo proxy - 7 de mayo de 2024
- Kimsuky explota las políticas DMARC "None" en recientes ataques de phishing - 6 de mayo de 2024