サーバ・ドメイン・メールの引っ越し全体図: 何をどの順で動かすか

小さな事業のIT・バックオフィス公開

この記事は特定の製品の使用レビューではありません。公式仕様と公的情報をもとに整理しています。 ・仕様の取得日

結論

  • 引っ越しの対象は「Webサーバ」「メール」「DNS（ネームサーバー）」「ドメインの登録先」の4つです。同じ日に全部を動かさず、1つずつ動かして確認するのが基本です。
  • 順番は ①現状の書き出し → ②TTLを下げる → ③新しい側を先に完成させる → ④DNSを切り替える → ⑤新旧を並行で動かす → ⑥旧側を止める → ⑦ドメインの移管（必要な場合だけ、最後に） です。
  • DNSの切り替えは、レコードを元の値に戻せば切り戻せます。戻せる状態を保つために、旧サーバは並行期間が終わるまで解約しません。

1. 動かすものは4つある

対象内容動かすと変わるDNSの項目
Webサーバサイトのファイルやデータベースの置き場所A / AAAA / CNAME
メールメールボックスと送受信のサーバMX、SPFのTXT、DKIMのTXT
DNS（ネームサーバー）上のレコードを答えるサーバNS（ドメインの登録先の管理画面で指定）
ドメインの登録先ドメインの契約と更新を扱う事業者変わらない（ネームサーバーの指定が同じなら、DNSの内容は同じ）

「サーバを替える」と「ドメインを移管する」は別の作業です。サーバだけ替えて、ドメインの登録先はそのままにしておくこともできます。

→ ドメイン移管でメールが止まる場面と、止めない段取り

2. 全体の順番

① 現状を書き出す

いまのDNSレコードをすべて控えます。管理画面の一覧を写すほか、dig でも確認できます（example.com は例です）。

dig +noall +answer example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +noall +answer example.com NS

メールアドレスの一覧、転送設定、サブドメイン、フォームの自動返信など「このドメインでメールを送っているサービス」も書き出します。

② TTLを先に下げる

TTLは、DNSの答えをキャッシュしてよい秒数です（RFC 1035）。TTLが86400（1日）のレコードを書き換えると、古い答えを覚えているリゾルバが最大で1日残ります。

  • 切り替える予定のレコード（A、MXなど）のTTLを、短い値に変えます。
  • 変える時期は、「いまのTTLの長さ」以上前です。TTLが1日なら、切り替えの1日以上前に下げます。下げた直後は、まだ古いTTLで覚えているリゾルバがいるためです。
  • 同じ名前・同じ種類のレコードが複数あるとき（MXが2行など）は、TTLをそろえます（RFC 2181 5.2節）。
  • 切り替えが落ち着いたら、TTLを元の長さに戻します。

③ 新しい側を先に完成させる

DNSを切り替える前に、新しい側で次を済ませます。

  • サイトのファイルとデータを移し、新サーバ上で表示を確認する
  • メールアドレスを旧側と同じ名前で新側に作る（切り替え後に届くメールの受け皿を先に用意する）
  • 新しいメールサービスが指定するSPF・DKIMの値を控える

→ SPF・DKIM・DMARCの設定の手順

④ DNSを切り替える

方法は2つあります。

方法内容注意する点
レコードだけ書き換えるいまのネームサーバーのまま、AやMXの値を新しい側に変える変える範囲が小さく、1行ずつ確認できる
ネームサーバーごと替える新しい事業者のDNSに全レコードを作ってから、NSの指定を変える新側のDNSに、①で控えたレコードがすべて入っているかを先に確かめる。MXやTXTの写し忘れがメール不達の原因になる

切り替え後にメールが届かないときの確認順は、別の記事にまとめました。

→ ネームサーバー変更後にメールが届かないときの確認順

⑤ 新旧を並行で動かす

切り替え後もしばらく、古い答えを覚えているリゾルバは旧サーバへ届けます。

  • 旧側のメールボックスは残し、並行期間中は旧側の受信も確認します。
  • メールソフトに新旧の両方のアカウントを設定しておくと、どちらに届いても読めます。
  • 旧側のメールボックスを先に消すと、そこへ届いたメールを受け取れなくなります。

送信側のメールサーバは、一時的に届けられないメールをすぐには諦めず、再送を続けます。RFC 5321は、諦めるまでの時間を少なくとも4〜5日とするよう述べています（4.5.4.1節）。短時間の切り替え作業でメールが失われにくいのはこのためです。

⑥ 旧側を止める

数日のあいだ旧側に新しいメールもアクセスも来ないことを確かめてから、旧メールボックスの中身を保存し、解約します。

→ 3-2-1のバックアップの組み方

⑦ ドメインの移管は最後に、必要なときだけ

移管を同じ時期に重ねると、①〜⑥と問題が重なって原因が追いにくくなります。サーバとメールが落ち着いてから、別の日に行います。

3. 切り戻しの備え

備え内容
旧レコードの控え①の書き出しを、切り替え前の値として保存しておく
短いTTL②で下げてあれば、戻したときも短い時間で反映される
旧サーバの契約並行期間が終わるまで解約しない。更新日が近いときは先に確認する
作業の時間帯メールや問い合わせの少ない時間に切り替える
管理画面に入れること新旧の事業者とドメイン登録先の3か所に、作業前にログインして確かめる

→ パスワード管理と2要素認証の進め方

4. 確認表

#確認すること方法済
1全レコードを控えた管理画面の一覧と dig の結果を保存□
2TTLを下げてから、元のTTL以上の時間がたった変更した日時を記録□
3新側に同じメールアドレスがある新側の管理画面で一覧を照合□
4新側のDNSにMX・SPF・DKIM・DMARCがあるdig @新ネームサーバー example.com MX など□
5切り替え後、外から新旧どちらの答えが返るかdig +short example.com MX を複数の回線で□
6送受信のテスト外部のアドレスとの間で送受信し、ヘッダーのSPF・DKIMの結果を見る□
7旧側に数日新着がない旧メールボックスと旧サーバのアクセス記録□
8TTLを元に戻した管理画面□

出典（取得日: 2026-09-20）