サーバー移転でメールが止まる原因と、止めない手順6つ

サーバー移転でメールが止まったとき、まず知っておくべきことがひとつあります。「消えた」と思っているメールの多くは、消えていません。旧サーバーの受信箱に入ったまま残っています。ネームサーバーを切り替えても、世界中の DNS キャッシュが一斉に新しい設定へ入れ替わるわけではないからです。

切り替えの直後は、新サーバーと旧サーバーの2台に、送信元ごとにバラバラに届く期間が発生します。Google Workspace の管理者ヘルプでも、新しい MX レコードがインターネット全体で認識されるまで最長で72時間ほどかかることがあると明記されています（Google Workspace の MX レコードを設定する）。この記事では、なぜ止まるのかの仕組みと、止めないための作業順序、すでに起きてしまった場合の切り分けを、実務の順番どおりにまとめます。

結論：止まる原因は「伝播の遅さ」ではなく「2台同時期間」

先に結論だけ言い切ります。サーバー移転でメールが止まる・届かなくなる原因は、次の4つにほぼ集約されます。

• 新サーバーにメールアカウントを作る前に DNS を切り替えた（新サーバー側に受け皿が無く、届いたメールが宛先不明で送信元へ返る）
• 切り替え直後に旧サーバーを解約・停止した（旧サーバーに届いた分がまるごと消える。これが唯一、後戻りできない事故）
• メールソフトの設定を旧サーバー向けのまま放置した（新サーバーに届いた分だけが見えない）
• SPF / DKIM / DMARC を移転後に再設定していない（受信はできるが、送ったメールが相手の迷惑メールに落ちる）

逆に言えば、受け皿を先に作り、TTL を先に縮め、旧サーバーを最低でも数日残す。この3つを守るだけで、メールが止まる事故のほとんどは起きません。ダウンタイムをゼロに近づけるのは、特別な技術ではなく作業の順序の問題です。

なぜ止まるのか：DNS の「伝播」ではなく「2台に同時に届く期間」で理解する

ネームサーバー変更は一斉切り替えではない

よく「DNS の浸透待ち」と説明されますが、この言い方が誤解の元です。実際に起きているのは、世界中のプロバイダやクラウドのキャッシュ DNS サーバーが、それぞれ自分のタイミングで古い情報を捨てて新しい情報を取りに行くという現象です。捨てるまでの時間を決めているのが、レコードごとに設定された TTL（Time To Live）という値です。

つまり、キャッシュが切れたところから順に新サーバーを見るようになり、キャッシュが残っているところは切り替えたあとも旧サーバーへメールを送り続けます。エックスサーバーの案内でも、ネームサーバー変更後は数時間〜24時間ほどかけて徐々に移転され、その間は新旧どちらのサーバーで受信されるか予測できないとされています（エックスサーバー：サーバー移転中のメールの受信方法）。

「消えた」メールは、たいてい旧サーバーの受信箱にある

ここが現場で一番効く指摘です。移転後に「取引先からのメールが届かない」と言われたとき、送信元側ではエラーが返っていないケースがほとんどです。エラーが返っていない＝どこかのサーバーが正常に受け取っているということで、その受け取り先が旧サーバーなのです。

ですから最初にやるべきは、新サーバーの設定を疑うことではなく、旧サーバーの受信箱を開いて中を見ることです。旧サーバーのコントロールパネルにある Web メールから直接ログインすれば、その場で確認できます。旧サーバーが生きてさえいれば、この段階の「消えた」は100%取り戻せます。

逆に、旧サーバーを解約してしまっていると、この期間に届いた分は復旧できません。カゴヤの解説でも、旧サーバー側にメールが届かなくなったのを見届けてから解約する必要があると明記されています（カゴヤのサーバー研究室：メールサーバー移行を失敗しないための手順）。

止めないための作業順序：6ステップのチェックリスト

実務では、この順番を1つでも入れ替えると事故が起きます。特に①と④の順序、そして⑤は絶対に崩さないでください。

① 先に新サーバーでメールアカウントを同名で全部作る

