2つのとき SPF チェッカーはさまざまな検索数を表示するため、より安心できる数を選択しないでください。各ツールが何を測定したかを確立します。 1 つは評価されたパス上の DNS 依存の用語を表示することができ、もう 1 つはポリシー グラフを展開することができ、3 つ目はネットワーク クエリを表示することができます。これらの出力は、同じドメインを検査する場合でも、異なる質問に答えることができます。
カウンターの意味を聞く
RFC 7208セクション 4.6.4 再帰全体で評価される DNS 依存の用語を制限します。これは、単にすべてのTXT文字列、すべてのDNSパケットの数、あるいはトップレベルに目に見える形で書き込まれたインクルードの数ではありません。キャッシュされた回答では、より大きな論理用語の予算は付与されません。
他の制約も分離します。仕様のアドレス ルックアップを無効にする 主要な評価期間の上限に加えて、メカニズム固有の制限も設けられています。あるツールは 1 つの組み合わせた警告を表示し、別のツールは各カテゴリを公開する場合があります。すべての赤いラベルが同じ意味であると仮定するのではなく、正確な警告テキストと文書を保存してください。
両方のツールに同じフィクスチャを与えます
評価されたドメイン、接続 IP、送信者の ID、 HELO 関連する場合、リゾルバー ビューとクエリ時間。ツールがドメインのみを受け入れる場合は、そのカウントが静的推定、最悪の場合の分析、または特定の合成パスであるかどうかを確認します。ドメインのみのスキャンは、実際の接続の評価と自動的に同等になるわけではありません。
マクロを使用するポリシーの場合、不足している ID 入力が直接問題となる可能性があります。 IPv4とIPv6の両方が発生する場合は、別々に比較してください。 DNS応答または再現可能な制御されたフィクスチャを保存して、後でプロバイダーを変更したときに、想定されるツールの比較が異なるポリシーの比較にならないようにします。
小さな実例を見てみる
合成ポリシーを考えてみましょう。
v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all
下 RFC 7208 §4.6.2 そして RFC 7208 §5.6、 192.0.2.10の場合、インクルードが評価される前に明示的なアドレスが一致する可能性があります。別のアドレスの場合、評価はインクルードとそのネストされた依存関係に到達する可能性があります。グラフ展開ツールは、最初のメッセージのパスが到達しない場合でも、その分岐を表示することがあります。数値の違いについては説明が必要であり、どちらかのツールに欠陥があると自動的に判断する必要はありません。
数値カウントを比較するには、インクルード ターゲットを明示的にします。この合成治具では、 _spf.vendor.example SPFが 1 つだけあります TXTレコード, v=spf1 ip4:192.0.2.20 -all。 DNS取得が成功し、構文が有効で、追加の依存関係がなく、通常の状態であると仮定します。 メール送信元 親ドメインの評価。
- 入力192.0.2.10 : 親の最初の ip4 メカニズムが一致します。実際のパスは DNS に依存する用語を 0 つ評価し、インクルードにはアクセスしません。
- 入力192.0.2.20 : 親の ip4 が一致しません。インクルードが評価され、そのターゲット ip4 が一致し、親が pass を返します。実際のパスは、DNS に依存する 1 つの用語、つまり include を評価します。
- 入力192.0.2.30 : インクルード ターゲットは-all達し、失敗を返すため、インクルードは一致しません。親は自身の-allに到達し、失敗を返します。実際のパスは依然として 1 つの DNS 依存項を評価します。これは、以下と一致します。 RFC 7208 §5.2.
DNS に依存する用語の静的グラフの数は、どの接続が選択されているかに関係なく、このフィクスチャ全体で 1 です。親ポリシーの最初のTXT取得は必要ですが、それ自体は、この制限に対してカウントされる評価対象の条件の 1 つではありません。したがって、最初の入力の 0 と拡張されたグラフの 1 の表示は両方とも説明できます。これらは分析的に期待される結果であり、実行された測定値やネットワーク パケット数ではありません。
ここで、含まれているポリシーが 2 回のスキャンの間に変更されたと想像してください。新たにスキャンすると、別の依存関係ツリーが正当に公開される可能性があります。意見の相違をエスカレートする前に、タイムスタンプと実際の回答を保存してください。入力のないスクリーンショットは証拠としては弱いです。
最初の分岐点でトレースを比較する
評価された用語の並べたリストを作成します。レコードの選択、早期一致、再帰、 DNSエラー、マクロ拡張、カウント規則など、ツールが一致しない最初の箇所を見つけます。一方がエラーで停止し、もう一方が診断のために継続しているかどうかを確認します。診断拡張は、有効な完了した評価を示さなくても役立つ場合があります。
ツールが標準に矛盾しているように見える場合は、セクション参照を使用して最小限の合成フィクスチャと予想される動作を生成します。それを通常のサポート プロセスを通じてツール管理者に送信し、フィクスチャが行う機密の製造データを回避します。一貫性のないダッシュボードを一致させるためだけに本番環境を変更しないでください。
解決された証拠に基づいて決定を下す
1 人の送信者に対する有効なショート パスがすべての送信者の正常性を確立するわけではありません。代表的な正当な入力と一致しない入力をテストし、後で変更される可能性のある依存関係を検査します。逆に、大きな静的グラフ自体は、すべてのメッセージが評価期間の制限を超えていることを証明するものではありません。
どの測定結果が決定を裏付けるか、未解決のツールの制限事項、および提案された変更によって予想される影響を記録します。使用 メカニズムの順序付け それらの道を理解した後でのみ。結果的な矛盾を調整できない場合は、説明のつかない数値を確実性として提示するのではなく、現在の証拠を保持し、実装固有のレビューを求めてください。
決定を書面に残す
指定された 2 レコードのフィクスチャについて、親テキストと子のテキスト、入力アドレス、カウント定義、および予想される合格/不合格を保持します。 0/1/1 の値は分析的に評価された用語の数であり、測定されたDNSパケットや独立したツールの実行ではありません。ツールが異なる数量を報告する場合は、比較する前にラベルを付けます。エラー処理パスの不一致には、成功した検索から推定するのではなく、独自のフィクスチャが必要です。