「Microsoft 365 に移行したい、でもメールが止まったらどうしよう…」。これは現場で最もよく聞く不安の声です。
実際、移行作業で事故が起きやすいポイントは次の 2 つに集中しています。
- DNS の切り替えタイミングを誤る（メールが届かない時間が発生する）
- 旧サーバーのメールデータを適切に移行しない（過去メールが消える・消えかける）
さらに、
この 2 点に加えて「プロパゲーション期間」と呼ばれる DNS 変更の浸透待ち時間中に、メールがどちらのサーバーに届くかわからなくなる問題があります。
本記事ではこれらをすべて解決する、現場で実際に使える 正しい手順と順番 を詳しく解説します。
全体の流れと「絶対に守るべき順番」
移行を成功させる最大の秘訣は「順番」を崩さないことです。
移行フェーズ全体像
- フェーズ 0（3週前） 事前準備・現状把握
- フェーズ 1（2週前）M365テナント設定・ドメイン登録
- フェーズ 2（1週前）TTL短縮・メールデータ移行（IMAP同期）開始
- フェーズ 3（Xデー前日）最終確認・旧サーバーチェック
- フェーズ 4（Xデー）MXレコード切り替え・DNS変更
- フェーズ 5（切り替え後）プロパゲーション監視・旧サーバー並行運用
- フェーズ 6（1〜2週後） 旧サーバー停止・後処理
最重要ルール：
MX レコードを変更する前に、必ず Microsoft 365 側のメールボックスを作成してライセンスを付与しておくこと。
MX レコード変更後にメールボックスが存在しないと、受信メールは配信されず、送信元に NDR（配信不能レポート）として返送されます。
フェーズ 0〜1 ｜ 事前準備と Microsoft 365 テナントの初期設定
現状の棚卸し（Xデー 3 週前まで）
移行前に以下を必ず確認してください。
- メールプロトコルの確認：旧サーバーが IMAP か POP3 かを把握する（移行方法が根本的に変わります）
- ユーザー数とメールボックス数：ライセンス購入数に影響
- メールデータ量：1 ユーザーあたりの容量（移行時間の見積もりに必要）
- 現在の DNS 管理場所：ドメインレジストラー or レンタルサーバー側の DNS かを確認
- 現在の MX レコードの TTL 値：nslookup -type=mx yourdomain.co.jp で確認可能
Microsoft 365 テナントを作成・ドメイン登録
- Microsoft 365 管理センターにサインイン
- 「設定」→「ドメイン」→「ドメインの追加」 で自社ドメインを登録
- ドメイン所有確認のための TXT レコード を DNS に追加
- ここでは MX レコードは絶対に変更しない
ポイント：
ドメイン登録ウィザードが MX レコードを自動設定しようとする場合があります。
「自分で DNS レコードを管理する」オプションを選択し、MX レコードの変更はスキップしてください。
ユーザーアカウントの作成とライセンス付与
MX レコードを変更する 前に、全ユーザーのメールボックスを Microsoft 365 上で作成しライセンスを割り当てておきます。
注意：
Exchange Online ライセンスが割り当てられていないユーザーにはメールボックスは作成されません。
また、既存メールボックスからライセンスを外した場合、一定期間（通常30日）後に削除されます。
承認済みドメインの設定
Microsoft 365 のテナントに独自ドメインを登録すると、デフォルトでは 「権限あり（Authoritative）」 という設定になります。
この状態では、Microsoft 365 テナント内から同一ドメイン宛にメールを送信した場合、Exchange Online はまずテナント内の受信者を解決しようとします。
該当ユーザーがテナント内に存在しない場合、外部（旧サーバー）へ配送されず NDR になることがあります。
これを防ぐため、移行完了まで承認済みドメインを 「内部の中継（Internal Relay）」 に設定し、旧サーバーへのコネクタを設定する必要があります。
フェーズ 2 ｜ TTL の短縮とメールデータの移行
MX レコードの TTL を事前に短縮する（Xデー 1 週間以上前）
TTL（Time To Live）とは、DNS のキャッシュ保持時間（秒単位）です。
なぜ TTL の短縮が必要か？
世界中の DNS サーバーは、一度問い合わせたレコードを TTL の時間分キャッシュします。
TTL が 86400（24時間）のまま MX レコードを変更すると、変更前にキャッシュしたサーバーは最大 24 時間も古い MX レコードを参照し続けます。
これが「プロパゲーション期間」の正体です。
TTL 短縮の具体的な手順：
1. 現在の TTL を確認（例：86400 = 24時間）
2. 切り替えの 24〜48 時間以上前に TTL を 300〜3600 秒に変更
3. 元の TTL 時間（例：24時間）が経過するまで待つ
4. Xデーに MX レコードを変更 → 短い TTL が効いて数分〜1時間で浸透
Microsoft も公式に、移行前に TTL を 3,600 秒（1時間）以下 に設定することを推奨しています。
SPF レコードの更新（Xデー前）
旧サーバーと Microsoft 365 の両方からメールを送信する移行期間中、SPF レコードに 両方のサーバー情報を含める 必要があります。
v=spf1 include:spf.protection.outlook.com include:旧サーバーのSPF ~all
SPF レコードは 1 ドメインにつき 1 つのみ定義できます。
複数の SPF レコードが存在すると評価エラー（PermError）となり、正しく判定されません。
既存の SPF レコードに include:spf.protection.outlook.com を追記してください。
メールデータの移行方法（IMAP と POP3 の違い）
移行方法は現在のメール受信プロトコルによって大きく異なります。
まず自社の環境を確認してください。
| プロトコル | メールデータの保存場所 | 推奨移行方法 |
|---|---|---|
| IMAP | サーバー上に保存 | Exchange 管理センターの IMAP 移行バッチ（Xデー前に実行） |
| POP3 | PC（クライアント）に保存 | Outlook の PST ファイルを経由してインポート（Xデー前後） |
IMAP 方式の場合：
移行バッチによる同期移行
IMAP 方式はサーバーにメールが残っているため、Xデー前から移行バッチで差分同期できる のが大きな強みです。
これが IMAP 移行の最重要テクニックです。
Step 1. CSV ファイルの作成
移行するメールボックスの一覧を以下の形式で作成します：
csv
EmailAddress,UserName,Password
user1@yourdomain.co.jp,user1,password123
user2@yourdomain.co.jp,user2,password456
Step 2. Exchange 管理センターで移行エンドポイントを作成
- Exchange 管理センター（EAC）→「移行」→「移行バッチの追加」
- 移行の種類：「IMAP 移行」 を選択
- 旧 IMAP サーバーのホスト名・ポート（993/SSL または 143/TLS）・暗号化方式を入力
- 接続テストが自動実行されます
Step 3. 移行バッチを開始・差分同期を維持
移行バッチを開始すると、Microsoft 365 が旧 IMAP サーバーに接続してメールを取り込みます。
完了後も定期的に差分同期が自動で継続されるため、Xデーまでメールの差分が取り込まれ続けます。
Step 4. MX レコード変更後に移行バッチを停止・削除
MX レコード切り替え後、新着メールが Microsoft 365 に直接届くことを確認したら、移行バッチを停止（または完了）し、最終同期を確認したうえで不要であれば削除します。
IMAP 移行の制限事項：
IMAP で移行されるのは メール（受信トレイ・フォルダー内のアイテム）のみ です。
連絡先・予定表・タスクは移行されません。
これらは手動でエクスポート＆インポートが必要です。
参考:
IMAP メールボックスを Microsoft 365 または Office 365 に移行する方法について知っておくべきこと参考: Exchange Online での移行バッチの管理
POP3 方式の場合：
PST ファイル経由のインポート
POP3 ではメールはすでにクライアント PC 上にあるため、サーバー側の移行バッチは使えません。
方法 A：Outlook 経由でアップロード
- ユーザーの Outlook に新しい Exchange Online アカウントを追加設定
- 旧メールを旧アカウントのフォルダーから Exchange Online アカウントのフォルダーにドラッグ＆ドロップ
- Outlook が自動的に Exchange Online へアップロード同期
方法 B：PST ファイルを管理者がインポート
- Outlook で旧アカウントのメールを PST ファイルとしてエクスポート
- Microsoft 365 コンプライアンスセンターの インポートサービス からネットワーク経由でアップロードしてインポート
POP3 環境の注意点：
旧 PC 上にメールが散在しているケースが多く、全ユーザー分の収集が手間になりやすいです。
Xデー前後に並行して実施するよう計画してください。
フェーズ 4〜5 ｜
Xデーの MX レコード切り替えとプロパゲーション期間の乗り切り方
Xデーの作業：MX レコードの切り替え
Xデーの推奨作業時間帯：平日の夜間（業務終了後）または週末
1. 旧 MX レコードを削除（または優先度を下げる）
2. Microsoft 365 の MX レコードを追加
例：yourdomain-co-jp.mail.protection.outlook.com（優先度：0）
3. TTL は 3600〜7200 秒（1〜2時間）程度に設定
Microsoft 365 の正確な MX レコード値は、
管理センターの「設定」→「ドメイン」→ 対象ドメインの「DNS レコードの確認」から取得できます。
旧 MX を残す方法もある：
旧 MX レコードを削除せず、優先度を Microsoft 365 より低く設定することで（例：旧 MX 優先度 20、新 MX 優先度 0）、Microsoft 365 に障害が発生した場合のフォールバックとして機能することを期待して旧 MX を残すケースもあります。
ただ、送信側は通常最優先の MX のみを使用するため、実際にはフォールバックとして機能しない場合が多い点に注意が必要です。
ただしプロパゲーション期間中に旧サーバーへのメール流入が増えるリスクもあるため、状況に応じて判断してください。
プロパゲーション（DNS 浸透期間）の正体
MX レコードを変更しても、インターネット上の無数の DNS キャッシュサーバーは、それぞれ古いキャッシュを TTL の時間分保持し続けます。
このため、DNS 変更直後は 送信元によって「旧サーバー」に届くものと「新サーバー（Microsoft 365）」に届くものが混在します。
この状態がプロパゲーション期間です。
TTL を事前に 300 秒（5分）に設定していれば理論的には数分で浸透しますが、一部の DNS リゾルバーでは TTL より長くキャッシュされるケースもあるとされており、理論値より長く浸透に時間がかかる場合があります。
実務では 「MX 変更後 1〜48 時間はプロパゲーション期間として扱う」 のが安全です。
プロパゲーション期間を乗り切る実務テクニック
【テクニック 1】旧サーバーを MX 変更後も最低 48〜72 時間は稼働させ続ける
プロパゲーション期間中、旧 MX を参照する外部サーバーからのメールは旧サーバーに届き続けます。
旧サーバーを早期に停止するとこれらのメールが消失します。
MX 変更後も旧サーバーのサービスを維持し、旧サーバーに届いたメールも受信できる状態を保ちます。
推奨の並行稼働期間（目安） ・TTL を 300 秒に設定済みの場合 → 24〜48 時間 ・TTL を 3600 秒に設定済みの場合 → 48〜72 時間 ・TTL が未変更（86400 秒）だった場合 → 最低 1 週間
【テクニック 2】IMAP 移行バッチの差分同期を MX 変更後も一定期間維持する
IMAP 移行バッチは MX 変更後も自動で差分同期を続けます。
つまり MX 変更後も旧サーバーに誤配された新着メールを Microsoft 365 側に自動で取り込んでくれます。
プロパゲーション期間の「メールが旧サーバーに届いてしまう問題」を実質的にカバーできます。
これが IMAP 移行最大のメリットです。
MX 変更後も最低 24〜48 時間は移行バッチを削除せず同期を継続しましょう。
【テクニック 3】ユーザーはプロパゲーション収束まで両方のメールを確認する
旧メールクライアント（旧サーバー接続）と新 Outlook（Microsoft 365 接続）の両方をしばらく並行して確認するようユーザーに周知します。
具体的には：
- 旧 Outlook / Thunderbird / メールアプリ（旧サーバー接続）→ MX 変更直後も監視継続
- 新 Outlook / Outlook on the Web（Exchange Online 接続）→ 新着メールの確認
【テクニック 4】DNS 伝播チェッカーで浸透状況を確認する
https://www.whatsmydns.net/ などの DNS 伝播チェッカーを使い、世界各地の DNS サーバーが新 MX レコードを返しているかリアルタイムで確認できます。
大部分が新 MX を返していれば旧サーバーへの流入が収まりつつあるサインです。
【テクニック 5】旧サーバーのメールログを確認する
旧サーバーの受信ログを監視し、新着メールの件数がゼロに近づいたことを確認してからサービスを停止します。
感覚的な判断ではなくログに基づいて判断することが重要です。
MX レコード変更後に行う作業
1. Microsoft 365 に新着メールが届いていることを確認
2. 旧サーバーのメールも引き続き監視
3. IMAP 移行バッチの最終同期状況を確認（Synced / 同期完了）
4. 承認済みドメインを「権限あり（Authoritative）」に変更
5. 旧サーバーへのコネクタ設定を削除
6. 旧 MX レコードを削除（プロパゲーション収束後）
メール認証設定（SPF / DKIM / DMARC）の整備
なぜ今やらないといけないのか
Google（Gmail）の送信者ガイドライン変更により、SPF・DKIM・DMARC のいずれかが未設定だと Gmail に届かなくなるリスクが現実のものになっています。
Microsoft 365 への移行はメール認証を整備する絶好のタイミングです。
SPF レコード（移行前に設定）
SPFレコードの「書き換え」手順
SPFレコードは「追加」ではなく「統合」するのが正解です。
移行完了（最終形）： v=spf1 include:spf.protection.outlook.com -all
移行中（ハイブリッド状態）： v=spf1 include:spf.protection.outlook.com include:[旧サーバーのSPF] ~all
移行期間中は旧サーバーの SPF も含め、移行完了後に旧サーバー分を削除します。
DKIM の設定（Xデー後に設定）
- Microsoft Defender ポータル または Exchange 管理センターから DKIM を設定できます。
- 対象ドメインを選択し、CNAME レコード 2 つ（selector1, selector2）を取得
- DNS に CNAME レコードを追加
- DKIM 署名を「有効」に変更
DMARC の設定（DKIM 設定後に追加）
まずはレポート収集から始めます：
v=DMARC1; p=none; rua=mailto:dmarc-report@yourdomain.co.jp
レポートを分析しながら徐々にポリシーを強化（none → quarantine → reject）します。
Microsoft はこの段階的な強化を推奨しています。
よくある失敗事例と対策
失敗例 1：
MX レコード変更と同時にユーザーアカウントを作成した
何が起きたか：
メールボックスが存在しないまま MX を切り替えたため、外部から届いたメールが NDR（配信不能）になってバウンスした。
対策：
ユーザーアカウントとライセンス付与は MX 変更の 1〜2 週間前に完了させる。
失敗例 2：
TTL を短縮せずに MX レコードを変更した
何が起きたか：
TTL が 86400 秒（24時間）のままだったため、世界中の DNS サーバーが最大 24 時間も古い MX を参照し続け、メールが旧サーバーに届いてしまった。しかも旧サーバーはすでに停止していたためメールが消失した。
対策：
MX 変更の最低 48 時間以上前に TTL を 300〜3600 秒に変更する。
失敗例 3：
承認済みドメインの設定を変更しなかった
何が起きたか：
Microsoft 365 のドメイン登録直後から、テナント内ユーザーが同じドメインのユーザー（まだ旧サーバー使用中）にメールを送ると NDR が返った。
対策：
Xデー前は承認済みドメインを「内部の中継」に設定し、旧サーバーへのコネクタを作成する。
失敗例 4：
POP3 環境でデータ移行なしに MX を切り替えた
何が起きたか：
旧サーバーにメールが残っていると思っていたが POP3 だったため、データはすべてクライアント PC にあり、旧サーバーは空だった。移行後に「過去メールが見られない」と苦情が殺到した。
対策：
POP3 かどうかを事前に確認し、クライアント PC のメールデータを PST エクスポートして移行計画に組み込む。
失敗例 5：
SPF レコードを新しく別途追加した
何が起きたか：
既存 SPF レコードに加えて、Microsoft 365 用の SPF レコードを別の TXT レコードとして追加してしまった。
SPF は複数の TXT レコードが存在するとエラーになるため、送信メールがスパム扱いになった。
対策：
SPF レコードは必ず 1 つ。
既存レコードの ~all の前に include:spf.protection.outlook.com を追記する。
移行後チェックリスト
【メール疎通確認】
□ 外部→Microsoft 365 への受信テスト（Gmail 等から送信）
□ Microsoft 365→外部への送信テスト
□ 組織内ユーザー間のメールテスト
【DNS 設定確認】
□ MX レコード → Microsoft 365 を指しているか
□ SPF レコード → include:spf.protection.outlook.com のみに整理
□ DKIM → Defender ポータルで「有効」になっているか
□ DMARC → TXT レコードが設定されているか
□ Autodiscover CNAME → autodiscover.outlook.com を指しているか
【Microsoft 365 設定確認】
□ 承認済みドメインが「権限あり」になっているか
□ 旧サーバーへのコネクタが削除されているか
□ IMAP 移行バッチが削除されているか
□ 全ユーザーにライセンスが付与されているか
【ユーザー側確認】
□ Outlook の接続先が Exchange Online になっているか
□ スマートフォンのメール設定が更新されているか
□ 共有メールボックス・配布グループが移行されているか
おわりに
レンタルサーバーから Microsoft 365 への移行は、正しい手順と順番を守れば業務を止めずに完遂できます。
最大のポイントを改めてまとめます。
- MX レコード変更前に メールボックスを作成してライセンスを付与する
- 切り替えの 48 時間以上前に TTL を短縮する
- IMAP の場合は Xデー前から 移行バッチで差分同期を開始しておく
- プロパゲーション期間（最低 48〜72 時間）は旧サーバーを並行稼働させる
- POP3 の場合はクライアント PC のデータ移行を忘れずに計画する
これらを守ることで、「メールが届かない時間」や「過去メールの消失」といった最悪の事態を防ぐことができます。
免責事項：Microsoft 365の機能や仕様は変更される可能性がありますので、実施前には最新の公式ドキュメントをご確認ください。
