オンボーディングを始める前に、次を済ませてください。
- デプロイ経路を選びます。Email security には 2 つのデプロイ方式があります。API と BCC/Journaling 向けの 配信後（post-delivery） と、MX/Inline 向けの 配信前（pre-delivery） です。
- 判定（disposition）、なりすましレジストリ、送信（submission）について把握します。
- メール環境を正しく設定する手順を確認します。
次の表は、API、BCC/Journaling、MX/Inline で使える機能を比較したものです。
| 機能 | Microsoft 365 | Google Workspace | その他（オンプレミス / クラウド） |
|---|---|---|---|
| デプロイの種類 | API と MX | BCC と MX | MX のみ |
| API 連携 | Microsoft Graph API | BCC のみ | なし |
| BCC/Journaling | Microsoft Purview ポータルの Journal Rule を使います | BCC ルールを使います | ジャーナリングを使います |
| Inline/MX Mode | MX レコードを Cloudflare に向けます | MX レコードを Cloudflare に向けます | MX レコードを Cloudflare に向けます |
| メッセージの対処 | Read/Write API による auto-move | Read/Write API による auto-move | メッセージはインラインでブロック、隔離、または変更できます |
次の点に注意してください。
- すべてのメールプロバイダーが MX/Inline デプロイに対応しています。
- API または BCC/Journaling で Email security を連携する Microsoft 365 または Google Workspace のユーザーは、主に削除または配信後の 移動 でメールを変更できます。
- MX/Inline で Email security を連携する Microsoft 365 または Google Workspace のユーザーは、配信後の 移動、リンクアクション、テキストアドオン でメールを変更できます。
配信後デプロイを選ぶと、Cloudflare はメールがユーザーの受信トレイに届いたあとにスキャンします。
Microsoft 365 のユーザーの場合は、Microsoft Graph API または ジャーナリング で行います。
Google Workspace または Microsoft Exchange のユーザーの場合は、BCC で行います。
配信後デプロイは MX の変更が不要なため、時間を節約できます。メールフローも止めません。配信後デプロイでは、auto-move イベント を有効にしてメッセージを完全削除または論理削除できます。Microsoft Graph API または Google Workspace を使う場合は、ディレクトリ も同期できます。
配信前デプロイを選ぶと、Cloudflare はメールがユーザーの受信トレイに届く前にスキャンします。MX レコードは Cloudflare を指します。
配信前デプロイは、最も高い保護レベルを提供します。配信時に テキストアドオン またはリンク書き換えを適用します。
配信前デプロイは転送中の脅威をブロックし、ユーザーがメールを見る前にバナーやテキストを追加します。
判定を使うと、ポリシーの設定とレポートの調整ができます。たとえば、不審なメールを迷惑メールフォルダーへ移すポリシーを設定できます。
判定の詳細は Dispositions を参照してください。
ビジネスメール詐欺（BEC） ↗ の標的は、多くの場合、経営層や経理の役割です。なりすまされやすい役割のアドレスを追加する必要があります。ユーザーの追加方法は Impersonation registry を参照してください。
なりすましレジストリに含めたい役割の例は次のとおりです。
- 経営層（C-suite）
- 経理
- 人事（HR）
- IT ヘルプデスク
- 法務
役割は変わるため、なりすましレジストリは四半期ごとに見直してください。
送信（submission）は、初回スキャン後にメールの判定を変更することです。見逃し / 誤検知を直し、検出モデルを継続的に賢くするための、Cloudflare 組み込みのフィードバックループです。メッセージの再分類方法は レビュー用にメッセージを送信する を参照してください。
送信が重要な理由は次のとおりです。
- モデル精度の向上: 検証済みの送信は、新しい誘導、言い回し、インフラ、良性のパターンを Cloudflare の機械学習に教えます。
- アラート疲労の低減: ユーザーが実際に受け取りたい Suspicious や Spam のメールを修正すると、組織向けに検出が調整され、ダッシュボードのノイズが減ります。
- 対処ループの完了: 判定が Malicious に上がると、Cloudflare はそれらのメールをすべての受信トレイから自動で移動します（Graph API または Google Workspace API 連携）。
- 送信に対する操作の記録: 各送信には送信 ID、元の判定、要求された判定、最終判定などの詳細が表示されます。詳細は レビュー用にメッセージを送信する を参照してください。
送信を最大限に活かすには、次を行います。
- 送信を週次で確認します。
- MX/Inline デプロイには連携を関連付けます。連携を関連付けると、毎回 EML をアップロードする必要はありません。Cloudflare は API でメールメッセージのコピーを受け取れます。
- ユーザー送信 の増加を調査します（フィルターをすり抜けたフィッシングをユーザーが見つけた可能性があります）。アナリストの最終判定がポリシーと一致しているかも確認します。
送信を正しく使うと、手動調整を減らしつつ、Email security はより強い保護を提供します。
次のチェックリストに沿って、メール環境が正しく設定されていることを確認します。
| 手順 | 配信後 | 配信前 |
|---|---|---|
| 連携を認可する（Graph API または Google Workspace） | 必須1 | 必須 2 |
| MX/Inline ドメインに連携を関連付ける | 必須 | |
| ドメインの追加 / 検証 | 必須 | 必須 |
| MX レコード / コネクタを更新 し、下流のメールサーバーで Cloudflare の egress IP を許可する | 必須 | |
| なりすましレジストリ と 許可 / ブロック リストを投入する | 必須 | 必須 |
| パートナードメイン TLS と管理者隔離を設定する | 必須 | |
| テキストアドオン と リンクアクション を設定する | 必須 | |
| テストメールを送り、想定した判定で Monitoring > Email activity に表示されることを確認する | 必須 | 必須 |
デプロイ経路が決まったら、オンボーディングを始められます。