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が提供する多くのヘルプを引き続き得るための、より痛みの少ない方法として、多くの場合、それほど厳しくないソフトフェイルが推奨されます。受信者のスパムフィルターは、メッセージがスパムである可能性があるという強力なヒントとして、ソフトフェイルを引き続き使用できます（多くの場合）。

指定したノード以外のノードからメッセージが送信されることはないと確信している場合は、必ずSPF標準が意図したとおりにfailを使用してください。つかいます。

-allは常に例外なしで使用する必要があります。使用しないことは、ドメイン名をスプーフィングする誰かに自分を開放することです。たとえば、Gmailには〜allがあります。スパマーはgmail.comを常にスプーフィングします。標準では、〜allのためにそれらからの電子メールを受け入れる必要があるとされています。私はあなたのほとんどがあなたのSPFレコードを間違って設定していることに気付いたので、私はこれに関する標準には従いません。〜all、？all、-allと同じように強制します。 SPF構文 SPFの間違い

私の理解では、GoogleはSPFだけでなく、DKIM、最終的にはDMARCにも依存して電子メールを評価しています。DMARCは、SPFとDKIM署名の両方を考慮します。いずれかが有効な場合、Gmailは電子メールを受け入れますが、両方が失敗（またはソフトフェイル）した場合、これは電子メールが不正である可能性があることを明確に示します。

これは、GoogleのDMARCページからのものです。

DMARCにも失敗するには、メッセージがSPFチェックとDKIMチェックの両方に失敗する必要があります。いずれかのテクノロジーを使用した単一チェックの失敗により、メッセージはDMARCを通過できます。

したがって、メール分析のより優れたアルゴリズムを使用できるようにするには、softfail-modeでSPFを使用することをお勧めします。

おそらく、ソフトフェイルがまだ使用されている理由は、多くのユーザーが（正しいか間違って）職場のメールから自宅への転送をセットアップしているためです。