施行の決定には、変更が起こる前にチームが説明できる証拠のしきい値が必要です。それ以外の場合は、健全なパーセンテージ、任意の待機期間、またはグリーンDNS結果が、どの正当なメッセージが危険にさらされているかを知る代わりになる可能性があります。
評価対象のビジネス フローとドメインに関する基準を定義します。その結果、特定の変更がなぜ正当化されるのか、何が不確実なままなのか、重要なメッセージが届かなくなった場合に誰が行動するのかを示す意思決定記録が得られるはずです。
決定を正確に定義する
正確なドメイン、その目的、検討中のポリシー変更を書き留めます。専用の受信ドメインに関する決定は、従業員のメールや新しく取得したブランドには自動的に適用されません。
承認所有者と、間違いによる運用上の影響を特定します。失敗した重要な通知は、何千もの通過する低リスク メッセージよりも重要である可能性があります。ボリュームが小さい場合でも、重要なフローを証拠基準に含めます。
を使用します。 政策選択ガイド 適合性を評価するため。より強力な評価は、すべてのドメインにとって自動的に目的地となるわけではありません。 RFC 9989 §7.4 特に、汎用メールおよびインターネット メーリング リストへの参加に関連します。
明らかに失敗する可能性がある基準を構築する
次の受け入れフレームワークは、独自の運用上の推奨事項です。これはプロトコルで義務付けられたチェックリストでも、すべての組織が同じリスク許容度を持っているという主張でもありません。
- 基準: 重要なサービスが既知であり、所有されている。それを裏付ける証拠: 承認されたアカウント、ルート、ビジネスオーナーにリンクされた在庫。決定をオープンにしておく理由: 重要なサービスには所有者がいない、または説明されていないルートがある
- 基準: 意図したアイデンティティが機能する。それを裏付ける証拠: 認証と認証を伴う、影響を受ける各ルートからの受信メッセージの証拠 アライメント 記録された。決定をオープンにしておく理由: DNSステータスまたは無関係の raw パスのみが利用可能である
- 基準: 周期的なフローがカバーされています。それを裏付ける証拠: 関連するビジネスサイクルをカバーする代表的なサンプルまたは文書化されたテスト。決定を保留する理由: 月次または年次サービスが検討されていない
- 基準: 間接的な使用が評価されます。それを裏付ける証拠: ルート固有の結果が得られた既知のフォワーダーおよびメーリング リストのケース。決定をオープンにしておく理由: スタッフリストへの参加は無視される
- 基準: 観察結果が正しく解釈されている。それを裏付ける証拠: サービス証拠とともに記載されている報告者、期間、エラー、既知のギャップ。決定をオープンにしておく理由: パーセンテージは完全な送信メール台帳として扱われます。
- 基準: リカバリを実行できます。それを裏付ける証拠: 指定された所有者、以前の記録、意思決定のトリガー、検証手順。決定をオープンにしておく理由: 誰も影響を受けるDNSを変更したり、サービスを回復したりすることはできません。
失敗した基準ごとに、所有者と次のアクションが生成される必要があります。証拠が添付されていないのに緑色のマークが付けられるチェックリストや、説明なしに「該当なし」と書いたチームに報酬を与えるようなチェックリストは避けてください。
メッセージレベルで身元証拠を調査する
重要なフローごとに、From ドメイン、SPF 評価された ID、関連する情報を保持します。 DKIM 署名ドメインと受信者の結果。どの受け渡し ID が該当するポリシーに基づいて調整されるかを示します。サービス独自のドメインの raw パスは、 DMARC 組織の From ドメインでの失敗。
また、通過メッセージとドメイン所有者の完全な参加を区別します。下 RFC 9989 §5.3.51 つの通過調整メカニズムは、適用可能なポリシーが存在する場合、メッセージ レベルのDMARC通過条件を確立できます。の参加要件は、 RFC 9989 §8 カバーを揃えた SPF およびDKIM 、レポート作成、ポリシー公開、およびその他のアクション。下 RFC 9989 §7.4、ドメイン公開拒否はSPFのみに依存してはならず、有効なDKIM署名を適用する必要があります。
実際にテストした内容を記録します。プロバイダーのデフォルトの送信者を介したデモンストレーションでは、運用アプリケーションが同じ ID またはアカウントを使用していることは証明されません。プロバイダーが複数のルートをサポートしている場合は、証拠の中でルートに名前を付けます。
総合的な意思決定の例を使用する
領収書、アカウントアラート、四半期の税金明細書という 3 つの既知のフローを備えた専用のサービス ドメインを想像してください。レシートとアラートには、現在受信したサンプルと明確な所有者が含まれています。四半期ごとのサービスは承認されていますが、運用署名状態はチェックされていません。
の 集計レポート レシートが大半を占める高い合格率を示しています。この観察は有用ですが、税金計算書のクリティカルフロー基準を満たしていません。次の正しいアクションは、代表的なテストを取得し、その意図された ID パスを確認することです。
その後の認可されたテストで不足している証拠が得られ、所有者が実稼働構成を確認したとします。レビュー担当者は、その新しい証拠を使用して変更を再検討できるようになります。これは合成的な進行です。ここでは、実際のテスト、測定された合格率、または承認は保証されません。
観察限界を公然と宣言する
レポートの構造と受信者の参加については、次のセクションで説明されています。 RFC 9990 §3.1 そして RFC 9989 §5.3.8。静かなレポート ウィンドウは、送信量の少なさ、受信者の参加が不完全、または認証の成功を反映している可能性があります。裏付けとなる証拠がなければ、どの説明が当てはまるかを立証することはできません。
したがって、固定日数は一般的な準備テストではありません。関連する期間は、ドメインのビジネス サイクルと該当するガイダンスによって異なります。インターネット メーリング リストを使用する可能性のあるドメインの場合は、注意が必要ですが、拒否することを検討してください。 RFC 9989 具体的なモニタリングと隔離の比較ガイダンスを提供します。それを一般的な 7 日間の約束に置き換えるべきではありません。
使用 モニタリングポリシーガイド 観察期間で何が明らかになることが期待されるかを定義します。証拠の欠如とサービスが送信しない証拠を分けて保管してください。
承認と回収を具体化する
承認メモでは、各基準をその証拠にリンクし、未解決のリスクを記録する必要があります。以前のDNS値と提案された正確な差分を保存します。行動できる人、検証計画、および見直しまたは回復を引き起こす条件を挙げてください。
回復は決定プロセスであり、即座に伝播することを約束するものではありません。 DNSキャッシュは、TTL 期限切れ後の古い回答の使用の認定など、以前の情報を保持できます。 RFC 8767 §4。影響を受けるサービス所有者と通信し、構成の観察結果が収束するまでの間、特定のルートを再テストする計画を立ててください。
変更が承認された後、実際のDNSと正当なフローの結果を検査し、変更をカバーするレポート期間を確認します。発見結果と是正措置を記録します。導入前に完了した承認フォームは、後の検証の代わりにはなりません。
証拠のしきい値は、チームが重要な正当な通信を説明し、ドメインに対して選択したポリシーを正当化し、予期しない結果から回復できるときに満たされます。サービス インベントリで基準を保持すると、次のアプリケーションまたはサプライヤーの変更を同じ基準に照らして評価できるようになります。
見直し可能な決定を記録する
3 つのフローの例では、たとえ領収書が健全な割合を占めていたとしても、代表的な証拠が到着するまで納税申告書基準をオープンのままにします。その決定は、遅延、正当化された範囲の狭さ、または責任ある所有者との明示的に受け入れられた制限である可能性があります。これらは編集ガバナンスのオプションであり、プロトコルの自動承認ではなく、この記事は実際の変更を承認するものではありません。