SPFの「ハードフェイル」にもかかわらずメールが正常に配信されるのはなぜですか？

電子メールにSPFのマークが付いているにもかかわらず、偽造された電子メールが主要な電子メールプロバイダー（gmail.com、outlook.com）に配信されている理由を理解しようとしていますhardfail。メールはMicrosoft Exchangeにも配信さPermErrorれ、同じSPFレコードに対してがスローされます。

壊れたSPFレコードを定義するSOME_DOMAIN.comドメインを使用してメールを送信しています。電子メールは、SOME_DOMAIN.comのSPFレコードに明示的にリストされていない自分のIPアドレスから送信されます。SOME_DOMAIN.comのSPFレコードには次の3つのプロパティがあり、最初の2つはSPF RFC-4408の違反です。

1. のため、SPFレコード全体を解決するには、10を超えるDNSクエリが必要include:です。
2. SPFレコードの1つに構文エラーがあり、python-spfが解析エラーをスローします。
3. SPFレコードは、ルールの両方が含まれている~allと-all、両方のすべてのアドレスのセットがすべきことを言ってsoftfailやhardfail

admin@SOME_DOMAIN.comになりすましてoutlook.comアドレスに送信されたメールには、配信されたメールのSMTPヘッダーに次のエラーが含まれます。このメールは通常、ユーザーの受信トレイに配信されました：

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

Gmailもユーザーの受信トレイにメールを配信しますが、別のSPFエラーをスローします。

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

ここで何が起こっているのでしょうか？SPFにもかかわらずメールが配信されるのはなぜhardfailですか？壊れたSPFレコードがあるということは、他のSMTPサーバーがSPFを完全に無視するということですか？または私がここで見逃しているものがあります...

多くのサイトではSPFの設定が非常に悪いため、MTAを受信すると、多くの場合hardfail、通知のみとしてカウントされ、スパム検出スコアに含まれるだけです。最終的には、SPF障害の処理方法はMTAの管理者に任されています。

SPFエラー状態は、目的のポリシーについて何も示していません。そのため、メッセージを受け入れるかどうかについてのガイダンスは提供されていません。意図されたポリシーがである可能性があり+allます。この場合、メールの受付は正常です。Googleは、このドメインが標準に準拠していないことに寛容であるようです。

-all送信者アドレスを検証する場合、SPFポリシー拒否（）でも信頼できません。このようなメールを拒否することが不適切である場合がいくつかあります。

• 契約メーラーから送信されたメール（これらの人々は、ポリシーに違反した場合に支払いを受けます。）
• Webフォームおよびその他の自動システムから送信されたメール。
• メーリングリストまたはその他の転送メカニズムによって転送されたメール。そして
• SPFレコードの単なる誤った構成（一般的ではありませんが、十分ではありません）。

ハードフェールを延期できるかなり小さいサーバーを実行しています。これにより、正当な失敗をホワイトリストに登録できます。送信者がメールが配信されないことに気付いた場合、設定を修正することがあります。場合によっては、関連するに連絡を取ろうとしpostmasterますが、多くのドメインにpostmasterアドレスがありません。

より強力なポリシーを適用したいユーザーは、まだ標準ではないDMARCを使用できます。メールは引き続き配信される可能性がありますが、そのポリシーで指定されているように隔離または拒否される場合があります。ポリシーに失敗したメールは、通常の受信トレイではなく、スパムフォルダに配信される可能性があります。

SPFハード障害は、送信サーバーのIDを検証するために信頼できるようです。私はしばらく前にいくつかの調査を行いましたが、HELO名のソフトフェイルでさえ、着信メッセージを失敗または延期する合理的な理由であることがわかりました。

多くのメールサーバーにはSPFレコードがありません。メールサーバーにSPFレコードがない場合は、親ドメインに対してSPFレコードを確認します。これは非標準ですが効果的です。メール管理者には、PTRレコードにリストされているサーバーIPのSPFレコードがあることを確認することをお勧めします。サーバーは、PTRレコードから返された名前で自身を識別する必要もあります。逆引きDNS検証に対応するAレコードがあることを確認します。