Jomo Jomo

オンプレミスメールサーバーからMicrosoft 365への移行

Exchange Serverからexchange Onlineへの移行について、DNS設定やメール認証設定、段階的カットオーバーの手順をひとり情シスの視点で解説します。

状況：オンプレミスメールサーバーの運用が限界に

社員60名の中小企業で、社内に設置したExchange Server 2016でメールを運用しています。しかし、以下の問題が蓄積し、クラウドへの移行が不可避となりました。

  • サーバーハードウェアの老朽化：導入から7年が経過し、ディスク障害の予兆が出始めている
  • セキュリティパッチの適用負担：Exchange Serverの脆弱性が頻繁に報告され、毎月のパッチ適用に手間がかかる
  • スパム・マルウェア対策の限界：オンプレミスのスパムフィルターでは最新の攻撃メールをブロックしきれない
  • リモートワーク対応の困難：社外からのメールアクセスにVPNが必要で、社員からの不満が増加
  • メールボックスの容量管理：社員からの「容量が足りない」という相談が頻発

経営層と協議し、Microsoft 365（M365）のExchange Onlineへの移行を決定しました。すでに一部の社員がWordやExcelでM365を利用しているため、追加ライセンスの調達ではなく、既存ライセンスのメール機能を有効化する形で進めます。

💡 ポイント

ひとり情シスにとって、メールサーバーの運用は「最も負荷が高いサーバー管理業務」の一つです。24時間365日の稼働が求められ、障害時は「メールが使えない＝業務が止まる」という即座の影響があります。M365への移行により、この負担から解放されるだけでなく、50GBのメールボックス容量、高度なスパムフィルター、モバイルアクセス等が標準で利用可能になります。

事前準備フェーズ

ステップ1：現環境の棚卸し

移行前に現在のメール環境を正確に把握します。

  • メールアカウント数：個人アカウント60個 + 共有メールボックス（info@、support@等）5個 + 配布グループ10個
  • メールボックスサイズ：平均3GB × 60名 ＝ 約180GB（最大の社員は15GB）
  • メールドメイン：example.co.jp（メイン）、example.com（サブ）
  • 利用クライアント：Outlook 2019が50名、Outlook 2016が10名
  • メールフロー：メーリングリスト、転送ルール、自動返信の設定

📋 具体例

Exchange Management Shellで以下のコマンドを実行すると、全メールボックスのサイズ一覧を取得できます：
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName, TotalItemSize, ItemCount | Sort TotalItemSize -Descending | Export-CSV C:\mailbox_sizes.csv -NoTypeInformation

このCSVファイルを確認し、特に大きなメールボックスを持つユーザーを事前に把握しておきます。M365のExchange Onlineは1メールボックスあたり50GBなので、容量の心配はほぼありません。

ステップ2：M365テナントの準備

M365の管理センター（admin.microsoft.com）で以下を準備します。

  1. カスタムドメインの追加：example.co.jpをM365テナントに追加し、所有権を確認（TXTレコードまたはMXレコードで検証）
  2. ユーザーアカウントの作成：全社員のM365アカウントを作成（Azure AD Connectで同期済みの場合は不要）
  3. ライセンスの割り当て：Exchange Onlineを含むライセンスを各ユーザーに割り当て

⚠️ 注意

カスタムドメインの追加時に、DNSのMXレコードをM365に変更するよう指示されますが、この段階ではMXレコードを変更しないでください。MXレコードを変更するとメールの配送先がM365に切り替わりますが、メールデータの移行が完了していない段階で切り替えると、過去のメールが参照できなくなります。MXレコードの変更はメールデータ移行完了後に行います。

ステップ3：メール認証設定の準備

メールの信頼性を確保するために、以下のDNS認証レコードを設定します。これらはメールの到達率向上となりすまし防止に不可欠です。

SPF（Sender Policy Framework）

自社ドメインからのメール送信を許可するサーバーを宣言するDNSレコードです。

📋 具体例

M365用のSPFレコード例：
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

・include:spf.protection.outlook.com：M365のメールサーバーからの送信を許可
・-all：上記以外のサーバーからの送信を拒否（ハードフェイル）
移行期間中は、旧Exchange Serverからも送信するため、旧サーバーのIPアドレスも含めます：
"v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

DKIM（DomainKeys Identified Mail）

メールに電子署名を付与し、送信者の正当性を証明する仕組みです。M365の管理センターから有効化できます。

DMARC（Domain-based Message Authentication, Reporting and Conformance）

SPFとDKIMの検証結果に基づいて、認証に失敗したメールの扱いを指定するポリシーです。

📋 具体例

DMARCレコード例（段階的に強化）：

初期導入時（モニタリングモード）：
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.jp; ruf=mailto:dmarc-reports@example.co.jp"

・p=none：認証失敗してもメールは配信する（まずはレポートの収集のみ）
・rua：集計レポートの送信先

運用安定後（検疫モード）：
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.co.jp"

最終目標（拒否モード）：
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.co.jp"

💡 ポイント

