サーバー移転の実務手順｜メールを止めないための段取り

2026.08.282026.09.08

サーバー移転で本当に怖いのは、サイトが表示されないことではありません。メールが止まることです。

サイトが数時間見えなくても、多くの場合、事業への影響は限定的です。しかしメールは違います。受信できないだけでなく、送信元にエラーも返らず、静かに消えることがあります。取引先からの発注メールが届かなかったと後で分かる——これが最悪のシナリオです。

この記事では、メールを止めないことを最優先に、サーバー移転の実務手順を解説します。

この記事で分かること

移転前に必ず記録しておくべき情報
移転の8ステップと、それぞれの所要時間
メールを止めないためのDNS切り替えの段取り
切り替え後に確認すべきこと

なぜメールが止まるのか

ドメイン（example.co.jp）は、DNSという仕組みで「Webはこのサーバー、メールはこのサーバー」と行き先を指定しています。

レコード	役割
Aレコード	Webサイトの置き場所（IPアドレス）
MXレコード	メールの配送先
TXTレコード（SPF等）	送信元の正当性を示す設定
CNAMEレコード	別名の指定（wwwなど）

多くのレンタルサーバーは、WebとメールをセットにしたDNS設定を自動で書き込みます。サーバーを移すとき、新サーバー側の初期設定でMXレコードも上書きされる——これが事故の典型です。

WebサイトはA社サーバー、メールはGoogle Workspaceという構成だった場合、Web移転に伴ってMXが新サーバーに向いてしまえば、その瞬間からメールが届かなくなります。

移転前に必ず記録すること

作業を始める前に、現状をすべて記録してください。これを飛ばした移転は、必ずどこかで詰まります。

項目	確認方法
現在のDNSレコード一式	DNS管理画面のスクリーンショット。A・MX・TXT・CNAMEをすべて
ドメインの登録事業者と有効期限	Whois検索
DNSの管理場所	`nslookup -type=NS ドメイン`
現在のMXレコード	`nslookup -type=MX ドメイン`
メールアカウントの一覧	サーバー管理画面。転送設定・自動応答も忘れずに
PHPバージョン	サーバー管理画面
データベースの情報	DB名、ユーザー名、接続先ホスト
SSL証明書の種類	無料SSLか有料か。有料なら再発行の要否
cronの設定	定期実行しているスクリプトがないか
サイトの全ページ一覧	移転後の表示確認に使う

管理情報が分からない場合は、まずそこから調べる必要があります。手順はドメイン・サーバーの管理情報が分からないときの調査手順にまとめています。

移転の8ステップ

STEP	作業	所要
1	現状の記録（前章）	1〜2時間
2	新サーバーの契約と初期設定	1時間
3	DNSのTTLを短くする	作業5分＋反映待ち1日
4	サイトのデータとデータベースを新サーバーへ移す	2〜4時間
5	新サーバーで表示確認（hostsファイル等で先行確認）	1〜2時間
6	メールアカウントを新サーバーに作成（移す場合）	1〜2時間
7	DNS切り替え	作業10分＋反映1〜24時間
8	切り替え後の確認、旧サーバー解約	1週間以上あけて

全体で1〜2週間を見てください。作業自体は1日で終わりますが、TTLの反映待ちと、切り替え後の様子見の期間が必要です。

STEP3｜TTLを短くしておく

見落とされやすい、しかし重要な工程です。

TTL（Time To Live）は、DNS情報がキャッシュされる時間です。通常は3600秒（1時間）や86400秒（24時間）に設定されています。これを切り替えの前日までに300秒（5分）に下げておくと、切り替え時の反映が速くなり、問題が起きたときの切り戻しも短時間で済みます。

注意点として、TTLの変更自体が、元のTTLの時間だけかかって浸透します。元が24時間なら、TTLを下げる作業は切り替えの2日前には済ませてください。

切り替えが無事に終わったら、TTLは元の値に戻しておきます。

STEP5｜切り替え前に新サーバーで表示確認する

DNSを切り替えてから「表示がおかしい」と気づくのでは遅すぎます。切り替え前に、新サーバー上のサイトを確認する方法があります。

