performing-dmarc-policy-enforcement-rollout

DMARC ポリシー適用の段階的展開

概要

Domain-based Message Authentication, Reporting and Conformance（DMARC）は、メールのなりすまし対策の要となる仕組みです。DMARC の展開は、監視（p=none）、隔離（p=quarantine）、完全適用（p=reject）の 3 つの段階を経て進みます。p=reject に設定すると、SPF と DKIM の両方のチェックに失敗したメールは即座に拒否されます。Google と Yahoo は現在、大量送信者（5,000 通以上）に DMARC を必須としており、その結果、認証されていないメッセージが 65% 減少しています。安全に展開するには、通常 3～6 か月かかります。

使用するタイミング

• DMARC ポリシー適用の段階的展開を伴うセキュリティ評価を実施する場合
• 関連するセキュリティイベントに対してインシデント対応手順を実施する場合
• 定期的なセキュリティテストまたは監査活動を実施する場合
• 実地テストを通じてセキュリティ管理策を検証する場合

前提条件

• ドメインの DNS 管理に対する管理者権限
• SPF、DKIM、DMARC プロトコルの理解（RFC 7208、6376、7489）
• 正当なメール送信元の完全な棚卸し
• DMARC レポート分析ツール（EasyDMARC、DMARCLY、Valimail、dmarcian のいずれか）
• DMARC 適用機能を備えたメールゲートウェイ

主要な概念

DMARC ポリシーのレベル

ポリシー	動作	使用目的
p=none	監視のみ。失敗時に何もしない	検出フェーズ
p=quarantine	失敗したメッセージを迷惑メールフォルダへ送信	移行フェーズ
p=reject	失敗したメッセージを完全にブロック	完全適用

DMARC レコードの構成

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; fo=1

• p: 組織ドメインに対するポリシー
• sp: サブドメインに対するポリシー
• pct: ポリシーの適用対象となるメッセージの割合（段階的な展開用）
• rua: 集約レポートの送信先（日次 XML レポート）
• ruf: フォレンジックレポートの送信先（失敗ごとのレポート）
• adkim: DKIM アライメントモード（r=relaxed、s=strict）
• aspf: SPF アライメントモード（r=relaxed、s=strict）
• fo: 失敗レポートのオプション（0=いずれかの認証が失敗した場合、1=いずれかが失敗した場合）

SPF と DKIM のアライメント

• SPF アライメント: Return-Path（エンベロープ送信者）のドメインが From ヘッダーのドメインと一致する必要があります
• DKIM アライメント: DKIM 署名の d= ドメインが From ヘッダーのドメインと一致する必要があります
• Relaxed: 組織ドメインが一致すること（sub.example.com は example.com と一致とみなされます）
• Strict: 完全なドメイン一致が必要です

ワークフロー

ステップ 1: すべての送信元の棚卸し（1～2 週目）

• ドメインのアドレスでメールを送信しているすべてのシステムを監査します（マーケティング、CRM、チケット管理、トランザクションメール）
• サードパーティサービスを文書化します（Salesforce、Mailchimp、SendGrid、Zendesk など）
• 社内のメールサーバー、アプリケーション、リレーホストを特定します
• シャドー IT によるメール送信を確認します（未承認のサービスを利用している部門）

ステップ 2: SPF と DKIM の設定（2～4 週目）

• すべての正当な送信元 IP とインクルードを含むよう SPF レコードを統合します
• SPF レコードが DNS ルックアップの上限 10 回未満に収まるようにします
• 送信元ごとに DKIM 鍵を生成して公開します
• すべての送信メールの経路で DKIM 署名が機能することを検証します
• MX Toolbox または dmarcian の SPF/DKIM 検証ツールでテストします

ステップ 3: 監視モードでの DMARC 展開（4～6 週目）

• 初期の DMARC レコードを公開します: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
• 代表的な集約レポートを収集するため、1～2 週間待ちます
• レポートを分析し、未承認の送信者とアライメントの失敗を特定します
• 失敗が見られるすべての正当な送信元について SPF/DKIM を修正します
• すべての正当なメールが DMARC に合格するまで繰り返します

ステップ 4: pct タグを使用した隔離への移行（6～12 週目）

• 10% で隔離に変更します: v=DMARC1; p=quarantine; pct=10; rua=...
• 誤検知（正当なメールが隔離されること）を監視します
• pct を段階的に引き上げます: 10% → 25% → 50% → 75% → 100%
• 各引き上げの前に、1～2 週間待ってレポートを確認します
• 各段階で発見された残りのアライメントの問題を修正します

ステップ 5: reject ポリシーへの移行（12～20 週目）

• 100% の隔離が安定したら、10% で reject に移行します: v=DMARC1; p=reject; pct=10; rua=...
• pct を段階的に引き上げます: 10% -> 25% -> 50% -> 100%
• 正当なメールが拒否されていないか、慎重に監視します
• 緊急時のロールバック手順（quarantine への差し戻し）を確立します
• サブドメインにはサブドメインポリシーを適用します: サブドメイン向けに sp=reject

ステップ 6: 継続的な監視と保守

• DMARC の集約レポートを継続的に監視します
• 新しい送信元は、送信を開始する前に追加します
• フォレンジックレポートを確認し、なりすましの試みがないか調べます
• 送信インフラの変更に合わせて SPF レコードを維持します
• DKIM キーは年に 1 回ローテーションします

ツールとリソース

• EasyDMARC: 集約レポートとフォレンジックレポートの分析に対応した DMARC 監視ダッシュボード
• DMARCLY: 自動 DNS 更新に対応した SPF、DKIM、DMARC の監視ツール
• dmarcian: DMARC の導入と管理のためのプラットフォーム
• Valimail: ホスト型認証による自動 DMARC 適用
• MX Toolbox: DNS レコード検索および DMARC バリデーター
• Google Admin Toolbox: DMARC チェックおよび診断ツール

検証

• DMARC レコードが公開され、_dmarc.domain.com で正しく解決されること
• すべての正当な送信元が SPF および/または DKIM のアラインメントに合格すること
• 集約レポートで、正当なメールの 99% 超が DMARC に合格していることを示すこと
• 許可されていない送信者からのなりすましメールが拒否されること
• p=reject を完全に適用した後、正当なメールがブロックされていないこと
• サブドメインポリシー（sp=）も reject に設定されていること