Por qué el SPF no es suficiente para detener la suplantación de identidad
por
Tiempo de lectura: 3 min
Como proveedor de servicios DMARC, nos hacen esta pregunta a menudo: "Si DMARC sólo utiliza la autenticación SPF y DKIM, ¿por qué deberíamos molestarnos con DMARC? ¿No es innecesario?"
A primera vista puede parecer que no hay mucha diferencia, pero la realidad es muy diferente. DMARC no es sólo una combinación de las tecnologías SPF y DKIM, es un protocolo completamente nuevo por sí mismo. Tiene varias características que lo convierten en uno de los estándares de autenticación de correo electrónico más avanzados del mundo, y en una necesidad absoluta para las empresas.
Pero espere un momento. No hemos respondido exactamente por qué necesita DMARC. ¿Qué ofrece que no ofrezcan SPF y DKIM? Bueno, esa es una respuesta bastante larga; demasiado larga para una sola entrada del blog. Así que vamos a dividirla y a hablar primero del SPF. En caso de que no estés familiarizado con él, aquí tienes una rápida introducción.
¿Qué es el FPS?
SPF, o Sender Policy Framework, es un protocolo de autenticación de correo electrónico que protege al receptor del correo electrónico de los mensajes falsos. Es esencialmente una lista de todas las direcciones IP autorizadas para enviar correo electrónico a través de sus canales (el propietario del dominio). Cuando el servidor receptor ve un mensaje de su dominio, comprueba su registro SPF que está publicado en su DNS. Si la IP del remitente está en esta "lista", el correo electrónico se entrega. Si no, el servidor rechaza el correo.
Como puede ver, el SPF hace un buen trabajo al mantener alejados muchos correos electrónicos desagradables que podrían dañar su dispositivo o comprometer los sistemas de seguridad de su organización. Pero el SPF no es tan bueno como algunos podrían pensar. Esto se debe a que tiene algunos inconvenientes importantes. Hablemos de algunos de estos problemas.
Limitaciones del SPF
Los registros SPF no se aplican a la dirección From
Los correos electrónicos tienen varias direcciones para identificar a su remitente: la dirección del remitente que normalmente se ve, y la dirección de la ruta de retorno que está oculta y requiere uno o dos clics para verla. Con el SPF activado, el servidor de correo electrónico receptor mira la ruta de retorno y comprueba los registros SPF del dominio de esa dirección.
El problema es que los atacantes pueden aprovecharse de ello utilizando un dominio falso en su dirección de retorno y una dirección de correo electrónico legítima (o que parece legítima) en la sección del remitente. Incluso si el receptor comprobara la identificación del correo electrónico del remitente, vería primero la dirección del remitente, y normalmente no se molestaría en comprobar la ruta de retorno. De hecho, la mayoría de la gente ni siquiera sabe que existe la dirección de retorno.
El SPF se puede eludir con bastante facilidad utilizando este sencillo truco, y deja incluso a los dominios protegidos con SPF muy vulnerables.
Los registros SPF tienen un límite de búsqueda en el DNS
Los registros SPF contienen una lista de todas las direcciones IP autorizadas por el propietario del dominio para enviar correos electrónicos. Sin embargo, tienen un inconveniente crucial. El servidor receptor tiene que comprobar el registro para ver si el remitente está autorizado, y para reducir la carga del servidor, los registros SPF tienen un límite de 10 búsquedas de DNS.
Esto significa que si su organización utiliza varios proveedores de terceros que envían correos electrónicos a través de su dominio, el registro SPF puede acabar sobrepasando ese límite. A menos que se optimice adecuadamente (lo que no es fácil de hacer uno mismo), los registros SPF tendrán un límite muy restrictivo. Cuando se sobrepasa este límite, la implementación del SPF se considera inválida y su correo electrónico falla el SPF. Esto podría perjudicar sus índices de entrega de correo electrónico.
El SPF no siempre funciona cuando se reenvía el correo electrónico
El SPF tiene otro punto de fallo crítico que puede dañar la capacidad de entrega de su correo electrónico. Cuando has implementado el SPF en tu dominio y alguien reenvía tu correo, el correo reenviado puede ser rechazado debido a tu política de SPF.
Esto se debe a que el mensaje reenviado ha cambiado el destinatario del correo electrónico, pero la dirección del remitente sigue siendo la misma. Esto se convierte en un problema porque el mensaje contiene la dirección del remitente original, pero el servidor receptor ve una IP diferente. La dirección IP del servidor de correo electrónico de reenvío no está incluida en el registro SPF del dominio del remitente original. Esto puede hacer que el correo electrónico sea rechazado por el servidor receptor.
¿Cómo resuelve DMARC estos problemas?
DMARC utiliza una combinación de SPF y DKIM para autenticar el correo electrónico. Un correo electrónico debe pasar el SPF o el DKIM para pasar el DMARC y ser entregado con éxito. Además, añade una característica clave que lo hace mucho más eficaz que SPF o DKIM por sí solos: Los informes.
Con los informes DMARC, obtendrá información diaria sobre el estado de sus canales de correo electrónico. Esto incluye información sobre su alineación DMARC, datos sobre los correos electrónicos en los que falló la autenticación y detalles sobre posibles intentos de suplantación.
Si te preguntas qué puedes hacer para que no te suplanten, echa un vistazo a nuestra práctica guía sobre las 5 mejores formas de evitar la suplantación de identidad en el correo electrónico.
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- DMARC será obligatorio para el sector de las tarjetas de pago a partir de 2025 - 12 de enero de 2025
- Cambios de NCSC Mail Check y su impacto en la seguridad del correo electrónico del sector público británico - 11 de enero de 2025
- Guía de explicación de la etiqueta aspf DMARC - 7 de enero de 2025