DNS を触る前に、旧サーバーにあるメールアドレスを1つ残らず、同じ名前で新サーバーに作成します。info@・staff@ のような日常的に使うものだけでなく、フォーム送信用・EC の自動返信用・退職者宛の転送用など、普段人が開かないアドレスほど漏れます。

旧サーバーの管理画面からアドレス一覧を CSV などで書き出し、転送設定・エイリアス・自動返信・迷惑メールフィルタの条件までそのまま写すのが確実です。パスワードは同じにしておくと、メールソフト側の再設定が「サーバー名の変更だけ」で済みます。

② TTL を事前に短くする（例：3600秒 → 300秒）

切り替えの数日前に、対象ドメインの MX・A・CNAME レコードの TTL を短い値に変更しておきます。一般的な初期値は3600秒（1時間）や86400秒（24時間）で、これをそのままにして切り替えると、その時間ぶんキャッシュが居座ります。

重要なのは、「TTL を短くした設定そのものが、元の TTL の時間をかけて広まる」という点です。86400秒のまま TTL 変更だけ入れても、丸1日経たないと短い TTL は効きません。切り替えの最低でも元の TTL 相当の時間前に TTL を縮めておく、と覚えてください。なお、短い TTL は問い合わせ回数を増やすので、移転が落ち着いたら元の値に戻します。

③ IMAP で旧サーバーから新サーバーへメールデータを同期する

過去メールを引き継ぐなら、POP ではなく IMAP で移します。IMAP はサーバー上のフォルダ構成・既読未読・階層をそのまま扱えるので、受信箱以外のフォルダも含めて丸ごとコピーできます。方法は主に3つです。

• メールソフトで2アカウントを並べてドラッグ＆ドロップ：Thunderbird や Outlook に旧・新の両アカウントを IMAP で登録し、フォルダごとコピーする。件数が数千通程度までなら現実的で、特別なツールも要りません。
• サーバー側の移行ツールを使う：移転先のホスティング会社が「他社サーバーからのメール移行ツール」を用意していることがあります。旧サーバーの IMAP 情報を入力するだけで同期してくれるので、まずここを探すのが早いです。
• imapsync 等のコマンドラインツール：アカウント数が多い場合に向きます。差分同期ができるため、切り替えの前に1回、切り替えの数日後にもう1回走らせて、混在期間に旧サーバーへ届いた分を拾えます。

いずれの方法でも、同期は1回で終わりにしないのがコツです。混在期間中も旧サーバーにメールは届き続けるので、最後にもう一度だけ差分を取り込む前提で計画してください。

④ ネームサーバー／DNS レコードを切り替える

ここでようやく切り替えです。切り替え方は2通りあり、どちらを選ぶかで難易度とリスクが変わります。

• ネームサーバー（NS）ごと移転先に向ける：設定は楽ですが、MX・SPF・DKIM・サブドメインなどすべてのレコードが移転先の初期値に置き換わります。旧 DNS の全レコードを事前に控え、移転先で同じものを作り直しておかないと、Web は表示できてもメールだけ死にます。
• ネームサーバーは変えず、A レコードだけ新サーバーへ向ける：MX を含む他のレコードは一切動かないので、メールは一切止まりません。Web サーバーだけを移す案件では、こちらが圧倒的に安全です。

作業時間帯は、メールの流量が少ない金曜の夜や連休前が定番です。何か起きても、翌営業日までに旧サーバー側で受け止められる時間が稼げます。

⑤ 48〜72時間は旧サーバーを解約しない（後戻りできない一線）

この記事で唯一、絶対に守ってほしいのがこれです。旧サーバーの解約・停止だけは、やり直しが効きません。DNS の設定ミスは直せます。メールソフトの設定ミスも直せます。しかし、旧サーバーを解約した後に旧サーバーへ届いたメールは、二度と取り戻せません。

