迷惑メール対策を追加する前に。既存メール設定と運用を点検する

既存メール環境の全体像を把握する

メールフローとサーバ構成の確認

メールが社内外を行き来する経路を図に起こすと、どのサーバが中継し、どこで暗号化が行われているかが一目で分かります。まずは Exchange Online やオンプレミスのメールゲートウェイ、外部プロバイダーの設定画面から、受信・送信のルートをスクリーンショットで保存し、担当者と共有しましょう。

図を作成したら、実際にメールが届くまでにかかる時間や、転送設定が意図した通りに機能しているかをテストメールで確認します。テスト結果は Excel にまとめ、担当者別に「問題なし」「要修正」のステータスを付けて管理すると、次のステップでの優先度が見えてきます。

ユーザー権限と配信ルールの整理

メール配信には配信リストや配信グループ、転送ルールが多用されますが、権限が過剰に設定されていると不正利用のリスクが高まります。管理コンソールで全ユーザーの「メール転送設定」「外部転送許可」「配信リストへの参加権限」を抽出し、業務上必要なものだけを残す方針を立てます。

たとえば、営業部門の外部転送は許可するが、経理部門は内部だけに限定する、といった具体的な基準を文書化し、担当者に確認を取ります。変更後は変更履歴を記録し、定期的に権限見直しミーティングを設定すると、権限の肥大化を防げます。

ログ保存期間と監査設定の点検

メールの送受信ログは不正アクセスや誤配信の証拠になる重要情報です。Microsoft 365 の監査ログ保存期間はプランにより異なります。組織の要件に合わせて現在の保存期間を確認し、必要に応じて 90 日以上の保持を検討してください。

保存期間が短い場合は、追加ストレージやアーカイブ機能の導入を検討します。また、監査ログの自動エクスポート設定が有効かどうかを確認し、エクスポート先のフォルダ権限も併せて見直すと、ログが改ざんされるリスクを低減できます。

実際に過去 30 日分のログを抽出し、検索クエリで異常な送信パターンがないかを確認する作業を、月次で実施する体制を整えておきましょう。

フィッシング・なりすまし対策の設定確認

SPF・DKIM・DMARCの設定状態

送信ドメインの正当性を証明する SPF、DKIM、DMARC は、フィッシングメールをブロックする基本的な防御です。まずは DNS 管理画面で自社ドメインの SPF レコードが正しく記述されているか、送信元 IP がすべて列挙されているかを確認します。

次に DKIM の公開鍵が最新かつ有効期限が切れていないかをチェックし、必要ならキーのローテーションを計画します。

DMARC ポリシーは「p=none」から「p=quarantine」または「p=reject」へ段階的に強化することが推奨されますが、変更前にテストレポートを 7 日間取得し、正当なメールがブロックされていないかを確認します。

設定変更は DNS の TTL を短く設定し、影響範囲を限定しながら実施すると安全です。

メール認証エラーの対応手順

認証エラーが発生した際の対応フローが未整備だと、正規メールが届かず業務に支障が出ます。まずはエラーメール（NDR）を自動で受信トレイに集めるルールを作成し、エラー種別ごとに担当者を割り当てます。たとえば SPF 失敗はシステム管理者、DKIM 失敗はメール配信担当者が対応するようにします。

エラー内容をテンプレート化し、原因調査と修正手順を文書化しておくと、迅速な復旧が可能です。さらに、エラーが頻発するドメインはサプライヤーに連絡し、認証設定の見直しを依頼するプロセスも合わせて整備しておくと、外部からのメール送信リスクを低減できます。

インシデント報告体制の確認

フィッシングやなりすましが疑われるメールを受け取った際の報告先が曖昧だと、被害が拡大する恐れがあります。社内ポリシーで「疑わしいメールは件名に『[PHISHING]』と付け、専用のメールアドレス（security@example.jp）へ転送する」ルールを明文化します。

報告を受けた担当者は、メールヘッダー情報を取得し、送信元 IP、認証結果、添付ファイルのハッシュ値を記録します。その後、IPA のガイドラインに沿ってインシデント対応手順書を用いて初動対応を行い、結果を月次レポートにまとめます。

報告体制が明確になることで、全社員が迅速に疑わしいメールを共有でき、組織全体の防御力が向上します。

添付ファイルとマルウェア検知の運用点検

