サーバの契約更新が近い、制作会社を替える、いまのサーバが遅い。理由は何であれ、小さな会社でサーバを乗り換えるときにいちばん怖いのは「月曜の朝、メールが1通も届いていない」です。
この事故は、ほぼ全部が順番の間違いで起きます。技術の難しさではありません。この記事を読み終えると、何をどの順で動かせば止まらないか、切り替えた当日に dig で何を見ればよいかが分かり、最後の確認表をそのまま作業に使えます。
- この記事で出来ること
- 何をどの順で動かせば止まらないかが分かり、当日にdigで見る所、戻し方、業者に送る文面、確認表をそのまま使える
- 前提
- 新旧のサーバとドメイン登録先の管理画面に入れること（入れなければ、4節の文面で業者に頼む）
- 所要時間
- 準備は2日前から。当日の切り替え1〜2時間、並行期間2週間（私の目安）
先に結論：この順番以外は勧めません
①現状を書き出す → ②TTLを下げる → ③新しい側を先に完成させる → ④DNSを切り替える → ⑤新旧を並行で動かす → ⑥旧側を止める → ⑦ドメイン移管（要るときだけ、最後に）
私が守っている決まりは3つです。
- 同じ日に2つ以上動かさない。 サーバとメールとドメイン移管を一度にやると、止まったときに原因が3倍になります。
- 旧サーバは切り替えから2週間、解約しない。 切り戻しの保険は、旧サーバが生きていることだけです。
- 切り替えは金曜の夜ではなく、平日の午前にやる。 理由は後で書きます。
1. 動かすものは4つ。混ぜるから事故になる
| 対象 | 中身 | 関係するDNSの項目 |
|---|---|---|
| Webサーバ | サイトのファイルとデータベース | A / AAAA / CNAME |
| メール | メールボックスと送受信のサーバ | MX、SPFと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出力はこう読みます。
example.com. 3600 IN MX 10 mail.example.com.左から、名前・TTL（秒）・クラス・種類・値です。MXの値の頭の 10 は優先度で、小さいほうが先に使われます。2列目のTTLが、②で下げる対象です。
dig では「どんな名前があるか」は分かりません。サブドメイン（www、mail、予約システム用の名前など）は管理画面の一覧で拾ってください。あわせて、このドメインの名前でメールを送っているものを全部書き出します。問い合わせフォームの自動返信、請求書サービス、メール配信。移行で忘れられるのは、だいたいここです。切り替え後に「フォームの通知だけ届かない」と気づくのは数日後になります。
② TTLを下げる（前日までに300秒へ）
TTLは、DNSの答えを覚えていて（キャッシュして）よい秒数です（RFC 1035）。覚えておくのは、相手の会社やプロバイダが使っているDNSのサーバ（リゾルバ）です。TTLが86400（1日）のまま書き換えると、世界のどこかに古い答えを最大1日覚えているリゾルバが残ります。
手元の検証環境で、切り替えた後のキャッシュDNSに15秒おきに聞いた結果です。見るのは2列目の数字（TTLの残り秒）。111から4まで減る間はずっと旧い答えが返り、切れた瞬間に新しい答えへ変わります。検証ではTTLを120秒にしたので2分で済みました。86400なら、この「旧い答えの時間」が1日続きます。
dig した結果。TTLが切れるまでは旧い答えが返り、切れた瞬間にMXが消える（検証環境で再現・撮影 2026-09-20）この検証では、新側にMXをわざと写し忘れています。切り替わった後の答えからMXの行が消えているのがそれで、④で書く事故の実物です。
規格に「移行のときは何秒にせよ」という定めはありません。ここからは私の目安です。
- 切り替えるレコード（A、MX）のTTLを300秒にする。 5分なら、間違えて戻すときも5分で済みます。60秒まで下げる人もいますが、小さな会社のサイトで5分と1分の差が効く場面はまずありません。
- 下げるのは、いまのTTL以上前。 TTLが1日なら前日の同じ時刻より前に。下げた直後は、まだ古いTTLで覚えているリゾルバがいるからです。私は余裕を見て2日前に下げます。
- MXが2行あるなど、同じ名前・同じ種類のレコードはTTLをそろえます（RFC 2181 5.2節）。
- 落ち着いたら元の長さ（3600〜86400）に戻します。短いままでも動きますが、DNSへの問い合わせが増えるだけで得がありません。
TTLを下げ忘れたまま当日を迎えたら、延期してください。 「まあ大丈夫だろう」で切り替えて、半日メールが新旧に割れる、がいちばん多い失敗です。
③ 新しい側を先に完成させる
DNSを触る前に、新しい側を「あとは向きを変えるだけ」にします。
- サイトを移し、新サーバ上で表示を確かめる（多くのサーバに、切り替え前に確認するための仮のURLや、hostsファイルで確認する案内があります）
- メールアドレスを、旧側と同じ名前で新側に全部作る。 1つでも作り忘れると、切り替え後その宛先は「宛先不明」で送り主に返ります。これは再送されません。取引先に「御社のアドレス、無くなっていますよ」と言われる形で発覚します
- 新しいメールサービスが指定するSPF・DKIMの値を控える
メールの置き場所について、私の意見を書いておきます。 サーバを替えるこの機会に、メールはレンタルサーバー付属のものから、グループウェア（Google Workspace や Microsoft 365 の類）へ分けることを勧めます。理由は単純で、サーバ付属のメールを使っている限り、次にサーバを替えるときもまたメールの引っ越しが付いてくるからです。分けておけば、次回はAレコードを1行書き換えるだけで終わります。メールが数アドレスで、費用を足したくないなら付属のままでも構いません。ただしその場合は、この記事の手順を次回もう一度やることになります。
④ DNSを切り替える（平日の午前に）
| 方法 | 内容 | 私の評価 |
|---|---|---|
| レコードだけ書き換える | いまのネームサーバーのまま、AやMXの値を新側に変える | こちらを勧めます。 1行ずつ変えて1行ずつ確かめられる |
| ネームサーバーごと替える | 新しい事業者のDNSに全レコードを作ってから、NSの指定を変える | 必要なときだけ。全レコードが一度に入れ替わるので、写し忘れが即事故になる |
ネームサーバーごと替えるときの事故はほぼ1種類で、新側のDNSにMXやTXTを写し忘れることです。サーバ会社の「ネームサーバーをこちらに変えてください」という案内どおりに進めると、Web用のレコードは自動で入りますが、よそのメールサービス向けのMXは入りません。NSを変える前に、新しいネームサーバーへ直接聞いて確かめます。
dig @ns1.new-dns.example example.com MX +short@ の後ろが問い合わせ先です。①で控えた値と同じ答えが返るまで、NSは変えません。
時間帯について。金曜の夜や連休前に切り替える人が多いのですが、私は勧めません。止まっても誰も気づかず、気づいた月曜には事業者のサポートも混んでいます。平日の午前に切り替え、午後いっぱい様子を見るほうが、結果として止まっている時間が短くなります。
⑤ 新旧を並行で動かす（2週間）
切り替えた後もしばらく、古い答えを覚えているリゾルバは旧サーバへ届けます。
- 旧側のメールボックスは消さない。メールソフトに新旧両方のアカウントを入れ、どちらに届いても読めるようにしておく
- 旧側にメールが届いたら、誰から・いつ、を見る。数日たっても同じ相手から旧側へ届くなら、相手側のDNSキャッシュではなく、どこかに旧サーバ名を直接書いた設定が残っています
少しの間つながらなくてもメールが消えにくいのは、送信側のサーバが再送を続けるからです。RFC 5321は、諦めるまでの時間を少なくとも4〜5日とするよう述べています（4.5.4.1節）。ただしこれは「サーバにつながらない」場合の話で、③の「宛先が存在しない」は即座に返されます。再送を当てにしてよいのは前者だけです。
検証環境でも確かめました。MXを写し忘れ、Webサーバが25番ポートを閉じている状態で1通送ると、送信側のサーバ（Postfix）は status=deferred（保留）で待ち行列に残し、MXを直した後の再送で新しいサーバへ status=sent になりました。その間、送り主には何も返っていません。届いていないことに誰も気づかない、という意味では怖い動きですが、数日のうちに直せば失われない、という意味では救いです。
Sep 20 11:08:24 client postfix/smtp[364]: 194C540AE6: to=<info@example.jp>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.4.1, status=deferred (connect to example.jp[192.0.2.80]:25: Connection refused)
Sep 20 11:09:02 client postfix/smtp[364]: 194C540AE6: to=<info@example.jp>, relay=mail.example.jp[192.0.2.22]:25, delay=38, delays=38/0/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2EE6C42D4D)同じ番号（194C540AE6）の1通が、1行目で保留、2行目で配達済みになっています。
⑥ 旧側を止める
TTLだけを考えれば並行期間は数日で足ります。それでも私が2週間残すのは、月に1〜2回しか動かないもの（月次の請求メール、隔週の予約通知）が旧側の設定に依存していないかを、1周ぶん見たいからです。2週間ぶんのサーバ代は、保険料として安いものです。
旧側に新着もアクセスも来ないことを確かめ、旧メールボックスの中身を保存してから解約します。更新日が並行期間にかかるなら、1か月だけ延長してでも残してください。
→ 過去メールの移し方 ／ 3-2-1のバックアップの組み方
⑦ ドメイン移管は最後に、要るときだけ
移管を重ねると、①〜⑥の問題と区別がつかなくなります。サーバとメールが落ち着いて、TTLも戻してから、別の日にやります。
3. 切り戻しの備え
切り戻しは「レコードを元の値に戻す」だけです。それが5分で効くようにしておくのが準備です。
| 備え | 内容 |
|---|---|
| 旧レコードの控え | ①の書き出し。これが無いと戻す値が分からない |
| 短いTTL | ②で下げてあれば、戻すのも5分 |
| 旧サーバの契約 | 並行期間が終わるまで解約しない |
| 管理画面に入れること | 新旧の事業者とドメイン登録先の3か所に、前日までに実際にログインしておく。当日に「パスワードが分からない」「2要素認証の端末が退職者の手元」は珍しくありません |
うまくいかなかったときの戻し方
戻す順番は、事業に効く順です。
- MXを元の値に戻す。 メールが先です。サイトが10分見えなくても取引は止まりませんが、メールは止まります
- Aレコード（サイト）を元の値に戻す
- 切り替えのために書き換えたTXT（SPF）を元の値に戻す
dig @いまのネームサーバー example.com MX +shortで、①の控えと同じ値が返るのを見る- 新側に作ったメールボックスとサイトは消さない。戻している間に新側へ届いたメールが入っているからです
②でTTLを300秒に下げてあれば、5分で効きます。下げていなければ、元のTTLの時間だけ新旧に割れ続けます。その間は⑤と同じく、新旧両方のメールボックスを見てください。
ネームサーバーごと替えた場合は、戻しても即効ではありません。 上位のDNSが配るNSのTTL（.com は2日）は自分では下げられず、新側を覚えたリゾルバは切れるまで新側に聞き続けます。だから戻すときも新側のレコードは消さず、新旧どちらに聞かれても同じMXが返る状態を2日保ちます。私が「レコードだけ書き換える」を勧める理由の半分は、この戻しにくさです。
4. 業者に送る文面
DNSやサーバを制作会社・サーバ会社が管理しているなら、作業の前に次の2通を送ります。口頭で頼むと、TTLと並行期間が抜けます。【】を置き換えてください。
件名: example.com のサーバ移行に伴う事前のお願い（DNSの一覧とTTLの変更）
【会社名】【担当者名】様
お世話になっております。【自社名】の【氏名】です。
【日付】に example.com のサーバを【新しい事業者名】へ切り替える予定です。
メールを止めずに進めるため、事前に次の2点をお願いします。
1. 現在のDNSレコードの一覧（A・MX・TXT・CNAME の名前・値・TTL）をお送りください
2. 【切り替え日の2日前の日付】までに、A と MX のレコードのTTLを300秒に変更してください
切り替え当日は、こちらからお送りする値へのレコードの書き換えをお願いする予定です。
ネームサーバーの変更は行わず、レコードの書き換えだけで進めたいと考えています。件名: example.com のサーバ解約時期のご相談
【会社名】【担当者名】様
切り替えの後も、【日付＝切り替えから2週間後】までは現在のサーバとメールボックスを
残してください。切り戻しと、旧側に届くメールの確認のためです。
契約の更新日がその前に来る場合は、1か月の延長の手続きと費用をお知らせください。1通目の最後の2行が要点です。業者の標準の手順は「ネームサーバーをこちらに変えてください」であることが多いので、先にこちらの方針を伝えます。
5. 確認表
| # | 確認すること | 方法 | 済 |
|---|---|---|---|
| 1 | 全レコードと、メールを送っているサービスを控えた | 管理画面の一覧と dig の結果を保存 | □ |
| 2 | TTLを300秒に下げ、元のTTL以上の時間がたった | 変更した日時を記録。dig の2列目が300以下 | □ |
| 3 | 新側に同じメールアドレスが全部ある | 一覧を1行ずつ照合 | □ |
| 4 | 新側のDNSにMX・SPF・DKIM・DMARCがある | dig @新ネームサーバー example.com MX など | □ |
| 5 | 3か所の管理画面にログインできた | 前日までに実際に入る | □ |
| 6 | 切り替え後、外から新しい答えが返る | dig +short example.com MX を、会社の回線とスマホの回線の両方で | □ |
| 7 | 送受信のテスト | 外部のアドレスと送受信し、ヘッダーのSPF・DKIMが pass | □ |
| 8 | 旧側に2週間、新着がない | 旧メールボックスと旧サーバのアクセス記録 | □ |
| 9 | TTLを元に戻した | 管理画面 | □ |
出典（取得日: 2026-09-20）
TTLの秒数、並行期間の2週間、作業の時間帯は、規格の定めではなく筆者の実務上の目安です。
- RFC 1035 Domain Names - Implementation and Specification（TTLの定義） https://www.rfc-editor.org/rfc/rfc1035.html
- RFC 2181 Clarifications to the DNS Specification（5.2節、8節） https://www.rfc-editor.org/rfc/rfc2181.html
- RFC 5321 Simple Mail Transfer Protocol（4.5.4.1節、5.1節） https://www.rfc-editor.org/rfc/rfc5321.html