hostsファイルを書き換える：自分のPCだけ、新サーバーを見に行くようにする
サーバー会社が提供する確認用URLを使う
一時的なサブドメインを切って確認する

この段階で、全ページの表示、フォームの送信、ログイン、画像の表示を確認しておきます。WordPressの場合、PHPバージョンの違いでプラグインが動かなくなることがあるため、特に入念に確認してください。

メールを止めない段取り

ここが本題です。パターン別に整理します。

パターンA｜メールは移さない（Webだけ移転）

メールがGoogle WorkspaceやMicrosoft 365、あるいは別サーバーにある場合です。最も安全なパターンですが、油断は禁物です。

やることは1つ。DNS切り替え時に、Aレコードだけを変更し、MXレコードとSPFレコードは現状のまま維持する。

新サーバーの「ドメイン追加」機能を使うと、MXレコードが自動で書き換わることがあります。設定後に必ず nslookup -type=MX で確認してください。

パターンB｜メールも一緒に移す

難易度が上がります。手順は次のとおりです。

新サーバーに、同じメールアドレスをすべて作成する（DNS切り替え前に）
転送設定・自動応答・迷惑メール設定も再現する
DNSを切り替える
切り替え後しばらくは、新旧両方のサーバーでメールを受信し続ける
過去メールを新サーバーへ移行する（必要なら）
1週間以上経過し、旧サーバーへの着信が止まったことを確認してから解約

4が重要です。DNSの反映には時間差があるため、切り替え直後は、送信者によって新旧どちらかのサーバーに届きます。旧サーバーを即座に解約すると、その間のメールが失われます。

実務では、各PC・スマートフォンのメールソフトに、新旧両方のアカウントを一時的に設定しておくのが確実です。

過去メールの移行

POP方式で各PCにダウンロード済みなら、サーバー上のメールを移す必要はありません。IMAP方式の場合は、サーバー上にメールが保管されているため移行が必要です。

移行にはメールソフトの機能や専用ツールを使いますが、件数が多いと数時間〜数日かかります。どちらの方式で運用しているかを、移転計画の段階で確認してください。

切り替え後に確認すること

MXレコードが意図どおりか（nslookup -type=MX ドメイン）
外部アドレスから自社宛にメールを送り、届くか
自社から外部へ送り、迷惑メールに入らないか（SPFの設定漏れで起きます）
全ページの表示（特に画像とCSS）
お問い合わせフォームからの送信と受信
SSLが有効か（鍵マークが出るか）
httpからhttpsへのリダイレクト
wwwあり／なしの両方でアクセスできるか
WordPressの管理画面にログインできるか
cronで動かしていた処理が継続しているか

3番目のSPF設定漏れは、非常によくある見落としです。メールは届くのに、自社からの送信が相手の迷惑メールフォルダに入る——これは数週間気づかないことがあります。

よくある失敗

MXレコードを記録せずに作業した：元に戻せなくなります。最初に必ず控える
旧サーバーをすぐ解約した：切り戻しができず、移行期間中のメールも失います
TTLを下げずに切り替えた：問題が起きても、反映に24時間かかります
金曜の夕方に作業した：問題発覚が週明けになります。火曜〜木曜の午前中が定石
PHPバージョンの違いを確認していない：プラグインやテーマが動かなくなります
メールの転送設定を再現し忘れた：info宛を個人アドレスへ転送していた、など

費用と依頼先

作業範囲	費用の目安
Webのみ移転（小規模サイト）	3万〜10万円
Web＋メール移転	10万〜30万円
WordPress＋PHPバージョンアップ対応込み	15万〜40万円
大規模サイト・システム連携あり	要見積もり

依頼する際は、「メールも移すのか」「移転後の不具合対応はどこまで含まれるか」を必ず確認してください。ここが範囲外になっている見積もりが少なくありません。

あわせて、この機会にサーバー・ドメインの契約名義を自社に整えることをおすすめします。理由はサーバー・ドメインをお客様名義で契約すべき理由をご覧ください。