添付ファイルサイズ制限と例外設定

大容量の添付ファイルは業務上必要ですが、サイズ上限が緩すぎるとマルウェアの拡散リスクが高まります。まずは現在設定されている送受信サイズ上限を確認し、業務で必要な最大サイズを基準に見直します。添付を制限すると業務が止まる部署があれば、許可するファイルの条件と、受取人を限定できる別の共有方法を検討します。

容量や形式の制限は自社の利用状況と提供元の仕様を確認して決め、正規の連絡が届くかも試験してください。例外設定を行う際は、対象ユーザーと期間を明示した承認フローを設け、変更履歴を管理ツールに記録します。こうした制限は、マルウェアの添付率を低減させるだけでなく、メールサーバの負荷軽減にもつながります。

マルウェアスキャンエンジンの選定基準

Microsoft 365 では標準でマルウェアスキャンが提供されていますが、検出率や検査対象の拡張性はプランにより差があります。まずは現在有効化されているスキャンエンジンのバージョンと検出率レポートを確認し、過去 3 カ月の検出件数と誤検知件数を比較します。

次に、業界標準の AV ベンダーが提供するサードパーティ製スキャンエンジンとの相性を評価し、導入候補のスキャンエンジンで、既存環境と比較して検出率が向上するかどうかを評価します。選定時の判断基準は「検出率」「誤検知率」「管理負荷」「コスト」の 4 つとし、評価シートに数値化して記入します。

最終的に、コストパフォーマンスが高いものを本番環境に導入し、導入後は月次で検出レポートをレビューします。

検出結果の通知方法と対応フロー

マルウェアが検出された際の通知が遅れると、被害拡大のリスクが高まります。まずは検出メールを自動で管理者グループに転送するルールを設定し、件名に『[MALWARE]』と付与します。通知を受けた担当者は、即座に該当メールを隔離し、添付ファイルのハッシュ値を VirusTotal 等のオンラインサービスで二重チェックします。

その後、影響範囲を特定し、対象ユーザーへパスワード変更や端末の再スキャンを依頼する手順書を作成します。対応完了後は、インシデント管理ツールに処理結果と再発防止策を記録し、次回のレビューで改善点を抽出します。通知と対応が標準化されることで、迅速かつ一貫したマルウェア対策が実現します。

誤検知・支払い承認フローの改善策

誤検知時の例外リスト作成手順

正当なメールがスパムとして誤検知されると、業務が止まります。まずは過去 6 カ月分の誤検知レポートを抽出し、誤検知が頻発する送信元ドメインやアドレスを一覧化します。次に、これらの送信元を例外リストに追加する手順を文書化し、例外追加は「情報システム部長の承認」後にのみ実施できるようワークフローを設定します。

例外リストは CSV 形式で管理し、変更時には変更履歴と承認者を必ず記録します。また、例外追加後は 2 週間ごとに効果検証を行い、不要になった例外は速やかに削除する運用ルールを併せて策定します。これにより、誤検知による業務停止リスクを最小限に抑えられます。

支払い承認メールの二段階確認策

請求書や支払い承認のメールはフィッシングの標的になりやすく、誤って送金してしまうケースが報告されています。まずは支払い承認フローに「送信元ドメインの認証チェック」と「二段階認証（OTP）による承認」 の二つのチェックポイントを追加します。

具体的には、支払い依頼メールが届いたら、メールヘッダーで DKIM/DMARC が合格しているかを自動で表示し、承認者は別途送られる OTP を入力して承認します。OTP は組織の運用に適した送信手段（専用アプリ、SMS など）で提供し、有効期限は業務フローに合わせて設定してください。

二段階確認を導入することで、なりすましメールによる誤送金リスクの低減が期待できます。

改善後の評価指標と定期レビュー

対策を実施したら、効果を数値で把握し続けることが重要です。評価指標としては「誤検知件数」「フィッシング検出率」「支払い承認エラー件数」「対応平均時間」の 4 つを設定し、月次でダッシュボードに集計します。指標が目標値を下回った場合は、原因分析を行い、設定見直しや教育研修の追加を検討します。

また、年に一度は全体レビュー会議を開催し、最新の脅威情報や社内業務変化に合わせてポリシーを更新します。評価とレビューを定期的に行うことで、常に最適なメールセキュリティ体制を維持できます。