SPF/DKIM/DMARCの設定は、メール移行のタイミングで一緒に行うのが効率的です。特にDMARCは最初から「p=reject」にすると正当なメールも拒否される可能性があるため、必ず「p=none」から始めて、数週間のレポートを確認してから段階的に強化してください。Google宛てのメールは2024年2月から送信者ガイドラインが厳格化されており、SPF/DKIM/DMARCの設定は必須になっています。

移行フェーズ

ステップ4：メールデータの移行

オンプレミスExchange Serverのメールデータ（メール、カレンダー、連絡先）をExchange Onlineに移行します。主な移行方法は以下の3つです。

方法1：カットオーバー移行（一括移行）

  • 対象：150メールボックス以下の環境（今回はこの方法を選択）
  • 特徴：全メールボックスを一括で移行。ダウンタイムは数時間～1日程度
  • 手順：M365管理センターの移行ウィザードからExchange Serverへの接続を設定し、一括移行バッチを実行

方法2：段階的移行

  • 対象：メールボックス数が多い場合や、長期間にわたって段階的に移行したい場合
  • 特徴：部門ごとに分けて移行。移行期間中はオンプレミスとクラウドが共存

方法3：PST移行

  • 対象：Exchange Server以外のメールサーバーからの移行
  • 特徴：各ユーザーのメールをPSTファイルにエクスポートし、M365にインポート

⚠️ 注意

メールデータの移行には、データ量に応じて数時間～数日かかります。180GBのデータ移行の場合、ネットワーク速度にもよりますが8～24時間程度を見込んでください。移行中もオンプレミスのメールは通常通り利用可能です。移行は金曜夜に開始し、土日で完了させるスケジュールが理想的です。

ステップ5：DNS切り替え（MXレコードの変更）

メールデータの移行が完了したら、DNSのMXレコードをM365に向けて変更します。これにより、新しいメールがExchange Onlineに配信されるようになります。

📋 具体例

MXレコードの変更例：

変更前（オンプレミス向け）：
example.co.jp. IN MX 10 mail.example.co.jp.

変更後（M365向け）：
example.co.jp. IN MX 0 example-co-jp.mail.protection.outlook.com.

Autodiscover用のCNAMEレコードも追加します：
autodiscover.example.co.jp. IN CNAME autodiscover.outlook.com.

DNS変更後、世界中のDNSサーバーに伝播するまで最大48時間かかりますが、通常は数時間以内に大半が切り替わります。TTL（Time To Live）を事前に短く（300秒程度）しておくと、切り替えが速くなります。

ステップ6：クライアント設定の確認

MXレコードの切り替え後、各社員のOutlookクライアントがExchange Onlineに正しく接続しているか確認します。

  • Outlookの「アカウント設定」を確認し、接続先がExchange Onlineになっているか
  • Autodiscoverが正しく動作していれば、多くの場合は自動的に接続先が切り替わる
  • 切り替わらない場合は、Outlookプロファイルの再作成が必要

💡 ポイント

ひとり情シスの視点では、60名全員のOutlookの接続確認を1人で行うのは大変です。事前に「メール移行のお知らせ」を全社に配信し、「月曜朝にメールの送受信テストをお願いします。問題があればチャットで連絡ください」と案内しておくのが効率的です。また、「Outlookが接続できない場合の手順書」をA4一枚で作成し、全社員のデスクに配布しておくと、問い合わせ対応の負荷を大幅に軽減できます。

移行後の運用

旧Exchange Serverの停止

移行完了後、旧Exchange Serverは最低2週間は稼働させたまま経過観察します。問題がないことを確認してから、以下の手順で停止します。

  1. 全ユーザーのOutlookがExchange Onlineに接続していることを確認
  2. 旧サーバーにメールが配送されていないことを確認
  3. 旧サーバーのExchange役割をアンインストール
  4. サーバーの電源を切り、1ヶ月間保管後に廃棄

M365の運用ポイント

  • 迷惑メールフィルターの調整：Exchange Online Protection（EOP）の設定を確認し、必要に応じてホワイトリスト/ブラックリストを調整
  • メールフローのルール：旧サーバーで設定していた転送ルールやメーリングリストをM365で再設定
  • 監査ログの有効化：メールボックスの監査ログを有効にし、不正アクセスの検知に備える

⚠️ 注意

M365への移行後も、SPFレコードから旧サーバーのIPアドレスを削除することを忘れないでください。旧サーバーのIPアドレスがSPFレコードに残っていると、そのIPアドレスを悪用したなりすましメールが送信される可能性があります。旧サーバー停止後、速やかにSPFレコードを更新しましょう。

まとめ

  • オンプレミスメールサーバーの運用はひとり情シスにとって大きな負担であり、M365への移行で大幅に軽減される
  • メール認証（SPF/DKIM/DMARC）は移行と同時に設定し、段階的に強化する
  • MXレコードの変更はメールデータの移行完了後に行う（順序が重要）
  • DNS変更前にTTLを短くしておくと切り替えがスムーズ
  • 移行後の旧サーバーのSPFレコード削除とサーバー廃棄を忘れずに