¿Por qué el correo electrónico se entrega normalmente a pesar de un "error" de SPF?

Estoy tratando de averiguar por qué el correo electrónico falsificado se envía a los principales proveedores de correo electrónico (gmail.com, outlook.com) a pesar de que el correo electrónico está marcado con un SPF hardfail. El correo electrónico también se entrega a Microsoft Exchange, que está lanzando un PermErrorpara el mismo registro SPF.

Estoy enviando un correo electrónico utilizando el dominio SOME_DOMAIN.com, que define un registro SPF roto. El correo electrónico se transmite desde mi propia dirección IP que no aparece explícitamente en el registro SPF de SOME_DOMAIN.com. El registro SPF para SOME_DOMAIN.com tiene las siguientes tres propiedades, las dos primeras son una violación del SPF RFC-4408:

1. Requiere más de 10 consultas DNS para resolver todo el registro SPF, debido a include:.
2. Error de sintaxis en uno de los registros SPF, python-spf arroja un error de análisis.
3. El registro SPF contiene las reglas ~ally -all, ambas dicen que el conjunto de todas las direcciones debería softfailyhardfail

El correo electrónico enviado a una dirección de outlook.com que se hace pasar por admin@SOME_DOMAIN.com contendrá el siguiente error en el encabezado SMTP del correo electrónico entregado. Este correo electrónico se entregó normalmente a la bandeja de entrada del usuario :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail también entregará el correo electrónico a la bandeja de entrada del usuario, pero arrojará un error SPF diferente:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Entonces, ¿qué está pasando aquí? ¿Por qué se envía el correo electrónico a pesar de un SPF hardfail? ¿Tener un registro SPF roto significa que otros servidores SMTP ignoran el SPF por completo? ¿O hay algo que me falta aquí ...

SPF está tan mal configurado por tantos sitios que los MTA que reciben suelen contar hardfailsolo como asesoramiento y simplemente lo tienen en cuenta en sus puntajes de detección de spam. Al final, depende del administrador de la MTA cómo se tratarán las fallas SPF.

Las condiciones de error de SPF no indican nada sobre la política deseada. Como tales, no proporcionan orientación sobre si aceptar o no el mensaje. Es posible que la política prevista sea +all. Es normal aceptar correo en este caso. Parece que Google está siendo indulgente con el incumplimiento de este dominio con el estándar.

Incluso los rechazos de políticas SPF ( -all) no son confiables al validar las direcciones del remitente. Hay una serie de casos en los que rechazar dicho correo sería inapropiado, incluyendo:

• Correo enviado por remitentes contratados (a estas personas se les paga por violar la política);
• Correo enviado desde formularios web y otros sistemas automatizados;
• Correo reenviado por listas de correo u otros mecanismos de reenvío; y
• Simplemente la configuración incorrecta de los registros SPF (no es común, pero no lo suficientemente raro).

Ejecuto un servidor bastante pequeño donde puedo diferir los fallos duros. Esto me permite hacer una lista blanca de fallas legítimas. Si el remitente nota que no se entrega el correo, puede corregir su configuración. En algunos casos, intentaré contactar al relevante postmaster, pero muchos dominios no tienen una postmasterdirección.

Los usuarios que desean aplicar una política más sólida pueden usar DMARC, que aún no es un estándar. Es probable que aún se entregue el correo, pero se puede poner en cuarentena o rechazar según lo especificado en esa política. El correo que falla la política puede ser entregado a la carpeta de spam, en lugar de la bandeja de entrada normal.

Las fallas duras de SPF parecen ser confiables para validar la identidad del servidor emisor. Investigué un poco hace un tiempo, y descubrí que incluso las fallas leves en el nombre HELO son una razón razonable para fallar o diferir los mensajes entrantes.

Muchos servidores de correo no tienen un registro SPF. Si el servidor de correo no tiene un registro SPF, verifico en el dominio principal un registro SPF. Esto no es estándar, pero es efectivo. Recomiendo a los administradores de correo electrónico que se aseguren de que haya un registro SPF para la IP del servidor como se indica en el registro PTR. Su servidor también debe identificarse por el nombre devuelto por su registro PTR. Verifique que tiene un registro A correspondiente para la verificación inversa de DNS