libspf2（C）とMail::SPF::Query（perl、sendmail-spf-milterで使用）の両方で、10のDNS発生メカニズムの制限が実装されますが、後者はMXまたはPTR制限を適用しません（AFAICT）。mxとptrもlibspf2それぞれ10に制限します。
Mail::SPF（perl）には、DNSを引き起こすメカニズムが10個、メカニズムごと、MXごと、PTRごとに10ルックアップの制限があります。（2つのperlパッケージは、デフォルトではありませんが、一般的にMIMEDefangで使用されます。）
pyspf「ルックアップ」、MX、PTR、CNAMEのすべてに10の制限があります。ただし、操作中にMAX_LOOKUPSを明示的に4倍します。「strict」モードでない限り、MAX_MXとMAX_PTRを4倍にします。
商用/専有の実装についてコメントすることはできませんが、上記（を除くpyspf）は10のDNSトリガーメカニズム（以下で詳細）の上限を明確に実装します。時間。
それが12含まれており、私は「PermErrorという」を返すために最もSPFソフトウェアを期待する10の限界を超えたということです、あなたが正しい、あなたの特定のケースでは、しかし、失敗は最終的に影響を与えますプロバイダ（複数可）「が含ま」カウント理由SPF メカニズムは左から右に評価され、チェックはパスで「早期に」行われるため、送信サーバーが表示される順序によって異なります。
これを回避する方法は、DNSルックアップをトリガーしないメカニズム（例：ip4やip6）を使用しmx、可能であれば最大10個の名前を取得し、それぞれが複数のIPを持つことができるようにすることです。
SPFは指数関数的なスケーリングの可能性がある任意のDNS要求をもたらすため、DOS /増幅攻撃に簡単に悪用される可能性があります。これを防ぐために、意図的に低い制限があります：必要な方法でスケーリングしません。
ただし、 DNSルックアップを引き起こす 10のメカニズム（厳密なメカニズム+「リダイレクト」修飾子）は、10のDNSルックアップとまったく同じではありません。「DNSルックアップ」でも解釈が可能です。必要な個別のルックアップの数が事前にわからず、再帰リゾルバーが実行する必要のある個別のルックアップの数もわかりません（以下を参照）。
RFC 4408§10.1：
SPF実装では、DNSルックアップを行うメカニズムと修飾子の数を、SPFチェックごとに最大10に制限する必要があります。これには、「include」メカニズムまたは「redirect」修飾子の使用に起因するルックアップが含まれます。チェック中にこの数を超えると、PermErrorが返されなければなりません。「include」、「a」、「mx」、「ptr」、および「exists」メカニズム、および「redirect」修飾子は、この制限に対してカウントされます。「all」、「ip4」、および「ip6」メカニズムはDNSルックアップを必要としないため、この制限にカウントされません。
[...]
「mx」および「ptr」メカニズム、または％{p}マクロを評価する場合、検索およびチェックされるMXまたはPTR RRの上限は10以下でなければなりません。
したがって、DNSルックアップをトリガーする最大10のメカニズム/修飾子を使用できます。（ここでの表現は貧弱です：制限の上限のみを述べているようで、確認実装には2の制限があります。）
mxメカニズムの場合は5.4 、ptrメカニズムの場合は§5.5にはそれぞれ、その種類の名前の10回のルックアップの制限があり、そのメカニズムの処理にのみ適用されます。例：
サービス拒否（DoS）攻撃を防ぐために、「mx」メカニズムの評価中に10個を超えるMX名を検索してはなりません（セクション10を参照）。
つまり、最大10 MX名の10 mxメカニズムがあり、それぞれが20のDNS操作（それぞれ10 MX + 10 A DNSルックアップ）を合計200発生させる可能性があります。ptrまたは％{p}についても同様です。 10のルックアップすることができるPTRの 10×10 PTRSしたがって、メカニズムを、各PTRも再びAルックアップ、200の合計を必要とします。
これは、2009.10テストスイートがチェックするものです。「処理制限」テストを参照してください。
SPFチェックごとのクライアントDNSルックアップ操作の総数に明確に記載された上限はありません。暗黙的に210、ギブまたはテイクとして計算します。また、SPFチェックごとのDNSデータの量を制限する提案もありますが、実際の制限は提案されていません。SPFレコードは450バイトに制限されているため（おおよそ他のすべてのTXTレコードと共有されています）、大まかな見積もりを取得できますが、寛大な場合は合計が100kiBを超える可能性があります。どちらの値も増幅攻撃として悪用される可能性があることは明らかです。これはまさに、10.1で回避する必要があると言われていることです。
合計 10個のルックアップメカニズムがレコードに一般的に実装されていることが経験的に証明されています（microsoft.comのSPFを確認してください。必須のエラーコードは単に「PermError」であり、あらゆる種類の問題をカバーしているため、あまりにも多くのルックアップエラーの証拠を収集するのは困難です（DMARCレポートがそれを助けるかもしれません）。
OpenSPF FAQ は、より正確な「10 DNSがメカニズムまたはリダイレクトを引き起こす」のではなく、合計「10 DNSルックアップ」の制限を永続化します。このFAQは、実際には次のように書かれているため、間違いです。
SPFレコードごとに10個のDNSルックアップの制限があるため、IPアドレスを指定する[...]
これは、「SPFチェック」操作に制限を課し、この方法でDNSルックアップ操作を制限せず、SPFレコードが単一のDNSテキストRR であることを明確に示すRFCと一致しません。FAQは、新しいSPFレコードである「include」を処理するときにカウントを再開することを意味します。なんて混乱だ。
DNSルックアップ
とにかく「DNSルックアップ」とは何ですか？ユーザーとして。「ping www.microsoft.com」は単一のDNS「ルックアップ」を含むと考えます。1つのIPに変換する予定の名前が1つあります。シンプル？悲しいことではありません。
管理者として、www.microsoft.comは単一のIPを持つ単純なAレコードではないかもしれないことを知っています。これは、CNAMEである可能性があります。デスクトップ上のリゾルバではなく。今日、私にとって、www.microsoft.comは3つのCNAMEのチェーンであり、最終的にakamaiedge.netのAレコードになります。これは（少なくとも）誰かのための4つのDNSクエリ操作です。SPFは「ptr」メカニズムでCNAMEを参照する場合がありますが、MXレコードはCNAMEであってはなりません。
最後に、DNS管理者として、（ほぼ）すべての質問に答えるには、多くの個別のDNS操作、個々の質問と回答トランザクション（UDPデータグラム）が関係することを知っています。ダウン：. → com→はmicrosoft.com→ www.microsoft.com必要に応じて、レコード（NS、Aなど）の特定の種類を求め、そしてのCNAMEを扱います。を使用するとdig +trace www.microsoft.com、これを実際に見ることができますが、おそらくジオロケーションのトリック（ここの例）のためにまったく同じ答えは得られません。（TXTレコードのSPFピギーバックとDNS回答の512バイトという古い制限により、TCPを介したクエリの再試行が行われる可能性があるため、この複雑さにはもう少し多くあります。）
では、SPFはルックアップとして何を考慮しますか？管理者の視点に最も近いので、各タイプのDNSクエリの詳細に注意する必要があります（ただし、個々のDNSデータグラムまたは接続を実際にカウントする必要がある点に注意する必要はありません）。