¿Qué es SPF? el marco de política del remitente le permite al administrador de un dominio especificar qué direcciones IP pueden enviar correos en nombre de este; dicha autorización se publica como un registro .TXT en el proveedor del DNS (Cloudflare, GoDaddy, etc.). Es importante tener en cuenta que SPF comprueba la dirección 5321.MailFrom (también conocida como dirección de retorno, sobre de envío o dirección de rebote) para autorizar el envío de direcciones IP; cuando el servidor de correo del destinatario se adhiere a la política SPF del dominio del remitente, ambos interactúan en base a los lineamientos publicados en la política SPF.
Desde hace un tiempo existe una disputa histórica relacionada con el uso de los mecanismos SPF “hard fail” o “soft fail” desde que se iniciara el uso de los marcos de políticas del remitente desde el año 2004.
En este artículo, vamos a discutir por qué deberías usar SPF softfail vs hardfail (-all vs ~all)
Registro SPF: ¿cómo luce?
El registro SPF .TXT comienza con el indicador de la versión SPF que está siendo usada seguida de todas las direcciones IP incluidas en la lista blanca, que están autorizadas para enviar correos a nombre de un dominio especifico, y termina con una etiqueta “all”, aquí te presentamos los dos escenarios posibles:
- -all (Fail): aquí el correo de los servidores/direcciones IP que no figuran en el registro SPF deben ser rechazados.
- ~all (SoftFail): aquí los correos electrónicos de servidores/direcciones IP, que no figuran en el registro SPF, deben ser aceptados con una marca.
- +all (Aprobado): cualquier servidor puede enviar correos a nombre de tu dominio, como es de esperar, te recomendamos encarecidamente no usar esta opción.
- ?all (Neutro): esta etiqueta se interpreta como none/sin política, nuevamente recomendamos no usar esta opción.
Las etiquetas anteriores indican qué política debe aplicarse al correo cuando los ESPs (proveedores de buzón como Google, Microsoft, Yahoo!, etc.) detectan que el correo ha sido enviado desde servidores o direcciones IP que no figuran en tu registro SPF; el uso de SPF hard fail o soft fail son los dos métodos más aceptados, pero la preferencia general es “~all”.
Ahora que sabes que no deberías usar +all y ?all, podemos revisar un ejemplo del tipo de registro SPF antes de tocar el tema SPF SoftFail vs HardFail.
Ejemplo de registro SPF:
v=spf1 ip4:172.16.254.1 ip4:213.22.138.0/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all
- v=spf1: el registro SPF siempre debe comenzar con el número de la versión v=spf1 a usar.
- Mecanismos ip4 e ip6: con los que enumeran la dirección IP única (por ejemplo: 172.16.254.1 y 2001:db8:0:1234:0:567:8:1) o las subredes IP (por ejemplo: ip4:213.22.138.0/24) las cuales están autorizadas para enviar correos a nombre de un dominio; ten en cuenta que las direcciones IPv4 deben tener el prefijo «ip4» mientras que las direcciones IPv6 necesitan la etiqueta «ip6».
- Mecanismo «include»: este se utiliza para autorizar servicios de terceros que son usados para enviar correos electrónicos a nombre de tu dominio; en este ejemplo, «_spf.google.com» autoriza a Google Workspace (anteriormente G Suite) a enviar mensajes de correo a nombre de su dominio.
- Mecanismo “all”: En este ejemplo, se utiliza la etiqueta “-all” (Falla).
En este ejemplo se usa el registro SPF hardfail vs softfail, para descartar todos los correos que no pasen la prueba, incluidos los legítimos.
SPF -all vs ~all: ¿qué debo usar?
Antes de la adopción de DMARC (en el año 2012), solo SPF desempeñaba un papel importante en la autenticación de mensajes de correo, a pesar de sus limitaciones, era el único mecanismo de lucha contra los intentos de suplantación de correo de las direcciones de retorno o MailFrom. Los ESPs aplicaron una serie de reglas basadas en las políticas de registro de SPF tal como eran expresadas por los administradores (~all o -all), lo cual causó problemas con el bloqueo de correos legítimos debido a múltiples errores de configuración de SPF, lo que a su vez llevó a la mayoría de los servicios de correos conocidos a usar SoftFail (~all) y Fail (-all) como método para aceptar el ingreso de mensajes con una marca.
https://www.youtube.com/watch?v=sM5JGTXErtgSPF Authentication: SPF -all vs ~all | EasyDMARC
Hay algunos pros y contras de SPF fail vs. soft-fail, por lo que podemos profundizar acerca de las 3 razones principales por las que en EasyDMARC le recomendamos a nuestros usuarios que publiquen sus registros SPF configurados con ~all.
- Desde la adopción de DMARC, los servicios de correos usan las políticas DMARC de los dominios (p=quarantine o p=reject) para aplicar reglas de control para los correos fallidos; el registro SPF softfail frente a hardfail inicialmente significaba que un correo no podía pasar. El asunto es que esto deja en evidencia una ligera diferencia: SPF ~all significa «No aprobado», mientras que -all significa «SPF fallido” por lo que el correo debe rechazarse.
- El uso de SPF ~all puede facilitar el proceso de depuración de los informes de agregaduría de DMARC, así como la identificación de direcciones de ruta de retorno.
- De vez en cuando, es posible que te consigas con algunos servicios de correos que no son muy conocidos que aun manejan las políticas SPF «Fail» y «SoftFail» como se pretendía originalmente, lo cual produce múltiples falsos positivos y correos legítimos rebotados; lo cual puede evitarse usando SPF softfail vs hardfail.
Próximos pasos
Optimizar tus registros SPF puede ser un reto desafiante, por eso te ofrecemos nuestra guía para la optimización de SPF.
Además, puedes consultar nuestra herramienta de chequeo de registros SPF en crudo para validar tu registro SPF antes de implementarlo en tu DNS.
Para verificar si tienes un registro SPF configurado correctamente en tu dominio, puedes inspeccionar tu dominio con nuestra herramienta de verificación de registros SPF gratuita; si necesitas crear un registro SPF nuevo, puedes usar nuestra herramienta generadora de SPF.
También te invitamos a leer nuestra guía definitiva sobre SPF para mejorar la entregabilidad de tus correos electrónicos.