Google Workspace のヘルプが挙げる「最長72時間」を踏まえると、最低でも切り替えから48〜72時間、可能なら1か月程度は旧サーバーを契約したまま残すのが安全です。たかだか1か月分の費用で、失注1件ぶんのリスクを消せると考えれば安い保険です。旧サーバーの解約は、旧サーバーの受信箱に新着が数日間まったく入らなくなったことを確認してから行ってください。

⑥ 受信テストと SPF / DKIM / DMARC の再設定

切り替え後は、Gmail・Outlook.com・携帯キャリアなど系統の違う外部アドレスから3通以上テスト送信し、新サーバー側で受信できることを確認します。同時に、新サーバーから外部への送信テストも行い、相手の迷惑メールフォルダに入っていないかまで見てください。ここで手を抜くと、次章の「受信はできるのに送信だけ弾かれる」に直行します。

移転にともなうドメインまわりの整理は、そもそも「今どこで何を契約しているか」が分からないと始まりません。契約先が不明なまま作業に入ってしまいそうなら、ホームページのドメインとサーバーの管理先が分からないときの調べ方を先に済ませておくと、移転当日に慌てずに済みます。

ここまでの段取りを自社だけで回すのは、正直なところ負荷が高い作業です。Mihata では、ホームページの制作と一緒にサーバー移転・メール移行まで引き受けています。記事の途中で恐縮ですが、こうした移転ごと任せてしまいたい場合の選択肢として、よろしければご覧いただけたら嬉しいです。

症状別の切り分け表：もう止まってしまった場合

すでにトラブルが起きている場合は、「送信」と「受信」のどちらが壊れているかで原因がほぼ決まります。次の表で自分の症状を探してください。

なお、移転とは無関係にメールが届かなくなることもあります。契約は生きているのに受信だけできない場合は、独自ドメインのメールが受信できないときの原因の潰し方で、容量超過やフィルタ設定まで含めて順に潰していくのが早いです。

Google Workspace / Microsoft 365 なら「MX を触らない」でメールは止まらない

ここで多くの方が救われる分岐です。メールを Google Workspace や Microsoft 365 で運用していて、移転するのが Web サーバーだけなら、メールは1秒も止まりません。理由は単純で、メールの宛先を決めているのは MX レコードであり、Web の表示先を決めているのは A レコードだからです。この2つは独立しています。

Google Workspace の場合、MX レコードの値は smtp.google.com（優先度 1）です（Google Workspace 管理者向けヘルプ）。Microsoft 365 の場合は、管理センターの「ドメイン」から自社ドメイン専用の MX 値を確認します（Microsoft Learn：DNS レコードを作成するために必要な情報を収集する）。

したがって、この構成での正しい手順はこうなります。

1. ネームサーバーは変更しない（現在の DNS 管理先をそのまま使う）
2. A レコード（と www の CNAME）だけ新しい Web サーバーの IP へ向ける
3. MX・SPF・DKIM・DMARC の TXT レコードには一切触らない

危険なのは、移転先ホスティング会社の案内どおりにネームサーバーごと変更してしまうケースです。この瞬間に DNS の管理権が移転先へ移り、Google Workspace 向けの MX が消えて移転先の初期 MX に置き換わります。結果として、Web は無事なのにメールだけ全滅します。どうしてもネームサーバーを移す必要があるなら、移す前に既存の全レコードを控え、移転先で MX・SPF・DKIM・DMARC を先に作ってから切り替えてください。

SPF / DKIM / DMARC の再設定は、移転で最も忘れられる

実務で移転後にいちばん多い「あとから効いてくる」不具合が、送信ドメイン認証の設定漏れです。受信は直っているので一見成功に見えるのに、数日後に「送ったメールが相手の迷惑メールに入っていた」と発覚するという順番で表面化します。

総務省の令和7年版 情報通信白書によれば、JP ドメインにおける導入率は2024年9月末時点でSPF が88.4%、DMARC が32.6%です（総務省：送信ドメイン認証技術の導入状況）。SPF はほぼ当たり前になっており、移転で SPF が壊れている＝標準から外れた状態だと受け取られると考えたほうが安全です。

