メインコンテンツまでスキップ

メール非機能要件の整理

はじめに​

メール要件の議論は、SPF/DKIM/DMARCなどの設定論に寄りがちです。
ただし、企業が多数の顧客へ送信するケースでは、次の観点を一体で設計しないと事故を防げません。

  • 攻撃を防ぐ（なりすまし、アカウント侵害、漏えい）
  • 早く検知する（不審送信、設定改変、権限逸脱）
  • 被害を限定する（配信停止、鍵失効、顧客影響の最小化）

本記事は、まず共通の棚卸しを行い、その後は「企業から多数顧客への送信（通知、認証、請求、販促）」に焦点を固定して、セキュリティ非機能要件を5ステップで整理します。

Step 1：共通整理（対象・資産・責任分界）​

まずは、利用形態を問わず共通で整理します。

整理対象

  • 送信対象: 顧客向け通知、認証コード、請求、キャンペーン
  • 資産: 送信ドメイン、DNS、配信基盤、顧客アドレス、テンプレート、配信ログ、監査ログ
  • 境界: アプリ⇔メール配信基盤、管理者⇔運用画面、自社⇔外部MTA
  • 連携: IdP/SSO、SIEM、DLP、CRM、外部配信ベンダ

責任分界の決め方

  • SaaS/ベンダ: 基盤保護、可用性、標準セキュリティ機能
  • 自社: ドメイン認証設定、権限管理、監査、運用手順、インシデント対応
  • 委託先がある場合: 操作権限と監査責任を契約で明文化
Tips：Step 1の出口を明確にする

Step 1の完了条件は、資産一覧と責任分界表がレビュー可能な状態で揃うことです。
ここが曖昧だと、以降の要件が「誰の責任で実装・運用するか」で止まります。

Step 2：B2C前提の脅威モデルと優先順位​

ここからは「企業→多数顧客送信」に前提を固定します。
評価軸は、単発被害ではなく「同時多発・大量影響」です。

優先脅威

  • なりすまし送信（顧客への偽通知、偽請求）
  • フィッシング/BECへの悪用（ブランド毀損、問い合わせ急増）
  • 管理アカウント侵害（大量不正配信、設定改ざん）
  • 誤送信・設定ミス（誤宛先配信、テンプレート誤配布）
  • 個人情報漏えい（転送設定悪用、権限過大）

B2Cで重く見るべき観点

  • 影響人数: 一度に何人へ波及するか
  • 検知遅延: 異常検知まで何分かかるか
  • 封じ込め時間: 送信停止・鍵失効まで何分か
  • 説明責任: 顧客案内と監督当局対応に必要な証跡があるか
Tips：脅威モデルは「1件」ではなく「1万件」で考える

B2Cでは、同じ設定ミスでも顧客影響が桁違いになります。
要件は「最大同時影響」を基準に設計すると、優先順位がぶれません。

Step 3：B2C向けセキュリティ要件（予防コントロール）​

3-1. 送信真正性・ブランド保護​

  • SPF: 送信元棚卸しを前提に設計し、不要includeを抑制
  • DKIM: 送信系統ごとに署名、鍵ローテーション周期を規定
  • DMARC: noneから開始し、quarantine、rejectへ段階移行
  • ドメイン分離: notify、billing、promoなど用途別に分割
  • 表示名/署名ポリシー: 顧客が判別できる一貫ルールを定義

3-2. ID・権限・管理面保護​

  • SSO必須化、ローカルIDを原則廃止
  • フィッシング耐性の高いMFA方式を優先
  • 特権分離: 送信設定変更、テンプレート公開、鍵管理を分権
  • API鍵/SMTP認証情報の保護: Vault管理、漏えい時の即時失効手順
  • 管理画面アクセス制御: 条件付きアクセス、管理端末制限

3-3. 情報漏えい・誤送信対策​

  • 外部転送は原則禁止、例外は承認制
  • DLP: 個人情報・機密キーワード・添付分類と連動
  • 誤送信防止: 送信保留、宛先上限、ドメイン警告、承認フロー
  • テンプレート統制: 本番反映前レビューと差分記録
  • 添付ポリシー: 原本添付を制限し、保護リンク方式を優先

3-4. 外部ベンダ連携の統制​

  • Webhook署名検証、送信元IP制限
  • ベンダ側操作ログの取得要件を契約に明記
  • 本番と検証環境の分離、顧客データのマスキング
  • 委託先アカウントは期限付き権限を原則化

Step 4：監視・検知・インシデント対応（運用コントロール）​

予防だけでは不十分なので、「検知して止める」要件を先に決めます。

監視・検知

  • DMARC集計/失敗レポートの定常監視
  • 送信量急増、苦情率急増、解除率急増のアラート
  • 管理者権限変更、転送ルール追加、認証失敗急増の監視
  • 通常時ベースラインとの差分検知（時間帯、送信元、テンプレート）

インシデント対応（最小Runbook）

  • 封じ込め: 配信停止、疑わしい資格情報失効、該当テンプレート無効化
  • 根絶: 侵害アカウント調査、設定改ざん復旧、不要権限剥奪
  • 復旧: 段階的再開、監視強化、顧客向け案内
  • 事後対応: 再発防止策、運用手順改訂、監査証跡保全
Tips：初動時間を要件化する

「対応する」ではなく、
「不正送信疑い検知から15分以内に配信停止判断」など時間で定義すると実運用に落ちます。

Step 5：受入基準と継続要件（測定可能にする）​

5-1. 受入基準（例）​

  • 主要送信経路のDKIM署名率が100%
  • DMARCポリシー適用ドメインで未知送信元が継続発生しない
  • 特権操作は全件監査ログが残り、検索可能
  • 不審送信アラートから一次判定までの時間がSLA以内
  • API鍵ローテーションが定義周期内に実施される

5-2. 継続運用（例）​

  • 月次: DMARC分析、異常送信レビュー、誤送信事例の再発防止確認
  • 四半期: 権限棚卸し、鍵ローテーション、テンプレート統制レビュー
  • 半期/年次: インシデント訓練、脅威モデル更新、委託先監査

5-3. 要件の書き方​

  • 曖昧語を避ける（「強化する」「適切に」）
  • 主語を明確にする（誰が実施し、誰が承認するか）
  • 数値化する（率、時間、件数、周期）

まとめ​

メールセキュリティ要件は、設定項目の網羅ではなく、

  1. 共通整理（資産と責任分界）
  2. B2C前提の脅威優先順位
  3. 予防コントロール
  4. 監視・対応コントロール
  5. 受入基準と継続運用

の順で設計すると、実装可能で監査にも耐える形に落とし込めます。

参考リンク（信頼できる一次情報・公的資料）​

最近の関連インシデント・注意喚起（2024〜2026）​

に最終更新