レンタルサーバー（ホスティング会社）を乗り換えるとき、ホームページの移設だけでなくメールサーバーの移行作業もついてまわります。
Webサイトなら多少表示が乱れてもあとで直せますが、メールはそうはいきません。切り替えのタイミングを誤ると、その隙に届いたメールがどこにも残らず消えてしまうことがあるからです。ビジネスで使っているアドレスなら、たった数通の取りこぼしが大きなトラブルになりかねません。
私自身も何度かサーバー移転に立ち会ってきましたが、いちばん神経を使うのがこのメールの引き継ぎです。ここではDNS（MXレコード）の切り替えを軸にしたメールサーバー移行の手順と、メールを一通も落とさないための注意点を、現在の実務に沿ってまとめておきます。
メール移行でつまずく仕組みを先に押さえる
どのメールをどのサーバーが受け取るかは、ドメインのMXレコードというDNSの設定で決まります。移行とは、このMXレコードの宛先を旧サーバーから新サーバーへ差し替える作業だと考えるとわかりやすいです。
やっかいなのは、MXレコードを書き換えても世界中が同時に新しい設定へ切り替わるわけではない点です。DNSにはTTL（Time To Live）という「この情報は何秒キャッシュしてよい」という有効期限があり、各所のDNSキャッシュがこの期限切れを迎えるまで、しばらく古い宛先を覚え続けます。
この「切り替わりきるまでの時間差」の間は、送信側の環境によってメールが旧サーバーに届いたり新サーバーに届いたりバラつきます。ここで旧サーバーを早々に止めてしまうと、旧サーバー宛てに届いた分が受け取れず消えてしまう、というのがメール移行の典型的な失敗です。
DNS切り替えによるメールサーバー移行の手順
上の仕組みを踏まえると、やるべきことは「新サーバーを先に受け入れ態勢にしておき、切り替え後もしばらく旧サーバーを生かして両方で受ける」に尽きます。順を追って進めましょう。
1. 事前にMXレコードのTTLを短くしておく
切り替えの少なくとも1〜2日前に、ドメインのMXレコード（および必要ならAレコード）のTTLを短い値、たとえば300秒（5分）程度に下げておきます。
TTLは変更後すぐに効くわけではなく、それまで各所にキャッシュされていた「元の長いTTL」が切れて初めて短い値に置き換わります。だからこそ本番の数日前という前倒しが効いてきます。ここを短くしておくと、当日MXを差し替えたときの切り替わりが数分〜数十分単位まで縮み、旧新が混在する時間帯を大幅に短くできます。
2. 新サーバーにメールアカウントを用意する
新しいサーバーのコントロールパネルで、これまで使っていたメールアドレスをすべて作成します。転送設定やエイリアス、メーリングリストなど、旧サーバーで組んでいた仕掛けも忘れず再現してください。
この時点ではまだMXレコードは旧サーバーのままなので、実運用のメールは旧サーバーに届き続けます。あわてず、アカウントの作り漏れがないかを落ち着いて確認できます。
3. 認証（SPF・DKIM・DMARC）を新サーバー向けに合わせる
受信だけでなく送信も止めないために、送信に関わるDNSの認証設定を新サーバーに合わせて見直します。
具体的には、新サーバーの送信元を許可するようSPFのTXTレコードを更新し、新サーバーでDKIMの署名鍵を発行してそのTXTレコードを追加します。DMARCを運用している場合は、SPF・DKIMが新環境で正しく通ることを確かめてからポリシーを維持します。ここがずれていると、移行後に送ったメールが迷惑メール扱いされたり届かなくなったりするので、受信側だけでなく送信側の確認も必ずセットで行ってください。
4. メールクライアント側に新サーバーの設定を追加する
自分たちが使うメールソフト（Outlook、Thunderbird、スマホのメールアプリなど）には、新サーバーの受信・送信サーバー情報でアカウントを追加します。
このとき旧サーバーの設定はすぐ消さず、新旧の両方を残しておくのがおすすめです。切り替え直後は旧サーバーにもまだメールが届くため、両方を開いておけば取りこぼしに気づけますし、旧サーバーに残った過去メールの回収もしやすくなります。
5. MXレコードを新サーバーに切り替える
準備が整ったら、いよいよMXレコードの宛先を新サーバーへ書き換えます。これがメール移行の本番です。
作業はビジネスへの影響が少ない夜間や週末を選ぶと安心です。事前にTTLを短くしてあれば、新しい宛先はおおむね数分から数十分で行き渡り始めます。
6. しばらく新旧を並行運用して取りこぼしを防ぐ
切り替え後も旧サーバーはすぐに止めず、数日は生かしたまま並行運用します。旧サーバー宛てに届いていないか、新サーバーに正しく届いているかを両方で確認しましょう。
新サーバーだけにメールが届く状態が丸一日以上安定して続いたことを確認できたら、ようやく旧サーバーを停止し、下げていたTTLを通常の値へ戻します。この「確認できてから止める」を守るだけで、移行時のメール消失はほぼ防げます。
補足：「DNS浸透（プロパゲーション）」という言い方の誤解
移行の説明でよく「DNSが浸透するまで待つ」「プロパゲーションに1〜2日かかる」と言われます。この言い回しは実態を少しゆがめて伝えているので、補足しておきます。
DNSの変更は、どこか中央からじわじわ各サーバーへ「配られていく（浸透していく）」わけではありません。実際に起きているのは各所のDNSキャッシュの有効期限（TTL）切れです。世界中のDNSキャッシュサーバーは、それぞれが持っているキャッシュのTTLが切れたときに初めて権威DNSへ最新の値を取りに行きます。つまり「浸透待ち」の正体は「キャッシュの期限切れ待ち」で、待ち時間の上限を決めているのは切り替え前のTTLです。
だからこそ、手順1でTTLを事前に下げておくことが効きます。「24〜48時間かかる」という説明も、TTLが長かった時代の名残であって固定の決まりではありません。TTLを短くしてあれば、実際の切り替わりはずっと早く済みます。
移行時の注意点
- TTLは前倒しで下げる：当日に下げても間に合いません。少なくとも1〜2日前に短くしておくことで、切り替えの待ち時間が縮みます。
- 旧サーバーはすぐ止めない：新サーバーだけに安定して届くのを確認するまで、数日は並行運用してメールの取りこぼしを防ぎます。
- 送信認証をセットで見直す：SPF・DKIM・DMARCを新サーバーに合わせないと、受信はできても送ったメールが届かない・迷惑メール扱いになることがあります。
- 過去メールの移行を忘れない：旧サーバーに溜まっている受信済みメールは自動では移りません。IMAPでの引き継ぎやエクスポートで、重要なメールを取り残さないようにします。
- 関係者への事前連絡：移行作業のタイミングを社内やクライアントに伝えておくと、万一の不達時も対応がスムーズです。
まとめ
メールサーバーの移行でいちばん怖いのは、切り替えの時間差にまぎれてメールが消えることです。それを防ぐ勘どころは、事前にTTLを下げる／新サーバーを先に整える／切り替え後もしばらく旧サーバーを並行運用するの3つに集約されます。
「DNS浸透」を漠然と待つのではなく、TTLとキャッシュの仕組みを理解して段取りを組めば、メールを一通も落とさずに移行できます。焦って旧サーバーを止めないことだけは、くれぐれも忘れないでください。
