SPF リダイレクトは、残りの認可決定を別のポリシーに委任します。これは、多くの場合 1 つの管理組織内で、複数のドメインが集中管理された承認とポリシーを共有する必要がある状況向けに設計されています。
これは include のエイリアスではなく、 -all後のバックアップでもありません。レコードを統合する前に、いつリダイレクトが実行されるかを理解することが重要です。 RFC 7208セクション 6.1 その動作を定義します。
委任条件を確立する
一致するメカニズムがなく、以前のエラーで評価が終了しておらず、リダイレクトが存在する場合、 SPFリダイレクト ターゲットを評価します。接続先 IP と送信者は変わりませんが、評価対象のドメインが対象になります。結果として得られる評価では、ターゲットでSPFが欠落しているという結果が得られます。 permerror 何もないのではなく。
外部レコードにすべてのメカニズムが存在する場合、リダイレクトは無視されます。すべての前にリダイレクトを配置しても、それは救われません。わかりやすくするために最後にリダイレクトと書きますが、これは左から右への一致メカニズムではなく修飾子であることに注意してください。
ローカルメカニズムは委任に先立って実行できます。たとえば、共有ポリシーが参照される前に、明示的な ip4 アクセス許可が一致する可能性があります。そのような例外が意図されているかどうかを決定します。そうしないと、中心となるはずのポリシーが認可の全体ではない可能性があります。
実用的な例: 2 つのドメイン、1 つの管理ポリシー
有効な構文と仮定すると、1 つが選択されます SPFレコード 名前ごとに、およびDNS取得が成功した場合、この合成フィクスチャでは、 east.example.comとwest.example.comがそれぞれ公開されます。 v=spf1 redirect=policy.example.com。共有ターゲットが発行する v=spf1 ip4:192.0.2.30 -all.
192.0.2.30の場合、各外部ポリシーが委任され、ターゲット ip4 が一致し、結果は合格になります。 192.0.2.31の場合、ターゲットは-allに達し、委任された結果は失敗します。ターゲットの場合 TXTレコード が消え、リダイレクトを必要とする評価ではpermerrorが生成されます。
次に、東のポリシーを次のように変更します。 v=spf1 ip4:198.51.100.8 redirect=policy.example.com。この追加アドレスは、共有ターゲットが許可していない場合でも、ローカルに渡されます。したがって、中央ポリシーの監査では、ターゲットのみをレビューするのではなく、すべての委任レコードを読み取る必要があります。
include で同じターゲットを比較します
代わりに外部ポリシーに次のものが含まれる場合、 v=spf1 include:policy.example.com ~all、子パスはインクルードと一致します。子の失敗は最終結果を提供しません。処理が再開され、外側の~all softfailを生成します。
リダイレクトは、呼び出されたときにターゲット ポリシーの結果を伝えます。 Include は、ターゲットが合格するかどうかを尋ね、合格しない場合は外部ポリシーの下で続行します。所有権モデル間を機械的に変換するのではなく、所有権モデルに一致する構造を選択します。
コンテキスト依存ルールの監査
リダイレクトは、送信者の入力を保持しながら、現在の評価ドメインを変更します。したがって、マクロとドメイン関連メカニズムは、使用するドメインまたは送信者の値に依存する可能性があります。あるドメインで機能するポリシーが、別のドメインでも自動的に安全になるとは限りません。
サードパーティの送信サービスの場合は、現在のドキュメントでサポートされている統合メカニズムを使用してください。 RFC 7208では、特にターゲット ポリシーがローカル部分に依存している場合、管理境界を越えたリダイレクトは確実に動作しない可能性があると警告しています。表示されるレコードを短くするためだけに、文書化されたインクルードをリダイレクトに置き換えないでください。
共有ポリシーを安全に運用する
すべての依存ドメインとローカル例外をインベントリします。共有ターゲットに 1 人の責任ある所有者を割り当てます。変更する前に、使用されているIPv6を含む、個別のポリシー コンテキストごとに許可された送信者と許可されていない送信者をテストします。元の委任記録と共有記録を一緒に保持します。
下 RFC 7208 §4.1 そして RFC 7208 §4.6.4、リダイレクトおよびネストされた用語に到達すると、 SPF DNS用語バジェットが消費されます。各ローカル レコードの短い長さに依存するのではなく、評価を通じてループと依存関係の増大を検出します。変更後、信頼できる回答と再帰的な回答を検査し、担当者が受信したメールをテストします。
実践的なポイント
リダイレクトは、共有ポリシーが本当に必要な場合に便利な一元化です。委任レコードからすべてを除外し、ローカル例外を監査し、委任後に存続する送信者のコンテキストをテストします。
決定を再現可能に保つ
east.example.comの場合、ローカル198.51.100.8例外は共有ターゲットを呼び出すことなく通過します。したがって、共有ターゲットの停止がその正確なパスに影響を与える必要はありません。リダイレクトを必要とする別のソースでは、ターゲット エラーが発生する可能性があります。一元化を承認する前に、外部レコード、送信者の入力、到達目標、および期待される結果を一緒に記録します。共有ポリシーの変更や停止テストは実行されませんでした。