このガイドでは、正当な配送を維持しつつ、なりすましリスクを抑える検出設定の方法を説明します。
なりすまし検出を抑えるために なりすましレジストリ を設定したあと、レジストリ内のメールをセカンダリメールとして追加できます。セカンダリメールアドレスの追加方法は ユーザーを編集する を参照してください。
システム起因のなりすましイベントでは、配送の乱れを抑えるために 許可ポリシー の設定を推奨します。
セキュリティ水準を高く保つには、許可ポリシーの範囲をできるだけ狭くします。実際の送信者またはシステムを対象にする、具体的な式やメールアドレスから始めます。システムが複数のアドレスから送信する場合は、範囲を広げつつ、式は具体的に保ちます。ドメイン全体を許可する汎用ポリシーより、具体的なエントリを複数用意する方がよい場合があります。
許可ポリシー を設定するとき、条件に一致したメッセージの扱い方を選べます。
許可ポリシーは、人名をなりすますことがあるサービスに向いています。
定型トラフィックには、Sender verification (recommended) をオンにした Accept sender を使います。たとえば、Google Drive でファイルを共有すると、共有したユーザー名で通知が作られます。ただし、実際に使われるメールアドレスは Google のシステムアドレスです。
フィッシング検査が不要なメールには Trusted Sender を使います。リンク分析を含む、あらゆるフィッシング分析の対象外になります。
利用例:
- 一時ルール（過剰検出を避けるため）
- フィッシング訓練
- 確認用のワンタイムリンクを送るアプリケーション
- 静的 IP を優先する: リレーサーバーには、所有が明確な既知の静的 IP アドレスを使います。一時 IP アドレス ↗ は短命なため、ポリシーの精度が落ちることがあります。
- Sender Verification を必須にする: Cloudflare ダッシュボードでは、常に Sender Verification (Recommended) を有効にします。送信元システムのメール認証レコード（SPF ↗、DKIM ↗、DMARC ↗）をドメインと照合し、正当性を確認します。
- 未承認トラフィックを処理する: 未承認トラフィックは、組織内で承認されていないトラフィックです。シャドー IT ↗ とも呼ばれます。未承認のシステムがスパムやなりすましコンテンツを生成する場合は、text add-on を設定 して件名にタグを付け、メッセージを 自動で 迷惑メールフォルダーへ移動します。