DNSレコードを変更する前に残す確認メモ
サイト移転や外部サービス接続では、DNSの編集が必要になることがあります。値を入れる前に、今の設定と変更する範囲を記録し、Webとメールを別々に確認する準備をしましょう。
サイト移転や外部サービス接続では、DNSの編集が必要になることがあります。値を入れる前に、今の設定と変更する範囲を記録し、Webとメールを別々に確認する準備をしましょう。
反映を待つ時間と、旧環境を残す期間を先に決める。
「ドメインをつなぐ」という依頼だけでは作業範囲が分かりません。ホームページの行き先を変えるのか、メールサービスを変えるのか、ネームサーバーの管理先を変えるのかを先に区別します。サイトを移転するからといって、メールの設定まで変える必要があるわけではありません。
ドメインの購入先と、現在有効なDNSを管理しているサービスが違う場合もあります。編集するパネルが現在の管理先か分からない場合は、レコードを変更せず管理担当へ確認してください。この記事は変更前の準備用です。具体的な値は、接続するサービスがあなたのドメイン向けに示した設定を使います。
AはIPv4アドレス、AAAAはIPv6アドレス、CNAMEは別のホスト名、MXはメールの配送先、TXTは認証などの情報を扱います。これは役割を見分けるための概要です。値の書式や共存できる種類は、利用中のDNSサービスの公式説明で確認してください。
用途が分からないTXTやMXを「古そうだから」と消すのは避けます。Webサイトと別の担当者がメール、所有権確認、業務ツールに使っている可能性があります。用途不明は削除候補ではなく、担当者へ確認する項目として残します。
XServerも、誤ったDNS設定はWeb表示やメール受信に影響する可能性があると案内しています。参考: XServer公式・DNSレコードの編集。確認日: 2026年9月10日。画面の初期値をそのまま別契約へコピーするのではなく、自分の契約情報と照合します。
DNSを変更するときは、作業の前に今のレコードを画面ごと保存しておきます。とくにメールのMXレコードやSPFは、Webの移転のついでに消してしまうとメールが届かなくなるので、Webとメールの設定を分けて確認するようにしていました。
運営者の実務経験にもとづくメモです。すべての場合に当てはまるとは限りません。
サーバーの乗り換えとDNS管理先の変更は、それぞれ判断が必要です。作業前に「ドメインの契約先」「DNSレコードの管理先」「Webサイトの置き場所」「メールの利用先」を書き出し、今回どこを変えるかを決めてください。今のDNS管理を続けられ、移転先が必要なレコードの指定に対応していれば、Webの接続先だけを変える構成も選べます。既存契約の解約でDNSサービスも終わる場合は、DNSをどこに残すかも決めます。ネームサーバーの役割はCloudflare公式のネームサーバー解説で確認できます(2026年9月12日確認)。
スマホでは表を横にスクロールできます。
| 予定 | 検討する操作 | 先に確認すること |
|---|---|---|
| Webだけ新サーバーへ | 既存DNSで必要なレコードを変更 | 移転先の指定・SSL・メールへの影響 |
| DNS管理も移す | 新DNSへ設定を用意して委任先を変更 | 全用途のレコードとDNSSECの扱い |
| ドメイン契約先だけ移す | 移管条件と既存DNSの継続可否を確認 | 契約の変更と公開先の変更を混同しない |
| メールも同時に移す | メールの移行計画を別途用意 | 過去メール・MX・送信認証・切替時間 |
Aレコードだけ書き換えても、IPv6用のAAAAが旧環境を向いたままだと、接続条件によって古いサイトへ届くことがあります。メールはMXに加えてSPF・DKIM・DMARCなどの送信認証も関係するため、Cloudflare公式のメール用レコード解説を参考にし、実際の値は利用中のメールサービスで確認します。DNSSECを使っている場合は、ネームサーバーを変える前に、契約先のDSレコードと新しいDNS側の対応を確かめてください。
切り替わり方はキャッシュなどで差が出るため、TTLの時間だけで完了とは判断できません。旧環境を残す期間を計画に入れ、投稿や注文を受け付けるサイトでは、切替中に旧側へ入ったデータの扱いも先に決めておきます。
下表を埋めてから作業を始めます。スクリーンショットだけでは長い値が途中で切れることがあるため、元の値を正確に確認できる保存方法も用意します。公開記事や誰でも見られる共有フォルダへ貼る必要はありません。
スマホでは表を横にスクロールできます。
| 項目 | 記入する内容 |
|---|---|
| 対象 | ドメインとホスト名。wwwとルートを区別 |
| 現在値 | 種別、内容、TTL、必要な場合は優先度 |
| 変更値 | 接続先の公式案内で確認した値 |
| 変更理由 | Web移転、メール変更、所有権確認など |
| 残す設定 | 今回変更しないメール・別サービスの項目 |
| 作業記録 | 担当者、作業日時、連絡先、確認予定 |
| 戻す判断 | どの症状で誰が元の設定へ戻すか |
たとえば「Webだけ移転、メールは現状維持」という例の作業なら、Webの接続先と維持するメールサービスを、別々の行に書きます。「すべて新しいサーバーへ変更」と一行で済ませないことがポイントです。
ホームページが見えたことは、メールも正常である証拠にはなりません。逆に、別の端末で古い表示が見えても、すぐに値を次々と変更せず、設定内容と確認条件を照合します。変更と確認を短時間に何度も繰り返すと、どの設定が原因なのか追いにくくなります。
誤った値を保存したことが明らかな場合は、事前に決めた復旧手順に従います。ただし、元へ戻した操作だけで全利用者が直ちに元の状態へ戻ると考えず、その後の表示・メール確認も行います。元の値を記録していない場合は推測で埋めず、管理担当や契約先へ確認してください。
相談時は、ドメイン、変更日時、変更した種類、発生している症状、正常な端末があるかを整理します。ログインパスワードや秘密鍵をメール本文に添える必要はありません。DNSの設定変更とドメイン契約の更新は別の作業なので、期限の問題が疑われる場合はドメイン更新の確認表も切り分けて確認します。
DNSの管理先やメールへの影響が分からない場合は、値の変更を進める前に作業範囲を相談できます。「移転をお願いしたい」だけでなく、今の構成と希望する変更を分けてまとめましょう。
分からない管理先は「未確認」で構いません。パスワード・認証コードや管理画面全体の画像は最初の相談に含めず、必要な権限の渡し方は作業範囲を決めてから確認します。
当サイトでも、現状を伺って対応できる範囲を確認します。料金目安と対応範囲をご確認ください。原因や作業範囲によってお見積もりは異なり、相談の送信だけで契約は確定しません。
公開日: 2026-09-10
最終更新日: 2026-10-13
追記履歴