Todo el mecanismo siempre coincide. Por lo tanto, su calificador determina qué SPF dice sobre una dirección de conexión que le llega. Las terminaciones familiares -all , ~all , ?all y +all son cuatro declaraciones de autenticación diferentes, no cuatro acciones de entrega garantizadas.
Es posible que un mecanismo anterior ya haya arrojado un resultado. Lea todo el recorrido de evaluación antes de interpretar la última palabra del registro. RFC 7208 §2.6 y RFC 7208 §5.1 definir esta semántica.
Compara los cuatro finales.
Con -all , un remitente que llega a todos los mensajes falla. La política dice que la dirección no está autorizada para la identidad evaluada. Con ~all , recibe softfail , una declaración negativa más débil en lugar de un aprobado. Con ?all , recibe neutral, lo que significa que la política no realiza una afirmación de autorización para esa dirección. Con +all , recibe pase.
Bajo RFC 7208 §4.6.2, un todo no calificado tiene el calificador + predeterminado y, por lo tanto, también pasa. Eso hace que todo sea una elección de permiso consecuente, no un terminador inofensivo. Una vez que todas coinciden, los mecanismos posteriores no pueden aportar permisos adicionales.
Ejemplo resuelto: mantener constante el remitente autorizado
Utilice la política sintética v=spf1 ip4:192.0.2.90 QUALIFIERall. Para una conexión desde 192.0.2.90 , ip4 coincide primero y devuelve el pase debajo de cada final. Para 192.0.2.91 , el primer mecanismo no coincide. El final elegido devuelve fail, softfail , neutral o pass respectivamente.
Cambiar ~all a -all no cambia el resultado de la primera dirección en este aparato. Cambia el tratamiento de las direcciones que aún no coincidieron. Es por eso que la pregunta correcta sobre la preparación es si se han identificado todas las rutas de envío legítimas, no si un remitente común pasó una prueba.
Una política que consiste en v=spf1 -all no autoriza direcciones a través de SPF . Puede expresar una identidad que no es de envío, pero no es una instrucción universal de que cada receptor deba descartar todos los mensajes que muestren ese dominio en From.
Mantenga el resultado y el manejo separados
SPF devuelve un resultado de autenticación. El receptor decide qué hacer con el mensaje utilizando la política local y otras evidencias bajo RFC 7208 §8.4 y RFC 7208 §8.5. Un error no es prueba de que todos los receptores rechazaron el mensaje, y softfail no es una promesa de que se entregará con una advertencia.
SPF softfail y neutral no se convierten en rutas de paso SPF para DMARC. Bajo RFC 9989 §4.4.2, DMARC requiere un pase con alineación para su ruta SPF , o un paso separado alineado DKIM camino. Por lo tanto, un mensaje puede pasar DMARC a través de DKIM a pesar del error SPF . Por el contrario, +all puede generar un pase SPF para una dirección sin que su contenido sea confiable.
No utilice +all para silenciar un panel de error. Autoriza cada dirección que le llega para esa identidad y anula la restricción prevista. En su lugar, repare los remitentes que faltan, las identidades incorrectas o las dependencias rotas.
Distinguir los finales de las políticas de los errores de evaluación
error permanente y temperror no son otras grafías de fallar. Múltiple Registros SPF, la sintaxis no válida o los límites de procesamiento excedidos pueden impedir la evaluación normal. Los problemas temporales DNS pueden producir temperror . Reemplazar -all con ~all no repara un error que ocurre antes de llegar al final.
Recopile el resultado real y rastree antes de elegir un cambio. En caso de una interrupción DNS , investigue la dependencia y la ruta de resolución. Para un remitente legítimo no reconocido, establezca su propietario y la identidad esperada del sobre antes de otorgarle permiso.
Implementar una declaración más estricta con evidencia
Inventario de rutas de envío regulares, de conmutación por error, IPv6 y poco frecuentes. Pruebe la política propuesta contra esas direcciones y un control no autorizado. Mantenga el registro anterior, defina las condiciones de reversión basadas en el servicio y verifique el correo recibido después de la publicación.
Cuando el reenvío sea parte de una entrega legítima, revise el diseño de autenticación más amplio, incluido DKIM alineado y el comportamiento del receptor. No autorice ampliamente a reenviadores desconocidos a realizar todas las rutas SPF indirectas.
La conclusión práctica
Elija el calificador de la declaración que desea hacer sobre remitentes que de otro modo no coincidirían. Primero verifique el inventario y las rutas de error, luego mida la autenticación y la entrega como resultados separados.
Registre la siguiente decisión
Para 192.0.2.91 en el dispositivo sintético, los cuatro finales producen falla/ softfail /neutral/aprobación respectivamente; 192.0.2.90 permanece pasando por la coincidencia ip4 anterior. Si se produce un error de sintaxis o de dependencia antes de un resultado normal, cambiar el calificador final no es una reparación. Estos son resultados analíticos del flujo de control, no pruebas de entrega.