SPFレコードでSOFTFAIL over FAILを使用することはベストプラクティスと見なされていますか？
または別の言い方をすると、v=spf1 a mx ~allを使用するよりも推奨v=spf1 a mx -all？ RFC は推奨事項を提示していないようです。私の好みは常にFAILを使用することでしたが、これにより問題がすぐに明らかになります。 SOFTFAILを使用すると、誰も気付かないため、誤って構成されたSPFレコードが無期限に保持されることが許可されます。
しかし、私がオンラインで見た例はすべて、SOFTFAILを使用しているようです。 SPFを構成するための Google Appsの手順 を目にしたとき、私の選択に疑問を投げかけました。
このテキストを含むTXTレコードを作成します：v = spf1 include：_spf.google.com〜all
〜allではなく-allを使用するSPFレコードを公開すると、配信の問題が発生する可能性があります。 Google Appsメールサーバーのアドレスの詳細については、Google IPアドレスの範囲をご覧ください。
SOFTFAILの使用を推し進めることにより、例は過度に注意深くなっていますか？ SOFTFAILの使用をベストプラクティスにする正当な理由はありますか？
まあ、それは確かにそれを代わりに使用するための仕様の意図ではありませんでした-softfailは、メッセージを完全に拒否することなくメッセージをマークできる移行メカニズムとして意図されています。
お気づきのように、完全に失敗したメッセージは問題を引き起こす傾向があります。たとえば、一部の正当なサービスは、ユーザーに代わってメールを送信するためにドメインのアドレスを偽装します。
このため、いくつかの頭痛の種がなくても、SPFが提供する多くの助けを得る痛みの少ない方法として、それほど厳格でないsoftfailが多くの場合に推奨されます。受信者のスパムフィルターは、メッセージがスパムである可能性があることを強く示唆するものとして、ソフトフェイルを受け取ることができます（多くの場合そうです）。
指定したノード以外のノードからメッセージが送信されないことが確実である場合は、必ず、SPF標準で意図されているとおりにfailを使用してください。使用する。
私の理解では、GoogleはSPFだけでなく、DKIM、そして最終的にはDMARCにも依存して電子メールを評価しています。 DMARCはSPFとDKIM署名の両方を考慮に入れます。どちらかが有効である場合、Gmailは電子メールを受け入れますが、両方が失敗（またはソフトフェイル）する場合は、電子メールが不正である可能性があることを明確に示します。
これは Googles DMARC-pages からです：
DMARCも失敗するには、メッセージがSPFチェックとDKIMチェックの両方で失敗する必要があります。いずれかのテクノロジーを使用した単一チェックの失敗により、メッセージはDMARCを通過できます。
したがって、メール分析のより優れたアルゴリズムに入ることができるようにするために、softfail-modeでSPFを使用することをお勧めします。
おそらくsoftfailがまだ使用されている理由は、多くのユーザーが（正しくまたは誤って）転送を設定しているためです（おそらく仕事用の電子メールから自宅へ）。hardfailが有効になっている場合、これは拒否されます。