DMARC移行ガイド
DMARCプラットフォームを移行する際は、現在のDMARCプラットフォームで適用されている設定を理解することが重要です。適切に計画された移行により、認証とレポートを強化しながら、メールの流れを円滑に維持することができます。このガイドでは、DMARCプロバイダー（および関連するDNSレベルの設定）の切り替えの各フェーズについて説明します。
概要
このガイドでは以下の内容を扱います：
- 計画とインベントリ
- 評価と準備
- 並行設定
- DNS更新の順序
- テストと監視
- 切り替えの実行
- 移行後のレビュー
このプロセスに従うことで、ベストプラクティスとの整合性を確保し、自動化のヒントを活用してダウンタイムゼロ、配信可能性の維持、レポートと実施の最大化を実現できます。
1. 計画とインベントリ
この最初のフェーズでは、現在の設定の関連する各領域を完全に理解していることを確認します。
ドメインとレコードのインベントリ
関係するすべてのドメインをカタログ化します。各ドメインについて、以下の現在のDNSレコードを収集します：
| DNSレコード | 予想されるレコードタイプ | 識別方法 |
|---|---|---|
| DMARC | TXTまたはCNAME | ホスト名に_dmarcを含む |
| SPF | TXT | 値セクションがv=spf1で始まる |
| DKIM | TXTまたはCNAME | ホスト名に_domainkeyを含む |
| BIMI | TXT | 値セクションがv=BIMI1で始まる |
| MTA-STS | TXT | ホスト名に_mta-stsを含む |
| TLS-RPT | TXT | ホスト名に_tls-rptを含む |
既存のDMARC実施（p=none/quarantine/reject）とレポートアドレス（rua/ruf）を文書化します。最初の完全なインベントリは重要です – 変更を加える前に「まず既存の保護サービスの設定のインベントリを作成する」必要があります。
大規模な環境では、スクリプトやDNSエクスポートツールを使用してこのデータ収集を自動化します。
送信元の特定
- すべてのメール送信者（オンプレミスサーバー、クラウドサービス、マーケティングプラットフォームなど）と、各ドメインの現在のSPFインクルードまたはDKIMキーをリストアップ
- サブドメインやサードパーティへの委任を確認
- 既存のDMARCレポートや送信メールログを使用してインベントリを検証
現在のレポートフローのレビュー
- DMARCの集計/失敗レポートとTLS-RPTレポートの送信先（メールアドレス）を記録
- 新しいDMARC Managerプラットフォームへの移行によって可視性を維持することを計画
- DMARCレコードは複数のレポートURI（カンマ区切り）をリストでき、古いシステムと新しいシステムの両方に同時にデータを送信可能
ベースラインパフォーマンスの設定
変更前に、現在のメールメトリクス（バウンス率、スパム苦情、配信可能性）とDMARCコンプライアンスレベルを記録します。これにより、移行後の改善を確認し、後退がないことを確認できます。
2. 評価と準備
評価と準備フェーズでは、必要な場合のロールバックに備えていることを確認します。小規模な環境では、以下のすべてが必要ない場合があります。判断して使用してください。
既存のDNSレコードのバックアップ
- ゾーンファイルをエクスポートまたは保存
- DMARC、SPF、DKIMセレクター、MTA-STS、TLS-RPTなどの現在のすべてのレコードのコピーを保持
新しいターゲットDNSエントリのカタログ化
DMARC Managerを開き、各ドメインの新しいターゲット設定を取得します。各ドメインについて、DMARC managerから必要な新しいレコード（レガシープラットフォームでカバーされている場合）があることを確認します：
- DMARC
- SPF
- DKIM
- MTA-STS
- TLS-RPT
- BIMI
例: DMARCのセットアップ手順を見つける場所の例です。他の設定は、関連する標準設定タブに切り替えるだけで見つけることができます。
ステークホルダーの役割
責任を割り当てます。DNSを更新する人、新しいDMARC Managerを設定する人、レポートを監視する人、何か失敗した場合にロールバックを処理する人を定義します。例えば、IT運用がDNS変更を処理し、セキュリティチームがレポートをレビューするといった具合です。明確な役割とコミュニケーションチャネルが重要です。
リスク評価とスケジューリング
- リスク（例：一時的な誤設定によるバウンス）を特定し、緩和を計画
- トラフィックの少ない時間帯での移行や、ドメイングループごとのフェーズでの移行を検討
- 多数のドメインがある場合、影響を制限するためにバッチで移行（例：一度に100ドメイン）
新環境の準備
- チームに新しいプラットフォームのインターフェース/APIに慣れてもらう
- 必要な情報（新しい公開DKIMキー、SPFインクルード値、レポートアドレス、MTA-STSエンドポイント）を収集
- 新しいDMARC Managerのレコード用のDNSアクセス権があることを確認
- 必要なDNS CNAMEまたはTXTエントリを記録
DNS TTLの低減
- 変更の数日前に、主要なレコード（DMARC、SPF、DKIM、MTA-STS、TLS-RPT）のTTLを低い値（例：300～3600秒）に減らす
- これにより切り替え中の伝播遅延を最小限に抑える
- 安定化後に高いTTLを復元することを忘れずに
役割の委任とドキュメント化
- 計画された各変更を文書化し、ステップバイステップのランブックを準備
- 各ドメイン（またはドメインテンプレート）について、正確なDNS編集と順序を記録
- コンプライアンスを実証し、何がいつ変更されたかを示すことができる監査準備済みの変更ログを維持
3. 並行設定
古いDMARCプラットフォームがアクティブな間、新しいDMARC Managerを並行して設定し、両方のシステムが同時にメールを受信または検証するようにします。この「デュアルライト」フェーズにより、ダウンタイムやブラインドスポットを回避し、すべての関連するDNSエントリに適用されます。
新しいDMARC Managerへのドメインの追加
- DMARC Managerにすべての新しいドメインを追加
- 必要に応じてDNS所有権を確認（例：DNS TXTまたはメール経由）
DMARC設定
- 新しく追加されたドメインの初期DMARCポリシーを現在公開されているポリシーに設定
- 古いDMARCプラットフォームのレポートアドレスをDMARC Managerに追加
- ドメインインターフェースの'設定の編集'で設定：
- 集計レポートセクションにRUAアドレスを追加
- 失敗レポートセクションにRUFアドレスを追加
SPF設定
- DMARC ManagerでSPF TXTレコードを現在公開されているSPFレコードに更新
- すべてのインクルードがDMARC Managerに表示されることを確認
- 'all'タグが同じポリシー（通常は
~all）に設定されていることを確認 - レガシーDMARCプラットフォームの古いSPFインクルードはまだ削除しない
DKIM設定
- DKIMキーを新しいDMARC ManagerのDKIMキー管理に追加
- 古いDKIMレコードはまだ削除しない
BIMI設定
- 証明書ファイルをDMARC managerにコピー
- 画像ファイルをDMARC managerにコピー（正確なSVGを使用）
- 古いBIMIレコードはまだ削除しない
MTA-STS設定
MTA-STSを使用している場合、新しいDMARC ManagerのMTA-STSポリシーが古いものを反映していることを確認します。
4. レコード更新の順序
適切なDNS変更の順序付けによりリスクを最小限に抑えます。以下の順序に従ってください：
- TTLの低減（準備で完了）
- 既存のSPFを新しいSPFに置き換え：
- DMARC Manager指示に従う
- 構文とルックアップ制限を確認
- DNS伝播を待つ（数分から1時間）
- 新しいDKIMキー管理エントリを公開：
- 新しいDKIM管理NSレコードを追加
- ロールバック用に古いDKIMレコードをアクティブに保持
- 既存のDMARCレコードを置き換え：
- DMARC Managerレコードを使用
- 構文を確認（ドメインごとに1つのDMARC TXT/CNAME）
- 既存のBIMIレコードを置き換え：
- 古いBIMIレコードを削除
- 新しいBIMI NSレコードを追加
- MTA-STS DNSレコードを更新
- TLS-RPT DNS TXTを更新
- 検証の一時停止（24～48時間）
- オプションの実施調整
検証ステップ
各ステップで、メール認証を確認：
- SPF：ツールまたはテストメールを使用して認証を確認
- DKIM：テストメッセージを送信してヘッダーを検証
- DMARC：プロバイダー間の分割レポートを確認
5. テストと監視
DMARCレポート
- 両方のサービスがレポートを受信することを確認
- サンプルレポートを比較
- 正当なメールソースを確認
認証テスト
- 各ソースからテストメールを送信
- SPF=passとDKIM=passを確認
- 失敗があれば調査
MTA-STS検証
- オンラインMTA-STSチェッカーを使用
- 外部ドメインメールをテスト
- Google Workspace管理コンソールを確認（該当する場合）
TLS-RPTレビュー
- 数日後にレポートを確認
- 問題があれば対処
- 新しいプロバイダーがレポートを受信することを確認
配信可能性の監視
- バウンス率を監視
- スパムレポートを監視
- ユーザー苦情を追跡
6. 切り替えの実行
確認後、最終切り替えを実行：
- 古いDKIMキーを削除（48～72時間後）
- SPFインクルードをクリーンアップ
- DMARCレコードを最終化：
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100 - MTA-STS設定を更新
- 古いTLS-RPT URIを削除
- 古いプロバイダーを廃止
注意: バックアッププランを準備してメンテナンスウィンドウ中に削除を実行してください。
7. 移行後のレビュー
検証チェックリスト
- [ ] すべてのドメインがDMARC Managerにレポート
- [ ] DMARC Managerレコードのみが残っている
- [ ]
digまたはDNS管理インターフェースで確認
パフォーマンスレビュー
- メール拒否率を監視
- DMARCコンプライアンスを確認
- 移行前/後のメトリクスを比較
ドキュメント化
- 監査ログをコンパイル
- DNS変更を文書化
- 切り替え日を記録
- 確認メッセージを保存
ポリシーの強化
- 実施の増加を計画
p=rejectに向けて移行- 定期的なSPFレビュー
結論
慎重なインベントリ作成、準備、システムの並行実行により、切り替え中のダウンタイムゼロを確保します。マルチ受信者レポートにより、配信可能性と可視性が中断されることなく維持されます。最後に、古いレコードのクリーンアップとポリシーの強化により移行が完了し、DMARC Managerの下でより強力なメール認証と包括的な監視が実現します。