サーバー移転で「ドメインはそのまま使いたい」場合、作業の核心はドメイン設定（DNS）です。
ここでの判断を誤ると、切替後に「サイトが表示されない」「SSLが無効になる」「メールが届かない」といった事故が起きやすくなります。
本記事では、サーバー移転時に選ぶことになる3つの方法（DNS切替／ネームサーバー変更／ドメイン移管）の違いを整理し、
それぞれの具体的な手順と、切替前後のチェックポイントをまとめます。
※WordPressの引っ越し作業（ファイル・DB移行、プラグイン、動作確認）そのものは扱わず、あくまでドメイン設定に特化します。
全体の流れ（チェックリスト）は下記記事をご覧ください。
まず結論：DNS切替／ネームサーバー変更／ドメイン移管の違い
サーバー移転で混乱しやすいのが「ドメイン周りの作業」です。
ただ結論から言うと、やっていることは"どこを変更するか"が違うだけで、3つは別物です。
- DNS切替：DNSレコード（A/CNAME/MX/TXTなど）を書き換える
- ネームサーバー変更：DNSの管理先（権威DNS）そのものを別サービスへ切り替える
- ドメイン移管：ドメインの管理会社（レジストラ）を引っ越す（＝契約の移動）
「サイトが新サーバーに移る」ことだけが目的なら、多くのケースはDNS切替だけで完結します。
ネームサーバー変更やドメイン移管は、"管理をまとめたい／契約を移したい"といった別の目的があるときに選ぶ手段です。
| 項目 | DNS切替（レコード変更） | ネームサーバー変更 | ドメイン移管 |
|---|---|---|---|
| 何を変える？ | DNSレコード | 権威DNS（NS） | レジストラ（契約先） |
| 主な作業場所 | DNS管理画面（現行のDNS） | ドメイン管理画面（NS設定）＋新DNS側のレコード作成 | 旧/新レジストラ（Authコード等） |
| 影響範囲 | 必要なレコードだけ | DNSが管理する全レコード（移し漏れが事故原因） | 基本は契約の引っ越し（DNSは別問題） |
| 向くケース | サイト移転を最短・最小リスクで行いたい | DNS管理を新サーバー側/外部DNSに統一したい | 更新管理や費用の都合で契約先を変えたい |
| 注意点 | TTLと反映待ち、A/CNAME/MX/TXTの整合 | 旧DNSのレコードを完全再現しないと、メール等が止まる | 移管中の制約・期限、移管＝移転ではない点の誤解 |
DNS切替（レコード変更）とは
DNS切替は、いまのDNS管理画面でAレコードやCNAMEを新サーバーへ向ける作業です。
変えるのは必要なレコードだけなので、影響範囲を絞れます。サーバー移転で最も一般的で、迷ったらまずこの選択肢です。
ネームサーバー変更とは
ネームサーバー変更は、「DNSをどこで管理するか」を丸ごと切り替えます。
そのため、新しいDNS側に旧DNSのレコードをすべて再現できていないと、Webは表示されてもメールが止まる等の事故が起きます。
"管理を一本化したい"という目的がある場合に選びます。
ドメイン移管（レジストラ移転）とは
ドメイン移管は、ドメインの契約先（管理会社）を移す手続きです。
サーバー移転＝ドメイン移管が必要というわけではありません。
料金・更新管理・社内ルールなどの理由で「契約先を変えたい」場合に行い、サーバー移転とは切り分けて考えるのが安全です。
どれを選ぶべき？判断フロー（最短で迷わない）
判断のポイントは「目的がサーバー移転だけか」「DNS管理をどこに置きたいか」「契約先まで変えたいか」です。
多くのケースはDNS切替で十分です。
- 目的は「Webサイトを新サーバーへ向ける」だけ？ → DNS切替が第一候補
- DNS管理を新サーバー側（または外部DNS）に統一したい？ → ネームサーバー変更を検討
- ドメインの契約先（更新・請求）も変えたい？ → ドメイン移管（サーバー移転とは別タスク）
- メール運用（MX/TXT）が複雑・社内利用が大きい？ → 影響を絞れるDNS切替が安全寄り
迷う場合は、まずDNS切替でサイト移転を完了させ、落ち着いてから必要に応じてネームサーバー変更／ドメイン移管を進める流れが安全です。
移転でつまずく原因TOP（TTL・SSL・メール・www）
「DNSの変更自体は簡単なのに、なぜかうまくいかない」ケースは、たいてい周辺要素の見落としが原因です。
ここだけ押さえると、切替後のトラブルを大きく減らせます。
- TTLを下げていない：反映に時間がかかり、旧/新が混在して見える
- A/AAAA/CNAMEの向け先違い：wwwとルート（example.com）で設定がズレる
- SSL（https）を切替後に整えていない：証明書未設定・混在コンテンツで警告が出る
- MX/TXTの移し漏れ：メールだけ送受信できない、迷惑判定が増える
- リダイレクトの設計漏れ：http→https、www有無、旧URLの統一が崩れる
- キャッシュの罠：手元だけ直らない（ブラウザ/DNSキャッシュ）
以降の章では、これらを踏まえて「事前に控えるべきDNS」「切替の順番」「切替後の確認ポイント」を、パターン別に具体手順へ落とし込みます。
作業前の準備：現状のDNSを控える（必須チェックリスト）
DNS切替で一番多い失敗は、作業そのものではなく「変更前の状態を控えていない」ことです。
いざ切り替えた後にメールが止まったり、サブドメインだけ表示できなかったりしても、元の設定が分からなければ戻しようがありません。
まずは「いま何がどこに向いているか」を棚卸しして保存しましょう。
DNSは"正解の形"がサイトごとに違うため、ここを丁寧にやるだけで移転の成功率が上がります。
- DNSの管理画面（編集している場所）を特定する（レジストラ／サーバー会社／外部DNSなど）
- 対象ドメインとサブドメインを洗い出す（example.com、www、mail、sub など）
- 現状のDNSレコードを全件コピーして保存する（可能ならCSV/エクスポート、なければテキスト＋スクショ）
- 現状のネームサーバー（NS）も控える（どのDNSが権威かの証拠になる）
- メールや認証系（MX/TXT）の有無を確認し、移し漏れが起きない状態にする
- 切替前にTTLを下げる計画を立てる（反映待ちを短縮する）
ここで控えた内容が、そのまま「新DNSへ再現する設計図」になります。
次の小見出しでは、控えるべきレコードを種類ごとに整理します。
A/AAAA・CNAME・MX・TXT（SPF/DKIM/DMARC）を洗い出す
DNSレコードは種類が多く見えますが、サーバー移転で影響が出やすいのはWeb（表示）とメール（送受信・認証）です。
最低限、下記が揃っていれば「表示はできるのにメールだけ死ぬ」事故を防ぎやすくなります。
| 種類 | 主な役割 | 控えるポイント | 例 |
|---|---|---|---|
| A / AAAA | ドメインをIPへ向ける（Webの入口） | ルート（@）と www の向け先、複数IPの有無 | @ → 203.0.113.10 |
| CNAME | 別名を別ホスト名へ向ける | www、サブドメイン、外部サービス連携の有無 | www → example.com |
| MX | メールの配送先を指定 | 優先度（priority）と向け先、複数設定の有無 | 10 mail.example.com |
| TXT | メール認証や各種所有権確認 | SPF/DKIM/DMARC、Google/Microsoft等の確認レコード | v=spf1 ... |
| SRV | 特定サービスの接続先（主に業務系） | 使っている場合は必ず全件控える | _sip._tcp ... |
"控える"作業は、単にコピーするだけでなく、何のためのレコードかをメモしておくと後で迷いません。
特にメール系のTXTは長文になりやすいので、画面コピーだけでなくテキストで保存しておくのが安全です。
- Web系の必須：@（ルート）と www の A/AAAA または CNAME
- メールを使っている場合の必須：MX、SPF（TXT）、DKIM（TXT）、DMARC（TXT）
- 外部サービス：フォーム、予約、CDN、画像配信、計測タグ等で追加のCNAME/TXTが入っていることがある
- サブドメイン運用：shop / blog / lp / mail などがある場合は、それぞれ個別に控える
メールの移行手順そのもの（IMAP移行やクライアント設定）は別記事で詳しく扱い、ここではDNSとして必要な"配送先と認証"が揃っているかの確認に留めます。
メール移行の詳細は下記記事をご覧ください。
TTLを下げるタイミングと注意点（反映待ちを短縮）
TTLは、DNSの情報を「どれくらいの時間キャッシュしてよいか」を示す値です。
切替直前にTTLが長いままだと、利用者側の環境によって旧サーバーが見える人／新サーバーが見える人が混在しやすくなります。
反映待ちを短くしたい場合は、切替前にTTLを一時的に下げておくのが基本です。
ただし、プロバイダによっては最小値が決まっていたり、変更反映にも時間がかかるため、段取りで差が出ます。
- 切替予定の24〜48時間前に、対象レコード（@/www等）のTTLを短くする
- 切替当日は、想定通りTTLが短い状態になっているか確認してからDNS切替を行う
- 切替後、動作とメール等が安定したらTTLを元の値（例：3600〜）へ戻す
＜注意＞
- TTLを下げても「全員が即時に切り替わる」わけではない（各種キャッシュが残る）
- ネームサーバー変更の場合は、TTL以前に「新DNS側へ旧レコードを再現」できていないと事故が起きる
- DNS管理画面が複数に分散している場合、変更場所を誤ると"変えたつもり"になる
次の章では、控えたDNSをもとに「どの方法（DNS切替／ネームサーバー変更）で進めるか」を決め、具体的な切替手順へ進みます。
パターン1：DNS切替（レコードを書き換える）手順
DNS切替は、「ネームサーバー（NS）は変えず」に、いま使っているDNS管理画面でレコード（A/AAAA/CNAMEなど）だけを書き換える方法です。
影響範囲を必要最小限にできるため、サーバー移転で最も一般的で、迷ったらまずこの手順が安全です。
重要なのは、DNSを触る前に新サーバー側が"受け皿として完成している"こと。
DNS切替は「案内板を差し替える作業」なので、案内先（新サーバー）が未完成だと、切替した瞬間に表示崩れやエラーが出ます。
- 現状DNSを控える（s2で実施済み）
- 新サーバー側の準備ができているか最終確認（表示・SSL・最低限の動作）
- 切替対象レコード（@ / www / 必要なサブドメイン）を決める
- DNSレコードを書き換える（A/AAAA/CNAME）
- 反映確認（複数環境で確認）→問題なければ旧サーバーをしばらく保持
次の小見出しで「最低限触るレコード」を整理し、その後に切替の具体的な順番を解説します。
サーバー移転で最低限触るレコード（Web/メール/認証）
DNS切替で変更するのは基本的にWeb表示に関わるレコードです。
メールや認証（MX/TXT）は「移転の対象に含めるか」で扱いが変わりますが、サーバー移転だけならむやみに触らないのが安全です。
| 分類 | レコード | DNS切替での扱い | ポイント |
|---|---|---|---|
| Web（必須） | A / AAAA / CNAME | 新サーバーへ向ける | @（ルート）とwww、必要なサブドメイン（blog/shop等）を対象にする |
| メール（利用している場合） | MX | 原則変更しない | メールサーバーも移す場合のみ変更対象（本記事では深掘りしない） |
| メール認証 | TXT（SPF/DKIM/DMARC） | 原則変更しない | 移し漏れると迷惑判定や不達の原因になるため、触るなら全体設計が必要 |
| その他 | CNAME/TXT/SRV | 原則維持 | 外部サービス連携のレコードが入っていることがある（消すと機能が止まる） |
Web表示の代表例は下記です。サイト構成によって異なるため、あなたのDNS控え（s2）を優先してください。
- @（example.com）：A（IPv4）または AAAA（IPv6）で新サーバーIPへ
- www（www.example.com）：CNAMEで example.com へ向ける、またはA/AAAAで新サーバーへ
- サブドメイン（shop/blog/mail等）：使っているものだけ対象にする（不要なものは触らない）
なお、DNSサービスによってはルート（@）にCNAMEが使えない場合があります。
その場合はA/AAAAで向けるか、提供されているALIAS/ANAME相当の機能を使いますが、基本は現状の形式を踏襲するのが安全です。
切替の順番：テスト→切替→反映確認→復旧手順
DNS切替は、手順を間違えると「切替直後だけ一部ユーザーが見れない」などの混乱が起きます。
そこで"先に新サーバーをテストしてから、DNSを切り替える"流れにします。
1）切替前テスト（新サーバーが正しく表示できるか）
DNSを変える前に、新サーバー側で最低限の確認をします。
ここで問題を潰しておくと、DNS切替のリスクが一気に下がります。
- 新サーバーでサイトが表示できる（仮URLやIP直叩き、テスト用サブドメイン等）
- トップページだけでなく主要ページが表示できる（画像/CSS/JSが崩れていない）
- フォームや動的機能が最低限動く（問い合わせ、検索、ログイン等）
- 切替後に必要なリダイレクト（http→https、www有無など）の方針が決まっている
- 旧サーバーはすぐ消さず、復旧用に保持する（最低でも数日〜1週間）
2）DNSレコードを切り替える（A/AAAA/CNAMEを更新）
切替対象を決めたら、DNS管理画面でレコードを更新します。
ここでのコツは、変更するレコードを増やしすぎないことです。
- @（ルート）とwwwが対象になるケースが多い
- メール（MX/TXT）や使っていないサブドメインは触らない
- DNSの管理画面がどこか分からない場合は、控えたネームサーバー（NS）から特定する
3）反映確認（"切り替わったか"を複数視点で見る）
DNSはキャッシュの影響で、環境によって見え方がズレます。
自分のPCで見えた＝全員切替完了ではない点に注意します。
- 自分の回線だけでなく、別回線（スマホ4G/別Wi-Fiなど）でも表示を確認する
- wwwあり／なしの両方で確認する
- httpsで警告が出ないか確認する（SSL周りは後章で詳述）
- メールを使っている場合、送受信が止まっていないか最低限チェックする
4）復旧手順（戻すときは"元に戻すだけ"にする）
もし切替後に重大な不具合が出た場合は、慌ててあれこれ触るほど悪化しがちです。
事前に控えたDNSへ戻すだけに絞ると、復旧が早くなります。
- 切替対象のレコード（@/www等）を、控えておいた旧値に戻す
- 復旧したら、原因はDNS以外（新サーバー設定・SSL・アプリ側）も含めて切り分ける
- 再チャレンジは、テスト→切替の順番を崩さない
WordPressサイトの場合、DNS切替後に「表示は出るのに一部だけ崩れる」「管理画面URLやサイトURLの整合が取れていない」など、WordPress特有の調整が必要になることがあります。
手順と注意点は下記記事で紹介しています。
WordPressサーバー移行｜ドメインそのまま（URLを変えずに）移す手順と注意点
DNS切替が完了したら、次は「ネームサーバー変更」を選ぶ場合の手順と違いを整理します。
DNS切替だけで進める場合は、切替後の最終チェック（SSL・メール・リダイレクト）を後半章で行ってください。
パターン2：ネームサーバー変更（DNSの管理先を変える）手順
ネームサーバー変更は、DNSレコードを少し書き換えるのではなく、DNSの"管理先（権威DNS）"そのものを丸ごと切り替える方法です。
そのため、切替の本体は「NSを変えること」ではなく、新しいDNS側に旧DNSの設定を完全に再現することにあります。
DNS切替（レコード変更）が「案内板の行き先を一部変える」作業だとすると、ネームサーバー変更は「案内板の設置場所ごと引っ越す」作業です。
旧DNSにしかないレコードを移し漏れると、Webは見えてもメールが止まるなど、影響が広範囲に出やすい点が特徴です。
- 新しいDNS管理先（移行先）を決め、対象ドメインのゾーン（DNS設定）を作成する
- 旧DNSのレコードを全件洗い出し、移行先DNSへ同等に作成する（Web/メール/認証/サブドメイン含む）
- 移行先DNSで「回答が正しいか」を事前確認する（旧DNSと同じ結果が返る状態にする）
- ドメイン管理画面でネームサーバー（NS）を移行先DNSの値に変更する
- 伝播（反映）中は旧DNSも保持し、切替完了後にTTLを戻して安定運用へ
| 工程 | やること | 失敗しやすい点 |
|---|---|---|
| 事前準備 | 旧DNSの全レコードを控えて移行先へ再現 | MX/TXT（SPF/DKIM/DMARC）やサブドメインの移し漏れ |
| 切替 | ドメイン側でNSを移行先の値へ変更 | 変更後すぐに確認して「直ってない」と誤判定しがち（伝播がある） |
| 切替後 | Web/SSL/メール等を総合確認 | 一部ユーザーだけ旧DNS参照の期間が残り、挙動が混在する |
以降で「どんなときにネームサーバー変更が向くか」と、「移し漏れが起きやすいポイント」を整理します。
ネームサーバー変更が向くケース（管理を一本化したい等）
サーバー移転だけが目的なら、基本はDNS切替（レコード変更）が安全です。
そのうえで、次のように"DNS管理の設計自体を変えたい目的"がある場合に、ネームサーバー変更が選択肢になります。
- DNS管理を一本化したい（複数サービスに分散していて運用しづらい）
- 外部DNSの機能を使いたい（高速化、WAF/CDN連携、詳細なDNS運用、監視など）
- サーバー会社のDNSから、独立したDNS管理へ移して将来の移転を楽にしたい
- チーム運用で、権限管理や変更履歴など運用面を強化したい
- サブドメインが多く、DNS設計を整理してルール化したい
ただし、ネームサーバー変更は「DNS設定を一式作り直す」工程が入るため、準備8割です。
旧DNSのレコードを完全に再現できる見通しがない場合は、無理にNS変更せず、まずDNS切替で移転を終えるのが堅実です。
移行時の落とし穴：旧DNSにしかないレコードの消失
ネームサーバー変更で起きるトラブルの大半は、NS変更そのものではなく、移行先DNSへのレコード再現漏れです。
"サイトは見えるのにメールだけ止まった"のように、一部の機能だけが壊れる形で出やすいので、下記は重点的に確認してください。
移し漏れが多いレコード（チェックリスト）
- MX：メール配送先（優先度つき）。これが欠けるとメールが届かない
- TXT（SPF/DKIM/DMARC）：送信ドメイン認証。欠けると迷惑判定や不達の原因になる
- サブドメインのA/CNAME：shop/blog/mailなど、Web以外も含めて止まりやすい
- 外部サービス連携のCNAME/TXT：フォーム、予約、計測、CDN、所有権確認など
- CAA：証明書発行の許可設定。ある場合はSSLに影響することがある
- ワイルドカード：*.example.com のような設定（ある場合は要注意）
上記のうち、MXやSPF/DKIM/DMARCが欠けると「メールだけ送受信できない」「迷惑判定が増える」といったトラブルにつながります。
メール移行の原因と対処を先に押さえたい方は、下記記事もご覧ください。
安全に進めるためのコツ（手順の要点）
- 旧DNSのレコードは「必要なものだけ」ではなく、原則全件を移行先へ再現する
- 移行先DNS側で、Web（@/www）とメール（MX/TXT）の"回答"が正しい状態になってからNSを変える
- 切替当日は、Web表示だけでなく、メール送受信と認証まで最低限チェックする
- 旧DNSの設定はすぐ削除せず、切替後もしばらく保持してロールバックに備える
DNSSECを使っている場合の注意
もしドメイン側でDNSSECを有効にしている場合、ネームサーバー変更とあわせて追加対応が必要になることがあります。
DNSSECの扱いを誤ると、正しいDNSを設定していても名前解決自体が失敗することがあるため、分からない場合は無理に触らず、サーバー会社／DNS提供元の手順に従ってください。
ネームサーバー変更は「DNSを整備して今後の運用を楽にする」には有効ですが、移転当日にやるとリスクが上がります。
まずはDNS切替で移転を完了させ、必要があれば落ち着いてからNS変更を行う、という二段階でも問題ありません。
パターン3：ドメイン移管（レジストラ移転）の違いと手順
ドメイン移管は、サーバー移転やDNS切替とは別物で、ドメインの管理会社（レジストラ）を変更する手続きです。
「更新の請求先を変えたい」「管理画面を一本化したい」「社内ルールで指定レジストラに統一したい」など、契約・管理の都合で行います。
重要なのは、ドメイン移管をしても自動的にサーバーが移るわけではない点です。
サーバー移転（Web/メール）と混同すると、作業が増えたりリスクが上がるため、基本は「移転」と「移管」を切り分けて進めます。
| 項目 | サーバー移転（DNS切替/NS変更） | ドメイン移管（レジストラ移転） |
|---|---|---|
| 目的 | Web/メールの行き先を新環境へ | ドメインの契約先・管理先を変更 |
| 主な作業 | DNSレコード or ネームサーバーを変更 | Authコード取得、ロック解除、移管申請、承認 |
| 直接影響 | 表示/SSL/メールなど運用に影響が出やすい | 基本は契約の移動（DNS設定次第で影響が出る） |
| 注意点 | TTL・レコード整合・移し漏れ | 移管ロック、期限、移管中の制約、DNSの扱い |
次の小見出しでは「移管＝サーバー移転ではない」ことを具体的に整理し、そのうえで移管手順の全体像をまとめます。
「移管＝サーバー移転」ではない（混同しやすい点）
「ドメインを移す」という言い方が紛らわしく、サーバーを移す（Web/メールの引っ越し）と混同されがちです。
ドメイン移管で変わるのは、あくまで管理会社（レジストラ）と請求・更新の窓口です。
- サーバー移転：表示やメールの"行き先"を変える（DNSレコード/NSの変更が主役）
- ドメイン移管：ドメインの"契約先"を変える（Authコード等で手続き）
ただし、ドメイン移管のタイミングで、レジストラ側の設定が初期化されたり、移管先が自社DNSへ自動切替するケースもあります。
このときにDNSの再現が不十分だと、結果としてサイトが見えない／メールが止まるなど、サーバー移転と同じような事故が起きます。
そのため、移管をする場合は、事前に「現在のネームサーバー（NS）とDNSレコード一式」を控え、移管後に設定が変わっていないか必ず確認してください。
Authコード・ロック解除・移管中のDNS注意点
ドメイン移管の手続きはレジストラによって画面名称が違いますが、流れは概ね共通です。
手順のポイントは、「移管に必要なロック解除とAuthコード」、そして「移管中/移管後のDNSがどう扱われるか」です。
移管手順（全体像）
- 現レジストラで、対象ドメインの移管ロック（Transfer Lock）を解除する
- 現レジストラでAuthコード（EPPコード）を取得する
- WHOIS情報（管理者メール）を確認し、移管承認メールを受け取れる状態にする
- 移管先レジストラで移管申請を行い、Authコードを入力する
- 承認メール／管理画面で承認し、移管完了を待つ（完了通知を確認する）
- 移管後、ネームサーバー（NS）とDNSレコードが意図通り維持されているかを確認する
移管時にやってはいけない／注意すべきこと
- 移管直前にDNSを大きく触らない（切替作業と重ねると原因切り分けが難しくなる）
- 移管申請後に管理者メールが受け取れないと手続きが止まる（迷惑メールや転送設定も確認）
- 移管先レジストラが自社DNSへ自動切替する場合、旧DNSのレコードを移管先に再現してから進める
- 移管後にNSが維持されていても、念のためWeb/メールの動作確認を行う
DNSの扱いで失敗しないための判断
ドメイン移管は「契約の引っ越し」なので、最も安全なのは移管中はDNS構成を変えないことです。
サーバー移転も同時にやりたい場合は、下記のように分けると事故が減ります。
- 先にサーバー移転（DNS切替）を完了させて安定運用にする
- 落ち着いてからドメイン移管を実施する（DNS構成は維持したまま）
- 移管後に、必要があればネームサーバー変更でDNS管理を整理する
次の章では、切替後に必ず行う「表示・SSL・メール・リダイレクト」の最終チェックを整理します。
特にドメイン移管を絡める場合は、移管完了後にも同じチェックを行い、想定外のDNS変更が起きていないか確認してください。
切替後の確認：表示・SSL・メール・リダイレクトの最終チェック
DNS切替／ネームサーバー変更が終わったら、最後に「本当に運用に戻せる状態か」を確認します。
切替直後はキャッシュや伝播（DNSの反映）で挙動が混在しやすいので、Web表示だけでなくSSL・メール・リダイレクトまでまとめてチェックするのが安全です。
ここでのポイントは、"自分のPCで見える"だけで完了にしないこと。
可能なら別回線（スマホ回線、別Wi-Fi）でも確認し、「外部ユーザー視点」で問題がないかを見ます。
| カテゴリ | 最低限の合格ライン | よくあるNG |
|---|---|---|
| 表示 | 主要ページが崩れず表示、フォーム等も最低限動く | 画像/CSSが旧ドメイン参照で崩れる、管理画面だけ不具合 |
| SSL | httpsで警告なし、http→httpsが一貫して301 | 証明書未設定、混在コンテンツ、リダイレクトループ |
| メール | 送受信OK、MX/TXTが残っている | MXやSPF/DKIM/DMARCの移し漏れで不達/迷惑判定 |
| リダイレクト | www有無・末尾スラッシュ等が統一、重複URLが発生しない | wwwと非wwwが混在、httpが生き残る、302になっている |
- 別回線でもトップ＋主要ページを確認（表示・速度・崩れ）
- http/https、wwwあり/なしを一通り叩いて、最終URLが統一されるか確認
- SSL警告が出ないか、フォーム送信やログイン等の動作も最低限確認
- メールを使っている場合は、送受信と迷惑判定（到達）を簡易チェック
次の小見出しでは、まずSSL（https）と関連トラブルを重点的に確認します。
https化（SSL）と混在コンテンツ、証明書の再発行
切替後のトラブルで多いのがSSL周りです。
DNSが正しくても、証明書が未設定だったり、ページ内にhttp画像が混ざっていると、警告表示や一部機能のブロックが起きます。
まず確認すること（ブラウザでOK）
- httpsで開いたときに、鍵マークが正常（警告なし）
- httpで開いた場合、httpsへ301リダイレクトされる
- wwwあり/なしの両方で、最終的に正規のURLに統一される
- 主要ページで画像・CSS・JSが欠けない（表示崩れがない）
よくある原因と対処の方向性
| 症状 | よくある原因 | 対処の方向性 |
|---|---|---|
| 証明書エラー | 新サーバーで証明書未発行／別ドメインの証明書 | 新サーバー側で証明書を発行・適用（www有無も含める） |
| 混在コンテンツ警告 | 画像やスクリプトがhttp参照 | URLをhttpsへ統一（CMS設定・テーマ・DB内URLの見直し） |
| リダイレクトループ | サーバー側とアプリ側で二重にhttps化 | どちらかに寄せて一本化（片方の強制httpsを解除） |
| 特定ページだけ崩れる | CDN/キャッシュ/外部読み込み先が旧設定 | キャッシュ削除、外部連携の設定確認（CNAME等） |
確認のコツ（混在・強制https・正規URL）
SSLは「証明書を入れたら終わり」ではなく、URLの統一とセットです。
http/https、www有無でURLが複数生きると、SEO的にも重複になりやすいので、次の章のリダイレクトと合わせて必ず整えます。
メール送受信の確認（MX/TXTの反映・迷惑判定）
サーバー移転後に「サイトは問題ないのに、メールだけ止まった」というケースは珍しくありません。
原因の多くは、MXやTXT（SPF/DKIM/DMARC）の移し漏れ、またはネームサーバー変更後のDNS再現不足です。
本記事はメール移行手順そのもの（IMAP移行など）ではなく、切替後にDNSとして最低限確認すべきポイントを整理します。
最低限の確認（"届く/送れる"を先に見る）
- 外部から自社宛にテストメールを送って受信できる
- 自社から外部（Gmail等）へ送って届く（迷惑メールに入らないかも確認）
- 社内で使っているメールソフト（PC/スマホ）でも送受信できる
DNS側で確認する代表項目（移し漏れ防止）
- MX：メール配送先（優先度が複数ある場合も含めて維持）
- SPF（TXT）：送信元の正当性（移し漏れると迷惑判定が増える）
- DKIM（TXT）：署名鍵（プロバイダ提供のセレクタ付きTXTが多い）
- DMARC（TXT）：ポリシー（p=none/quarantine/rejectなど）
よくある落とし穴
- ネームサーバー変更後に、Web表示のA/CNAMEだけ作って満足し、MX/TXTを入れ忘れる
- TXTの値が長く、画面コピーだけで再現できていない（途中で欠ける）
- 反映待ち（伝播）中に「直っていない」と判断して、別の設定を触って泥沼化する
メールが止まったときは、まず「MXが残っているか」「SPF/DKIM/DMARCが欠けていないか」を確認し、DNSの再現漏れを疑うのが最短です。
次の章では、URL統一の要となるリダイレクト（http→https、www有無、重複URL防止）のチェックを整理します。
全体の手順（チェックリスト）は下記記事を参考にしてください。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
作業が不安なら代行/相談を紹介した下記記事をご覧ください。
よくあるトラブル：反映しない／一部だけ古い／メールだけ死ぬ
DNS切替やネームサーバー変更の直後は、「設定は正しいはずなのに、なぜか挙動がおかしい」という状態になりがちです。
これは多くの場合、DNS伝播（キャッシュ）と、移し漏れ、SSL/リダイレクトの二重設定が原因です。
トラブル時に大切なのは、焦って設定を何度も変えないこと。
まずは「何が起きているか」を切り分け、戻すなら事前に控えたDNSに戻すだけに絞ると復旧が早くなります。
- 反映しない：DNSがまだ切り替わっていない（キャッシュ・TTL・参照先の違い）
- 一部だけ古い：ルートとwww、サブドメイン、IPv4/IPv6で設定がズレている
- メールだけ死ぬ：MX/TXT（SPF/DKIM/DMARC）の移し漏れ、NS変更後の再現不足
以下で、原因を最短で切り分けるための見方と、戻し方（ロールバック）を整理します。
DNSの反映時間（伝播）と確認のコツ
DNSは変更するとすぐ全員が切り替わるわけではなく、各所にキャッシュが残ります。
そのため「自分の環境では直った」「別の環境では古いまま」という混在が、切替直後に起きやすくなります。
まず確認すべき代表パターン
- 時間の問題：TTLが長い、または切替前にTTLを下げていない
- 参照先の違い：見る人のDNSリゾルバ（社内DNS/プロバイダ）が違う
- 設定のズレ：@だけ変えてwwwが古い、Aは変えたがAAAAが残っている等
- キャッシュ：ブラウザ/OS/DNSリゾルバのキャッシュで古い結果が残る
「一部だけ古い」症状で疑うポイント
切替後に古い表示が残る場合、まずルート（@）とwwwの両方を見直します。
次に、IPv6（AAAA）が残っていないか、サブドメインが旧サーバーを向いたままになっていないかを確認します。
- ルート（example.com）とwww（www.example.com）が同じ行き先になっているか
- A（IPv4）とAAAA（IPv6）が混在していないか（片方だけ旧サーバーだと環境で差が出る）
- サブドメイン（shop/blog/mail等）で旧サーバーが残っていないか
- リダイレクトの最終到達先が統一されているか（www有無・https・末尾スラッシュ）
メールだけ死ぬ時の最短チェック
Webが問題ないのにメールだけ止まる場合は、まずDNSでMXとTXTを疑います。
特にネームサーバー変更をした場合、Web用のA/CNAMEは作っても、MX/TXTを移し忘れる事故が多いです。
- MXが存在し、意図したメールサーバーを指しているか（優先度も含む）
- SPF/DKIM/DMARCが欠けていないか（欠けると迷惑判定や不達の原因）
- 旧DNSにだけ存在したTXT/CNAME（外部サービス連携）が消えていないか
この段階で「設定が合っているのにおかしい」場合は、伝播中の混在の可能性が高いので、慌てて再変更せず、確認する回線を変えて状況を見ます。
戻し方（ロールバック）と、最悪を避ける運用
大きな不具合が出た場合、最短で被害を止めるにはロールバック（元に戻す）です。
ここでやってはいけないのは、原因が分からないまま設定を何度も触ること。反映待ちの混在に追い打ちをかけ、さらに状況が読めなくなります。
ロールバックの基本方針
- DNS切替（レコード変更）：変更したレコードだけを、控えておいた旧値へ戻す
- ネームサーバー変更：NSを旧値へ戻す（旧DNS側の設定を保持している前提）
DNS切替で戻す手順（最短）
- 変更対象（@/www/対象サブドメイン）のレコードを特定する
- 事前に控えた旧値にそのまま戻す（余計な削除・追加はしない）
- 表示とメールの最低限を確認し、復旧を優先する
- 原因の調査は復旧後に行う（新サーバー側の設定、SSL、アプリ設定を切り分ける）
ネームサーバー変更で戻す手順（最短）
- ドメイン管理画面で、NSを旧ネームサーバーへ戻す
- 旧DNSのレコードが当時のまま残っていることを前提に復旧を確認する
- 復旧後、移行先DNS側で「旧DNSを完全再現できているか」を再点検する
最悪を避ける運用（切替前にやっておくと強い）
- 旧サーバー／旧DNS設定はすぐ消さず、数日〜1週間は保持する
- 切替前にDNSを控える（スクショ＋テキスト）ことで「戻せる」状態にする
- 切替はアクセスが少ない時間帯に実施し、直後に確認の時間を確保する
- 切替直後は「何度も変更」せず、確認は回線を変えて行う
ここまでのチェックと切り分けができれば、DNS周りのトラブルはほぼ対処できます。
作業が不安なら代行/相談を紹介した下記記事をご覧ください。
サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応
最後に、この記事の結論として「迷ったらどう進めるか」をまとめます。
まとめ：迷ったら「DNS切替」を起点に考える（例外だけ拾う）
サーバー移転で混乱しやすいのは、DNS周りに「DNS切替」「ネームサーバー変更」「ドメイン移管」という似た言葉が並ぶからです。
ただ、目的が「サイトを新サーバーに向ける」ことなら、基本方針はシンプルで、まずDNS切替（レコード変更）を起点に考えるのが安全です。
DNS切替は、影響範囲を必要最小限にでき、戻すのも簡単です。
一方で、ネームサーバー変更やドメイン移管は、"運用や契約を整理したい"という別目的があるときに、例外として拾う選択肢です。
結論：3パターンの使い分け
- DNS切替（レコード変更）：サーバー移転の第一候補。迷ったらこれ。
- ネームサーバー変更：DNS管理を一本化したい／外部DNSの機能を使いたい等の目的がある場合のみ。
- ドメイン移管：契約先（更新・請求・管理画面）を変えたい場合のみ。サーバー移転とは別タスク。
安全に進めるための最重要ポイント
どの方法でも、成否を分けるのは「切替前に現状DNSを控えること」と、「切替後に表示・SSL・メール・リダイレクトまで確認すること」です。
これだけ守れば、DNS周りの事故は大きく減らせます。
- 現状DNSを全件控える（スクショ＋テキスト保存）
- 切替対象（@/www/必要なサブドメイン）だけを最小限変更する
- 切替後は別回線でも確認し、SSL・メール・リダイレクトまでチェックする
- 旧サーバー／旧DNS設定はすぐ消さず、ロールバックできる状態を保持する
「サイト移転を最短・最小リスクで完了させたい」なら、まずDNS切替で移転を終え、必要に応じて後からネームサーバー変更やドメイン移管で運用整理を行う流れが堅実です。
次は、具体的な環境（現行サーバー／移転先／メール運用／www有無／SSL方式）に合わせて、チェックリストをあなたのケース用に最適化していきましょう。
サーバー移転の全体の流れは下記記事で解説しています。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
サーバー移転時のメール移行方法は下記記事で解説しています。
サーバー移転のメール移行｜送受信できない原因と設定手順（IMAP/SMTP）
ドメインそのままでWordPressのサーバー移行方法は下記記事で解説しています。
WordPressサーバー移行｜ドメインそのまま（URLを変えずに）移す手順と注意点
作業が不安なら代行/相談を紹介した下記記事をご覧ください。
（※本ページはプロモーションが含まれています。）
- 広告
- 広告