コマンドで現状を確認する

推測せず、必ず実際の DNS を引いて確認します。macOS / Linux なら dig、Windows なら nslookup が使えます。

• dig mx example.com +short … MX の向き先と優先度。新サーバー（または Google / Microsoft）になっているか
• dig txt example.com +short … SPF レコード。v=spf1 で始まる行に旧サーバーの記述が残っていないか
• dig txt セレクタ._domainkey.example.com +short … DKIM 公開鍵。セレクタ名は送信側の管理画面で確認する
• dig txt _dmarc.example.com +short … DMARC ポリシー。v=DMARC1 で始まる行があるか
• nslookup -type=mx example.com … Windows で MX を確認する場合

チェックする観点は3つです。SPF は、旧サーバーの include や ip4 を削り、新しい送信経路を1行にまとめる（SPF レコードはドメインに1本だけが原則で、2本あると評価されません）。DKIM は、送信サーバーが変われば鍵も変わるので、新サーバー側で発行し直した公開鍵を DNS に登録します。DMARC は、SPF か DKIM のどちらかが通っていることが前提なので、いきなり厳しいポリシーにせず p=none でレポートを受け取り、認証が通っているのを確認してから段階的に強めます。

切り替え方式の比較：どの方法を選ぶか

移転の進め方は、大きく3つに分かれます。案件の条件に合わせて選んでください。

実務での推奨は明快です。メールを止めたくないなら、そもそもメールとサーバーを分離しておく。3つめの方式は初回の手間こそ大きいものの、以後の移転はすべて1つめの「A レコードだけ変更」で済むようになります。何度もリニューアルする予定があるなら、この形に寄せておく価値があります。

移転で見落とされがちな3つの落とし穴

チェックリストどおりに進めても、次の3点はよく抜け落ちます。

1. サイトのお問い合わせフォームからのメール。フォームは Web サーバー側のプログラムから送信されるため、サーバーが変わると送信経路そのものが変わります。移転直後に届かなくなっても誰も気づかないまま数週間が過ぎる、というのが典型的な損失パターンです。移転後は必ず自分でフォームからテスト送信してください。届かない場合の原因の絞り込みは、お問い合わせフォームのメールが届かないときの原因と対処にまとめています。

2. サブドメインと外部サービスの設定。ネームサーバーごと移すと、shop. や blog. といったサブドメイン、SaaS の所有権確認 TXT、EC カートや予約システムが指定した CNAME も一緒に消えます。移す前に旧 DNS のレコードを全件エクスポートし、1行ずつ突き合わせてください。

3. ドメイン自体の有効期限。移転作業に気を取られている間にドメインの更新期限が切れると、サーバーの状態とは無関係に Web もメールも同時に止まります。これは移転事故に見えて実は別問題で、ホームページが突然表示されなくなるドメイン失効のトラブルで挙げた症状と切り分けが必要です。移転の前後で更新期限を一度確認しておくと安心です。

まとめ：順序を守れば、メールは止まらない

サーバー移転でメールが止まるのは、技術的に難しいからではなく、受け皿を作る前に切り替えたり、旧サーバーを早く手放したりするからです。押さえるべきは次の5点に尽きます。

• 止まる正体は「伝播の遅さ」ではなく新旧2台に同時に届く期間。最長72時間ほど続くことがある
• 「消えた」メールの多くは旧サーバーの受信箱にある。まずそこを開く
• 作業順序はアカウント作成 → TTL 短縮 → IMAP 同期 → DNS 切替 → 旧サーバー据え置き → 認証設定
• 旧サーバーの解約だけが後戻りできない。最低48〜72時間、可能なら1か月残す
• Google Workspace / Microsoft 365 なら、A レコードだけ変えて MX に触らないのが最も安全

移転そのものが不安な場合や、すでに止まってしまっていて何から手を付ければよいか分からない場合は、状況を教えていただければ切り分けからご相談に乗ります。Mihata ではホームページ制作にあわせて、ドメイン・サーバー・メールの移行までまとめてお引き受けしています。