¿Usar SOFTFAIL sobre FAIL en el registro SPF se considera la mejor práctica?

O dicho de otra manera, ¿se v=spf1 a mx ~allrecomienda usar sobre usar v=spf1 a mx -all? El RFC no parece hacer ninguna recomendación. Mi preferencia siempre ha sido usar FAIL, lo que hace que los problemas se vuelvan aparentes de inmediato. Creo que con SOFTFAIL, los registros SPF configurados incorrectamente pueden persistir indefinidamente, ya que nadie se da cuenta.

Sin embargo, todos los ejemplos que he visto en línea parecen utilizar SOFTFAIL. Lo que me hizo cuestionar mi elección fue cuando vi las instrucciones de Google Apps para configurar SPF:

Cree un registro TXT que contenga este texto: v = spf1 incluye: _spf.google.com ~ all

Publicar un registro SPF que use -todos en lugar de ~ todos puede ocasionar problemas de entrega. Consulte los rangos de direcciones IP de Google para obtener detalles sobre las direcciones de los servidores de correo de Google Apps.

¿Los ejemplos son demasiado cautelosos al impulsar el uso de SOFTFAIL? ¿Existen buenas razones que hacen que el uso de SOFTFAIL sea una mejor práctica?

Bueno, ciertamente no era la intención de la especificación que se usara en su lugar: softfail está pensado como un mecanismo de transición, donde puede tener los mensajes marcados sin rechazarlos directamente.

Como ha encontrado, los mensajes fallidos tienden a causar problemas; algunos servicios legítimos, por ejemplo, falsificarán las direcciones de su dominio para enviar correos en nombre de sus usuarios.

Debido a esto, el softfail menos draconiano se recomienda en muchos casos como una forma menos dolorosa de obtener mucha de la ayuda que ofrece SPF, sin algunos de los dolores de cabeza; Los filtros de correo no deseado del destinatario aún pueden tomar el error de software como una fuerte pista de que un mensaje puede ser correo no deseado (que muchos lo hacen).

Si está seguro de que ningún mensaje debe provenir de un nodo que no sea el que ha especificado, entonces, por supuesto, use el error como lo pretendía el estándar SPF ... pero, como ha observado, el softfail definitivamente ha crecido más allá de lo previsto utilizar.

-todos deben usarse siempre SIN EXCEPCIÓN. No usarlo es abrirse a alguien que está falsificando su nombre de dominio. Gmail, por ejemplo, tiene un ~ todo. Los spammers falsifican direcciones de gmail.com todo el tiempo. El estándar dice que debemos aceptar correos electrónicos de ellos debido a ~ todos. Personalmente, no sigo el estándar en esto, porque me di cuenta de que la mayoría de ustedes ha configurado incorrectamente sus registros SPF. Hago cumplir ~ todos,? Todos, tal como lo haría con todos. Sintaxis SPF Errores SPF

En mi opinión, Google se basa no solo en SPF, sino también en DKIM y, en última instancia, DMARC para evaluar los correos electrónicos. DMARC tiene en cuenta tanto la firma SPF como la firma DKIM. Si cualquiera de los dos es válido, Gmail aceptará el correo electrónico, pero si ambos fallan (o fallan), esto será una clara indicación de que el correo electrónico puede ser fraudulento.

Esto es de las páginas DMARC de Google :

Un mensaje debe fallar tanto en las comprobaciones SPF como en DKIM para que también falle el DMARC. Una sola falla de verificación usando cualquiera de las tecnologías permite que el mensaje pase DMARC.

Por lo tanto, creo que se recomendaría usar SPF en modo softfail para permitirle ingresar al algoritmo mayor de análisis de correo.

Tal vez la razón por la que todavía se usa softfail es que muchos usuarios (correcta o incorrectamente) configuran el reenvío, tal vez desde su correo electrónico de trabajo a casa, esto sería rechazado si hardfail está habilitado