ドメイン分離とDNSカットオーバー ― ダウンタイムを最小化する手順｜テナント分離ガイド第8回
テナント分離プロジェクトの 最大の山場 がドメイン分離です。Microsoft 365 のドメインは、1つのドメインを1つのテナントしか使えません。新テナントで使うには、旧テナントから削除したうえで再検証する必要があります。
この間、メール送受信が止まります。本記事では、このダウンタイムを最小化するためのカットオーバー手順を解説します。
ドメイン分離パターンの整理
事業譲渡・スピンオフでは、ドメインの扱いに3つのパターンがあります。
パターン1：分離先が新ドメインを取得（推奨）
例：旧 oldco.com → 新 newco.com（新規取得）
- 旧テナントのドメインはそのまま維持
- 新テナントに新ドメインを追加して使用
- メールアドレス変更が発生するため、ユーザー周知と取引先連絡が必要
- ダウンタイムがほぼゼロ（新テナント側は最初から新ドメインで運用）
- 旧ドメイン宛のメールは旧テナントから新テナントへの自動転送ルールで救済
パターン2：既存ドメインの一部を新テナントに移管
例：oldco.com を旧テナントから削除し、新テナントに追加
- ユーザーのメールアドレスが変わらない（最大のメリット）
- 削除→追加のタイミングでメールが届かない時間帯が発生
- 商標・契約上の理由で「ドメインも移管対象」となるケース
パターン3：サブドメインで分割
例：oldco.com は旧、tokyo.oldco.com を新テナントに切り出し
- ドメイン全体は旧に残し、サブドメインだけ新へ
- メールアドレスが
@tokyo.oldco.comに変わる - 中間的な選択肢
最も多いのはパターン1ですが、契約上パターン2が必要なケースも珍しくありません。本記事はパターン2（最も難しい）を中心に解説します。
パターン2：既存ドメイン移管の手順
事前準備（カットオーバー2週間前）
1. DNSレコードの全棚卸し
□ MX レコード（メール）
□ SPF（TXT）
□ DKIM（CNAME × 2）
□ DMARC（TXT）
□ Autodiscover（CNAME）
□ MSOID（CNAME）（ハイブリッド構成の場合）
□ SIP（CNAME / SRV）（Skype for Business 旧構成）
□ その他のCNAME（マーケオートメーション、Webhost、SaaS連携）2. 第三者SaaSのDNS依存確認
意外に多いのが、サードパーティSaaSがCNAMEで自社ドメインを利用しているケース：
- HubSpot / Marketo / Mautic（メール送信ドメイン認証）
- SendGrid / Mailgun（トランザクションメール）
- Microsoft Defender for Office 365（メールフィルタ前段に挟む構成）
これらの設定はドメイン移管時に新テナント側で再構築が必要です。
3. メールフロー転送の事前設定
旧テナントから新テナントへのメール転送ルールを準備します。カットオーバー直後から数日〜数週間、旧ドメイン宛メールが新テナントに届くまで救済する仕組みです。
# 旧テナント側でTransport Ruleを作成
New-TransportRule -Name "Forward to NewTenant" `
-RecipientAddressContainsWords "@oldco.com" `
-RedirectMessageTo "newco-relay@newco.onmicrosoft.com"4. ロールバック計画の文書化
何かあった時に、いつまでに、どこまで戻すか。ロールバック判断基準を事前に明文化しないと、現場で判断が遅れます。
例：
- カットオーバー後 30 分以内にメール送信が回復しなければロールバック
- 新テナントのDNS検証が 2 時間で完了しなければロールバック
- ロールバック決定権者：CIO、PMOリーダー、情シス代表
カットオーバー当日（典型的なタイムライン）
平日夜間 22:00 開始、月曜朝 09:00 までに完了する標準的スケジュール：
| 時刻 | 作業 |
|---|---|
| 22:00 | カットオーバー開始宣言、ユーザー向け通知メール |
| 22:00-22:30 | 最終差分同期（メールボックス、OneDrive、SharePoint） |
| 22:30 | 旧テナントでメール送受信を停止（一時的にメールキュー保持設定） |
| 22:45 | 旧テナントからドメイン削除（サポートチケット起票が必要なケースあり） |
| 23:00 | 新テナントでドメイン追加・検証（TXT 検証） |
| 23:15 | DNS切り替え：MX、SPF、DKIM、DMARC、Autodiscover |
| 00:00 | DNS伝播待ち（TTL値を事前に短縮しておくと早い） |
| 00:30 | 新テナント側でメール送受信疎通確認 |
| 01:00 | 旧テナントからの転送ルール有効化 |
| 01:30 | 重要システム（Outlook、Teams、SharePoint）の動作確認 |
| 02:00 | カットオーバー完了宣言（PMO・情シスのみで作業終了） |
| 月曜朝 | 全社ユーザー向け案内、ヘルプデスクスタンバイ |
旧テナントからのドメイン削除時の落とし穴
ドメイン削除前の依存削除が必要です：
- ドメインに紐づくユーザーアカウントが存在する → 全アカウントのプライマリSMTPアドレスを別ドメインに変更
- ドメインに紐づくグループが存在する → 同上
- 共有メールボックス → 同上
- Acceptedドメインとして残っている → トランスポートルールから削除
- ハイブリッド構成（Exchange Online + オンプレ Exchange） → DNS変更前にハイブリッド設定の更新
これらが残っているとドメイン削除がエラーになります。事前にPowerShellで全依存を洗い出すスクリプトを準備するのが鉄則です。
DNS の TTL 短縮
DNS の TTL（Time To Live）が長いと、変更が伝播するのに時間がかかります。カットオーバー数日前に TTL を300秒（5分）程度まで下げておきます。
変更前：MX レコード TTL = 3600（1時間）
変更後（カットオーバー1週間前）：TTL = 300（5分）
カットオーバー後：TTL = 3600 に戻すただし、外部DNSサービス（権威DNSプロバイダ）によっては最小TTLに制限があります。事前確認が必要です。
SPF / DKIM / DMARC の再設定
SPF（TXT）
旧：
v=spf1 include:spf.protection.outlook.com -all新（旧テナントとの並行運用期間中）：
v=spf1 include:spf.protection.outlook.com include:newco-relay.onmicrosoft.com -all旧テナントから転送される間は、両方のテナントを許可するSPFが必要です。
DKIM
新テナント側で新しいDKIMセレクタを生成し、CNAMEを追加します。旧テナントのDKIMセレクタは、TSA期間が終わるまで残しておきます。
DMARC
新ドメイン宛のメールが新テナントから送信されることを宣言：
v=DMARC1; p=none; rua=mailto:dmarc-reports@newco.com最初は p=none（監視のみ）で開始し、運用が安定したら p=quarantine、p=reject に厳格化します。
ダウンタイム最小化のテクニック
テクニック1：メールキュー保持
カットオーバー中にドメイン宛に送信されたメールを、送信側のメールサーバが再送する仕組みに頼ります。多くのメールサーバは数日間リトライしてくれます。
テクニック2：補助ドメインの活用
新テナント側で newco.onmicrosoft.com のようなテナントデフォルトドメインを使ってメール疎通テストを先行実施。本番ドメインの切り替えは最後に。
テクニック3：地域・部門別の段階カットオーバー
100名以上の規模では、カットオーバーを地域別・部門別に分割するアプローチも有効。一日で全員を切り替えるリスクを下げられますが、共有メールボックス・配布リストの仕分けが複雑になります。
トラブル時の対応
「メールが届かない」報告が出た場合
- 送信元のメールサーバログを確認：実際にどのMXに配送されたか
- DNS伝播確認（dig、whatsmydns.net等）：意図通りに変わっているか
- 新テナントのメッセージトレース：受信できているがフィルタで隔離されていないか
- 旧テナントの転送ルール：稼働しているか
ロールバック発動時
最悪のケースに備え、 DNSをロールバックする手順 をプリエージェントしておきます：
1. MX を旧テナント向けに戻す
2. 旧テナントでドメインを再追加（再検証が必要）
3. SPF を旧構成に戻す
4. ユーザー向けにロールバック通知ロールバックは可能ですが、新テナントで進行した移行の差分が失われるリスク があります。判断は慎重に。
次に読むべき記事
カットオーバーが終われば、最後は移行ツールの選定と分離後の運用に向けた整備です。
情シス365の支援
ドメイン分離・DNSカットオーバーは経験値が物を言う領域です。情シス365のテナント分離パッケージでは、カットオーバー当日のオンサイト立会いと、48時間ヘルプデスクスタンバイを標準で含んでいます。