メール移転では、MXレコードを変えただけで新旧の受信箱が自動的に一つになるわけではありません。過去メールは端末または旧サーバーに残り、新しいメールはDNSを参照した配送先へ届きます。利用者・保存データ・配送経路を別々に移し、最後に一つの運用へ戻します。

アドレスではなく利用者と保存先を棚卸しする

現在のメールアドレスを、個人用・共有窓口・転送専用・システム送信用に分けます。同じアドレスを複数人が使っている場合は、各端末がPOPかIMAPかも確認します。POPでは受信済みメールが端末だけに残る設定があり、IMAPではサーバー上の状態と同期します。プロトコル名だけで保存場所を決めつけず、実端末とWebメールで確認します。

退職者のメールやローカルアーカイブも移行対象を決めます。すべてを新しい受信箱へ入れるのか、監査用に別保存するのかで作業量が変わります。アドレスごとに利用者・端末・保存量・移行方法・確認者を記録します。パスワードを一覧へ平文で書かず、管理された方法で本人へ配布します。

新環境はDNS変更前に受信箱まで用意する

新しいサービスでドメインを確認し、必要な利用者と共有先を作ります。容量やアドレス形式だけでなく、転送・自動返信・メーリングリストの動作も旧環境と照合します。新しい接続先を使って送受信を試せる場合は、DNSを切り替える前にテストします。管理者だけでなく代表利用者の端末でも確認します。

過去メールを移す場合は少量で試行し、送信者・受信日時・フォルダ構成が保たれるかを見ます。Google WorkspaceやMicrosoft 365には移行機能がありますが、元サービスと認証方式によって対応範囲は変わります。移行件数とエラーを記録し、失敗分を再実行できる手順を作ってから全体を移します。

MXと送信認証は一つの変更票で扱う

受信先を示すMXだけでなく、送信元を示すSPFやDKIM、DMARCも新しい構成へ合わせます。Webフォームや業務システムが旧サーバーから送信を続ける場合は、その送信経路を残す必要があります。新旧両方から送る移行期間を想定し、公式の設定値から一つの整合したDNS案を作ります。SPFレコードを別々に二つ置きません。

変更前のDNS値とTTLを記録し、戻す条件を決めます。TTLを短くしても、変更前の値がキャッシュされている間は旧受信箱へ届く可能性があります。固定の反映時間で旧環境を止めず、新旧の受信状況を観察します。DNS管理者とメール管理者が異なる場合は、変更時刻と確認結果を同じ連絡票で共有します。

切り替え中は新旧双方で受信を確認する

切り替え直後は、社外の複数サービスから各代表アドレスへ送ります。新環境で受信できることに加え、返信が相手へ届くことと迷惑メール判定も確認します。社内同士だけのテストでは、外部への配送や認証の問題を見落とします。送信ログやヘッダーを使い、どの経路を通ったかを記録します。

旧受信箱も並行して確認します。旧側へ届いたメールは新側へ取り込むか、利用者へ転送する方法を決めます。単純な自動転送は送信認証へ影響する場合があるため、サービス公式の移行方法を優先します。新旧で同じ返信をしないよう、問い合わせ窓口の担当を一時的に一人へ集約します。

端末設定は配布と完了確認を分ける

端末の設定値は、受信・送信サーバー名・ポート・暗号化・認証名を新サービスの公式案内から配布します。画面位置はアプリの更新で変わるため、古いメニュー名を固定した手順にしません。設定変更の前に端末内だけのメールが消えないか確認し、必要ならエクスポートします。利用者が自分で変更する場合も問い合わせ窓口を決めます。

完了報告は「設定した」ではなく、外部からの受信と外部への送信が成功した状態にします。PCだけでなく業務で使うスマートフォンも対象です。複合機やWebフォームがメールを送る会社では、それらを別の送信端末として確認します。未完了の端末が分かる一覧を残し、旧パスワードの停止時期を揃えます。

旧サービスは差分回収後に終了する

過去メールの初回コピー後にも旧受信箱へ新着が増えるため、終了前に差分移行を行います。新旧の件数だけでなく、重要フォルダと直近期間を抽出して確認します。移行エラーや利用者からの未着申告が解消し、DNSが新構成で安定したことを完了条件にします。条件を満たす前に旧契約を解約しません。

終了時には旧メールボックスの最終保存と、管理画面の設定記録を残します。DNSから不要になった送信元を外し、旧アカウントを停止します。新しい利用者一覧と退職時の停止手順も台帳へ反映します。メール移転はMX変更で終わらず、旧側に届いた最後の一通を回収し、新環境だけで送受信を管理できたときに完了します。