テナント統合

ドメイン・DNS移行とメールフロー切り替え ― 失敗しないための実務ガイド

#テナント統合#DNS#ドメイン#SPF#DKIM#DMARC#メールフロー
📘
完全ガイドの一部ですテナント統合 完全ガイド ― M365 / GWS移行の全11ステップ
→

テナント統合プロジェクトにおいて、最もリスクが高く、かつロールバックが難しいのがドメインとDNSの移行です。MXレコードの切り替えを誤れば全社のメールが停止し、SPF / DKIMの設定ミスは送信メールのスパム判定につながります。

本記事では、ドメイン・DNS移行をゼロダウンタイムに近づけるための実務手順を解説します。

ドメイン移行の全体フロー

M365テナント間のドメイン移行

Microsoft 365では、1つのカスタムドメインは同時に1つのテナントにしか紐づけられません。そのため、以下の手順が必要です。

  1. 移行元テナントでドメインに紐づくユーザーのUPNを変更（@contoso.onmicrosoft.com 等に一時変更）
  2. 移行元テナントからカスタムドメインを削除
  3. 移行先テナントにカスタムドメインを追加
  4. DNS検証（TXTレコードまたはMXレコード）
  5. 移行先テナントのユーザーUPNをカスタムドメインに変更
  6. DNSレコードの更新

重要: ドメインを移行元から削除してから移行先で検証完了するまでの間、そのドメイン宛のメールは受信できません。この時間を最小化するため、事前準備が不可欠です。

GWSテナント間のドメイン移行

Google Workspaceでもドメインの排他制約があります。

  1. 移行元テナントでプライマリドメインを変更（一時ドメインに切り替え）
  2. 移行元テナントからドメインを削除
  3. 移行先テナントにドメインを追加・DNS検証
  4. MXレコード等の更新

DNSレコードの変更手順

事前準備（カットオーバー48時間前）

TTLの短縮

すべての関連レコードのTTLを300秒（5分）に変更します。

; 変更前（通常）
contoso.com.  IN  MX  3600  10 contoso-com.mail.protection.outlook.com.
contoso.com.  IN  TXT 3600  "v=spf1 include:spf.protection.outlook.com ~all"

; 変更後（カットオーバー前）
contoso.com.  IN  MX  300   10 contoso-com.mail.protection.outlook.com.
contoso.com.  IN  TXT 300   "v=spf1 include:spf.protection.outlook.com ~all"

カットオーバー時のDNS変更

MXレコード

メールの配送先を移行先テナントに変更します。

M365の場合:

contoso.com.  IN  MX  300  10 contoso-com.mail.protection.outlook.com.

GWSの場合:

contoso.com.  IN  MX  300  1  ASPMX.L.GOOGLE.COM.
contoso.com.  IN  MX  300  5  ALT1.ASPMX.L.GOOGLE.COM.
contoso.com.  IN  MX  300  5  ALT2.ASPMX.L.GOOGLE.COM.

SPFレコード

移行先の送信サーバーを含むSPFレコードに更新します。

; M365の場合
contoso.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

; GWSの場合
contoso.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

移行期間中は両方のincludeを含めることも可能です:

contoso.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

DKIMレコード

移行先テナントで生成されたDKIM CNAMEレコードを設定します。

DMARCレコード

DMARCポリシーは移行前後で維持します。移行直後はp=noneに一時変更し、SPF / DKIMの認証が安定したことを確認してからp=quarantineやp=rejectに戻すことを推奨します。

; 一時的に緩和
_dmarc.contoso.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com"

Autodiscoverレコード（M365）

autodiscover.contoso.com.  IN  CNAME  autodiscover.outlook.com.

カットオーバー後のDNS変更（安定化後）

  • TTLを通常値（3600秒）に戻す
  • DMARCポリシーをp=quarantineまたはp=rejectに戻す
  • 不要になった旧テナント向けのレコードを削除

メールフロー切り替えの詳細

切り替え前のメールフロー

外部送信者 → MX（旧テナント）→ 旧Exchange/Gmail → ユーザー

切り替え後のメールフロー

外部送信者 → MX（新テナント）→ 新Exchange/Gmail → ユーザー

切り替え中の対策

メール転送ルールの設定

MXレコードの浸透に時間がかかるため、切り替え後しばらくは旧テナントにもメールが届きます。旧テナントで移行先への転送ルールを設定しておきます。

M365の場合（PowerShell）:

New-TransportRule -Name "Forward to New Tenant" `
  -SentToScope "InOrganization" `
  -RedirectMessageTo "user@newtenant.com"

ロールバック計画

ドメイン・DNS移行で問題が発生した場合のロールバック手順を事前に準備します。

ロールバックの手順

  1. MXレコードを旧テナントの値に戻す（TTL 300秒なら5分で浸透）
  2. 旧テナントの転送ルールを無効化
  3. ユーザーへ旧環境でのメール利用を案内
  4. 問題の原因を調査・対処後、再度カットオーバーを計画

ロールバックが困難なケース

  • 移行先テナントにドメインを追加済みで、旧テナントに戻せない
  • カットオーバー後に大量のメールが移行先に蓄積されている

→ これらのケースを避けるため、ドメインの追加・削除手順のリハーサルを事前に実施してください。

カットオーバー当日のタイムライン例

時刻作業
金曜 20:00旧テナントからドメイン削除
金曜 20:15新テナントにドメイン追加・検証
金曜 20:30DNSレコード更新（MX, SPF, DKIM, DMARC, Autodiscover）
金曜 21:00メール送受信テスト（内部・外部）
金曜 21:30SPF / DKIM認証の確認（メールヘッダーチェック）
土曜 終日DNS浸透の監視、問題があればロールバック
月曜 09:00ユーザーからの問い合わせ対応
月曜 17:00安定確認後、TTLを通常値に戻す

まとめ

ドメイン・DNS移行は「DNS変更するだけ」ではなく、MXレコード、SPF、DKIM、DMARC、Autodiscoverなど複数のレコードを正確に設定する必要があります。TTLの事前短縮、メール転送ルールの設定、ロールバック計画の準備を徹底し、金曜夜〜土曜のカットオーバーを推奨します。

次回（最終回）は、テナント統合後の検証と最適化チェックリストを紹介します。

まとめ・ご相談

セキュリティ対策の強化をご検討の方は、Security365（セキュリティ運用・SOCライト）をご覧ください。

貴社のIT課題について、まずは60分の無料相談でお気軽にご相談ください。

情シスのお悩み、ご相談ください

専門スタッフが貴社の課題に合わせたご提案をいたします。

60分無料相談はこちら 資料ダウンロード
メールでのお問い合わせはこちら →
60分無料相談