Autenticación SPF: SPF-all vs. ~all

Last Updated: October 13, 2021

5 Min Read

¿Qué es SPF? Las siglas en inglés significan “Sender Policy Framework,” en español el nombre más apropiado sería “Esquema de políticas del remitente.” Este comando permite al administrador de una dirección IP específica el envío de correos electrónicos a través de esta. Esta autorización es publicada como un registro .TXT en el proveedor de DNS (puede ser Cloudflare, GoDaddy, etc.)

Ten en cuenta que un SPF chequea el espacio 5321.MailFrom address (también conocido como la ruta de regreso, sobre del remitente, o la dirección de rebote) para autorizar el envío de direcciones IPs. Si el servidor de correo del remitente se adhiere a la política SPF de quien remite el correo, este debería actuar en base a la política SPF.

En este artículo, vamos a discutir porque deberías usar SPF-all vs. ~all.

¿Cómo luce un registro SPF?

Un registro SPF TXT empieza con el indicador de la versión de SPF que se ha utilizado, seguido de la lista de IPs que están autorizadas a enviar correos electrónicos a través del dominio principal. Todas las IPs deberían mostrar las etiquetas -all, ~all, +all y ?all, ya que estas indican qué política debería ser aplicada cuando los proveedores de correo (MBPs como Google, Microsoft o Yahoo!) detecten que el correo electrónico fue enviado de los servidores o direcciones IP que no están autorizadas en el registro SPF. Puedes revisar este indicador en nuestro chequeador de registros SPF gratuito.

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

Esta es la descripción de cada parte del código:

v=spf1: este registro SPF siempre debería comenzar con v=spf1 indicando el número de la versión utilizada.
Mecanismos ip4 e ip6: Estos mecanismos contienen listas de direcciones IP individuales (por ejemplo: 172.16.254.1 y 2001:db8:0:1234:0:567:8:1) o direcciones IP de las subredes (por ejemplo, ip4:213.22.138.0/24) que están autorizadas para el envío de correos de parte del dominio. Nótese que las direcciones IPv4 deben incluir el prefijo “ip4”, y las direcciones IPv6 deberían tener etiquetas “ip6”.
Mecanismo “include” (incluir): Este es utilizado para autorizar acceso a los servicios de terceros que sean usados para enviar correos desde tu dominio. En este ejemplo el comando “_spf.google.com” autoriza a Google Workspace (antiguo G Suite) a que envíe correos por parte de tu dominio.
Mecanismo “all”: En este ejemplo, el mecanismo de etiqueta “-all” (Fail) es utilizado. Entre las etiquetas también se incluyen:
1. -all (Fail): correos de servidores o direcciones IP que no se encuentran en el listado deberían ser rechazados.
2. ~all (SoftFail): correos de servidores o direcciones IP que no se encuentran en el listado del registro SPF deberán ser aceptados, pero con una marca.
3. +all (Pass): cualquier servidor puede enviar correos a nombre de tu dominio. Recomendamos que nunca uses esta opción.
4. ?all (Neutral): Esta etiqueta se interpreta como “Ninguna/Sin política aplicada.” Tampoco recomendamos que uses esta opción.

Para generar un registro SPF, chequea nuestra herramienta generadora de SPF.

También te recomendamos leer nuestra guía para mejorar el uso de SPF y el envío de correos electrónicos

¿Cuál SPF es mejor: -all o ~all?

Antes de la adopción del protocolo DMARC en el año 2012, SPF, que fue introducido en el año 2004, tenía un rol más relevante en la lucha contra rutas de retorno o MailFrom usado para el robo de identidad, incluso con todas sus limitaciones. Los administradores de servicios de correo electrónico aplicaban reglas basadas en los registros de políticas estipulados en los SPFs creados por los administradores (~all o -all).

Esto provocó muchos problemas en su momento ya que correos legítimos eran bloqueados debido a los errores de configuración del SPF, lo cual llevó a la mayoría de los proveedores de servicios de correos a usar el método de aceptar todos los correos, pero marcándolos usando SoftFail (~all) y Fail (-all).

En EasyDMARC aconsejamos a nuestros usuarios publicar sus registros SPF con SoftFail (~all) por tres razones muy específicas:

Desde la adopción de DMARC, los proveedores de correo usan políticas DMARC tales como (p=quarantine o p=reject para que las reglas que manejan SPF ~all sean las mismas que -all, estableciendo “Not Passed” o “SPF Fail”
Al usar SPF ~all es posible hacer que el proceso de depuración de los reportes por agregaduría DMARC sea mucho más fácil (identificando las direcciones usadas como rutas de regreso)
Cada tanto puede que te consigas con un proveedor de correos no muy conocido quienes aún usan SPF “Fail” y “Softfail” como fueron diseñados originalmente, lo cual puede producir varios falsos positivos y hacer que correos electrónicos legítimos sean rechazados. Esto puede evitarse con el comando ~all.