反復可能なオンボーディング プロセスは、顧客の境界から始まります。レポートを収集したり、 DNS変更を提案したりする前に、どの法人、ドメイン、アプリケーション、管理者が対象となるかを確認してください。共有サービスは、販売スプレッドシートまたはパブリックDNSルックアップに表示されるドメインから顧客の権限を推測すべきではありません。
サービス境界を確立する
顧客のスポンサー、技術所有者、 DNS管理者、MSP アナリスト、変更承認者、およびインシデントの連絡先の名前を指定します。担当者の責任とバックアップ範囲を記録します。合意されたオンボーディング プロセスを通じて権限を確認し、現在の段階で必要な範囲限定のアクセスのみを許可します。レポートの読み取りと認証レコードの変更は別個の権限です。
ビジネス目的、アプリケーション所有者、表示される From ドメイン、エンベロープ ドメイン、署名ドメイン、および予想されるアクティビティ サイクルを含む送信者登録を作成します。スケジュールされたサービスと少量のサービスが含まれます。短い観察期間内に不在があったとしても、サービスが使用されていないという証拠にはなりません。 RFC 9990 集計レポート 報告されたメッセージアクティビティを説明します。これらは信頼できるアプリケーション インベントリではありません。
段階的な受け入れを行う
まず目録と証拠の収集を受け入れます。次に、既知の送信パスを評価し、障害について説明します。次に、正確な差分、承認、ロールバックの条件を指定して変更を提案します。最後に、実際のアプリケーションからのメッセージと受信側の結果を使用して、意図したフローを検証します。 DMARC 依存している アライメント 同様に SPF または DKIM 下の認証 RFC 9989したがって、一般的なパス ラベルでは十分ではありません。
テンプレートにオンボーディングが完了していると記載されているからといって、すべてのドメインを強制ポリシーに移動しないでください。例外、未解決の送信者、転送者、およびメーリング リストのパスを記録します。残留リスクを誰が受け入れるか、証拠がいつレビューされるかを定義します。ポリシーの決定は、顧客のメールの依存関係と承認に従う必要があります。
2 つのオンボーディング ホールドを別々に保つ
顧客の請求アプリケーションに現在承認済みの aligned-pass サンプルがあるが、その四半期通知機能が実行されておらず、代替DNS承認者が未確認であると仮定します。テスト済みスコープの請求証拠を受け入れ、通知者を未テストとして保持し、それに依存する前に承認フォールバックを解決します。完了した導入チェックリストでは、これらのギャップを運用上の受け入れに変えることはできません。
これらは仮説上のオンボーディングの決定であり、顧客に提供されたランブックや実行された完全性チェックではありません。各段階で、責任者、正確な受領証拠、および未解決の状況を記録します。終了計画時には、将来のスクリプトによってアクセスが削除されることを約束するのではなく、責任のあるシステムを通じてアクセスの取り消しの確認を要求します。ここでは、顧客の承認、 DNS書き込み、またはレポートの取り込みはアサートされません。
業務を引き継ぎ、撤退を計画する
現在のドメイン登録、承認済みの設定、未解決の例外、およびエスカレーション ルートを顧客に提供します。レポートの可用性、監視対象範囲、保持責任を指定します。 MSP が何を測定できるのか、また顧客、 DNSホスト、受信者に何が依存するのかを説明します。認証が成功しても、受信トレイへの配置が約束されるわけではありません。
終了計画では、エクスポート形式、許可された受信者、アクセスの取り消し、保持されている監査証拠、および削除の責任を特定する必要があります。オフボーディング中に有用な認証レコードを自動的に削除しないでください。顧客は依然としてそれらに依存している可能性があります。技術的責任を移譲し、継続的なメール フローをテストし、承認された計画に基づいてアクセスを廃止します。所有権、アプリケーション、またはビジネスクリティカルなフローが変更されるたびにサービスを確認してください。