保険会社のブローカー ネットワークは 1 つの送信システムではありません。ブローカーは、独自のドメインから書き込みをしたり、承認された保険会社ブランドのサービスを使用したり、保険契約通知を転送したりできます。キャンペーン サプライヤーとポリシー管理プラットフォームは、さらにルートを追加します。認証を構成する前に、各関係でどの ID の使用を許可するかを決定します。
ブローカー関係を正確に分類する
ブローカーが独自のドメインで通信するか、保険会社が制御する From ドメインで通信するかを記録します。独自の ID を使用するブローカーは、そのドメインの認証を管理する必要があります。そのメッセージは、単に保険会社に言及しているという理由だけで保険会社ドメインのメッセージになるわけではありません。保険会社のドメインが承認されている場合は、特定のアプリケーション、テナント、目的、および責任のある保険会社の所有者を記録します。
一部のメッセージを修復する必要があるからといって、ブローカー ネットワーク全体に広範囲の送信者権限を追加しないでください。各承認には、ビジネス上の正当な理由と既知の技術的な実装が必要です。転送は、保険会社としての送信とも異なります。どの制御が失敗したかを判断する前に、実際のメッセージ ID と信頼できる受信者の結果を検査します。
キャンペーンをポリシーサービスの想定から遠ざける
アウトソーシングされたキャンペーンでは、さまざまなアプリケーション、オプトアウト プロセス、テンプレート、ポリシー通知の受信者を使用できます。キャンペーン所有者とポリシーサービス所有者を別々に記録します。認証は、市場への許可、ポリシー文言の有効性、または開示義務の履行を確立するものではありません。該当するビジネスおよび法的レビューを通じてそれらの問題を検証します。
キャンペーン サプライヤーの場合は、顧客固有のドメイン構成、セレクター、資格情報の所有者、および終了プロセスを特定します。ポリシーの管理、テストの更新、承認、および顧客にとって重要なその他の頻度の低い通知。ニュースレターのテストでは、更新処理者は検証されません。サプライヤーがカスタムを提供するという声明 DKIM 保険会社のテナントに対して有効であることを証明するものではありません。
認証の有効期限を設定する
ブローカーまたはサプライヤーの関係がいつ開始および終了するか、範囲の変更を誰が承認できるか、終了時にどの署名権限を削除する必要があるかを記録します。キューに入れられた正規の通知が誤って取り残されないように、退職したサプライヤーが古い権限で送信を続けることができないように順序を計画します。アクティブな移行と承認されたロールバックのニーズを調整せずに契約終了日が過ぎたという理由だけでDNSレコードを削除しないでください。
承認された合成ポリシー レコードをテストに使用します。表示されている From アドレス、実際の署名ドメイン、および返信先を検査します。返信に保険契約者データが含まれている場合は、サプライヤーの付随テスト メールボックスではなく、承認された運用システムに返信します。保管サンプルを最小限に抑え、組織のポリシーに従ってアクセスを制限します。
例外レコードの境界を説明する
仮想マップは、保険会社ブランドのブローカー ID、キャンペーン ID、および保険契約通知 ID を使用します。すべてのブローカーが保険会社のドメインを使用する必要があるという意味ではありません。保険契約通知にはpolicy.insurer.exampleと有効な DKIM署名 d=provider.example.net.その署名は厳密なDKIMに合格しません アライメント;妥当性は仮定されており、ここでは検証されません。
例外には、影響を受ける通知の種類、所有者、理由、補償プロセス、および次回のレビュー日を指定する必要があります。ブローカーのオンボーディング、サプライヤーの交換、ポリシー システムのリリース後に例外を確認します。在庫を規制遵守の評価や保険契約の内容とは区別して保管します。これらの仮説上のアイデンティティによってそのような決定は行われません。
ブローカーの終了と保留中の更新を調整する
承認された更新通知がポリシー システムのキューに残っている間に、ブローカーの送信委任が終了する予定であるとします。どのサービスがその通知を所有しているか、またその権限が廃止されるブローカーから独立しているかどうかを判断します。チェックリストを完了するためだけに、すべてのブローカー権限を無期限にアクティブにしたままにしたり、関連するすべてのDNSレコードを削除したりしないでください。責任ある所有者に範囲指定された移行を承認してもらい、残りのポリシーのワークフローを確認してもらいます。これらは仮説上の条件であり、実際の保険会社や契約上の決定ではありません。
ルート インベントリでは、承認された保険会社ブランドのブローカー メールについてはbrokers.insurer.example 、マーケティングについてはcampaign.insurer.example 、保険サービスについてはpolicy.insurer.exampleを個別に記録できます。これらは例示的なアイデンティティと役割であり、署名された見本や実際の助成金が提供されたものではありません。独自のドメインの下で通信するブローカーは、別個のアイデンティティ モデルのままです。暗号化テスト、通知の配信、または取り消しは実行されませんでした。
認証をその制限内で解釈する
RFC 9989セクション 4.4 および 5.3.5 署名の有効性、整合性、完全性を区別する DMARC 評決。単一の仮定された非整列署名は、他の整列されたDKIMの不在または整列された DKIM の通過を確立しません。 SPF パス。のために p=reject デプロイメントでは、セクション 7.4 および 8 では、 SPFのみに依存するのではなく、有効なDKIMが必要です。セクション 5.4 では、処理は受信者のポリシーに委ねられており、メッセージのビジネス内容は検証されません。これらのプロトコル境界は、承認されたワークフロー、アクセス、タイミング、または受信者のチェックに代わるものではありません。