メール移転で失敗しないための注意点と手順

メール移転は、新しいメールボックスを用意し、過去メールをコピーしてから、DNSとメールアプリの接続先を切り替える流れです。同じメールアドレスを作るだけでは、過去メールは自動で移りません。

切り替え直後には旧サーバーへ届くメールもあるため、しばらく新旧を併用します。旧契約の解約やアプリのアカウント削除は、過去メールと移行中の新着を回収した後になります。

移管後にメールが届かないときは配送先から確認する

すでに未着が起きている場合は、旧契約の解約やメールアプリのアカウント削除を止めます。まず受信できなかった宛先と時刻、送信者に返ったエラーを記録し、受信経路を確認します。

ドメインの管理会社を変える移管と、メールサーバーの移転は別の作業です。さくらの移転ガイドでも、この二つを区別しています。移管と同時にネームサーバーを変更した場合は、新しいDNSに従来のMXなどを引き継いだか、現在使われているネームサーバー側で確認します。古い管理画面の値だけを見て判断しません。

MXが予定した配送先を指していたら、そのサービスに同じ宛先のメールボックスや転送先が作成されているかを確認します。新旧双方のWebメールも調べ、旧側だけに届いているのか、どちらにも見当たらないのかを分けます。端末から送信だけできない場合は、MXではなく送信サーバー名や認証情報も確認します。

正しい設定が分からないままMXやネームサーバーを何度も変えないことが重要です。DNS管理者とメール事業者へ変更前後の値・時刻・返送エラーを渡し、メール未着の切り分けを進めます。受信箱が空に見えても、旧側の過去メールを消してよいという意味ではありません。

過去メールがどこに残っているか

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

退職者のメールやローカルアーカイブも移行対象を決めます。すべてを新しい受信箱へ入れるのか、監査用に別保存するのかで作業量が変わります。複数人を移す場合は、アドレスごとに保存先と移行済みかが分かる一覧が役立ちます。パスワードを一覧へ平文で書かず、管理された方法で本人へ配布します。

過去のメールは保存場所ごとに移行方法を決める

同じメールアドレスを新サーバーに作っても、過去のメールは自動では移りません。受信箱だけでなく送信済みや保管フォルダーも調べ、残っている場所に合う方法を選びます。

たとえばMicrosoft 365のIMAP移行は、メールフォルダーを対象とし、連絡先・予定表・タスクは移しません。別方式の移行機能では対象が変わるため、利用する方式の公式案内を確認します。大きいメールや特殊なフォルダーが除外されないかも少量試行で調べます。

コピー後は合計件数だけでなく、重要なメールを新環境で開いて本文と添付を確かめます。旧側を残した状態で試し、重複や取りこぼしがあれば対象を絞ってやり直します。アプリのアカウント削除や旧契約の終了は、この確認と最後の差分回収が終わった後です。

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

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

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

受信先と送信認証を新しい環境にそろえる

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

変更前のDNS値とTTLを記録し、戻す条件を決めます。TTLを短くしても、変更前の値がキャッシュされている間は旧受信箱へ届く可能性があります。MXレコード変更前後のチェックリストに沿って、新旧の受信状況を観察します。DNSとメールを別の担当者が管理している場合は、変更時刻と結果を共有します。

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

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

旧受信箱も並行して確認します。旧側へ届いたメールは新側へ取り込むか、利用者へ転送する方法を決めます。単純な自動転送は送信認証へ影響する場合があるため、サービス公式の移行方法を優先します。共有窓口では、新旧どちらで返信したかが分かるようにすると、重複した対応を防ぎやすくなります。

メールアプリも新しい接続先に設定する

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

設定値を入力しても、認証エラーなどで送受信できない場合があります。外部のアドレスとの往復で確認すると、この違いが分かります。PCだけでなく業務で使うスマートフォンも対象です。複合機やWebフォームがメールを送る会社では、それらを別の送信端末として確認します。未着があればメール配送の切り分け方で原因を調べ、旧パスワードの停止時期を揃えます。

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

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

終了時には旧メールボックスの最終保存と、管理画面の設定記録を残します。DNSから不要になった送信元を外し、旧アカウントを停止します。旧側に新着が残っている間は、新しい受信箱だけを見ていると見落としが生じます。DNSの切り替えとメールの回収を別の作業として考えることが、移転時の取りこぼしを防ぐポイントです。