企業サイトのリニューアル、サーバ老朽化、運用コストの見直しなどをきっかけに、 WEBサーバやメールサーバの移管を検討する企業は少なくありません。
ただし、サーバ移管は単にデータを移すだけの作業ではありません。 DNS設定やメール設定を誤ると、ホームページが表示されない、メールが届かない、 フォーム通知が受信できないといったトラブルにつながります。
特に混同されやすいのが、 「ドメインはそのままでサーバだけ移行するケース」と、 「ドメイン管理会社ごと移管するケース」です。 この記事では、WEBサーバ・メールサーバ・DNS・ドメインの役割を整理したうえで、 代表的な2つの移管パターンと失敗しやすいポイントを解説します。
サーバー移管では、安全性を優先するか、管理のしやすさを優先するかで適した方法が変わります。
このロジックツリーは、DNS設定の自由度や管理をまとめたいかどうかをもとに、移管方法を整理するためのものです。
条件に応じて、ドメインは残してサーバーだけを移管する方法と、ドメイン管理会社ごと移管する方法を判断できます。
移管を安全に進めるには、 WEBサーバ、メールサーバ、DNS、ドメインを分けて考えることが重要です。 これらは同じ会社でまとめて契約している場合もありますが、 それぞれ役割は異なります。
| 項目 | 役割 |
|---|---|
| WEBサーバ | ホームページのデータを置き、サイトを表示するサーバ |
| メールサーバ | メールの送受信やメールボックスを管理するサーバ |
| DNS | ドメインとWEBサーバ・メールサーバを結び付ける仕組み |
| ドメイン | 「example.com」などのインターネット上の住所 |
例えば、ホームページを別のサーバへ移す場合はAレコードやCNAME、 メールを別のサービスへ移す場合はMXレコードやTXTレコードの変更が関係します。 そのため、サーバ移管ではDNS設定の確認が大きなポイントになります。
DNSの基本やAレコード、MXレコード、TXTレコードの考え方については、 DNSの役割とドメイン設定 でも詳しく整理しています。
WEBサーバ・メールサーバ・DNSの移管では、 最初に「ドメイン管理会社を変えるのか、変えないのか」を整理します。 ここを混同すると、作業範囲やリスクを見誤りやすくなります。
| パターン | 主な作業 | 特徴 |
|---|---|---|
| ドメインは残す | DNS設定を変更し、WEBサーバやメールサーバの接続先を変える | 作業範囲を限定しやすく、一般的な移管方法 |
| ドメインも移管する | ドメイン管理会社、ネームサーバ、DNS設定をまとめて見直す | 管理を一本化しやすい一方で、確認項目が増える |
もっとも多いのは、ドメイン管理会社はそのままにして、 WEBサーバやメールサーバだけを移行するパターンです。 例えば、ドメイン管理はA社、WEBサーバはB社、メールサーバはC社というように、 役割を分けて利用する構成です。
この場合、ドメイン契約そのものには大きく触れず、 DNS設定を変更して新しいサーバへ接続します。 ドメイン移管ロックや認証コード取得などの手続きが発生しないため、 まず安全にWEBサイトだけを移したい場合に向いています。
| 項目 | 対応 |
|---|---|
| ドメイン管理 | 変更しない |
| DNS設定 | 新サーバやメールサービスに合わせて変更する |
| WEBサーバ | 新サーバへ移行する |
| メール | 現状維持または必要に応じて移行する |
WEBサーバ、メールサーバ、DNSは必ず同じ会社で管理する必要はありません。 WEBサイトはレンタルサーバ、メールはMicrosoft 365やGoogle Workspace、 DNSは外部DNSサービスという構成も可能です。
メールサーバの基本や認証設定については、 メールサーバの構築方法 も参考になります。
もう一つは、ドメイン管理会社も変更するパターンです。 ドメイン移管とは、ドメインの管理会社を変更することで、 レジストラ移管とも呼ばれます。 WEBサーバを変えることと、ドメイン管理会社を変えることは同じではありません。
ドメインごと移管する場合は、 ドメイン管理会社、ネームサーバ、DNS管理先、サーバ契約などをまとめて整理できます。 契約や管理画面を一本化しやすい一方で、DNS設定の引き継ぎが不十分だと、 WEBサイトやメールに影響が出る可能性があります。
| 項目 | 対応 |
|---|---|
| ドメイン管理 | 新しい管理会社へ移管する |
| ネームサーバ | 変更する場合がある |
| DNS設定 | 現在のレコードを確認し、新しい管理先へ引き継ぐ |
| WEB・メール | 移管内容に応じて接続先を変更する |
複数の会社に契約が分散している場合は、 ドメインやサーバ、SSL、DNSを同じ会社や同じ管理画面で管理することで、 更新確認や設定変更の手間を減らせることがあります。 ただし、安さだけで移管先を選ぶと、サポート品質やDNS管理の自由度で困ることもあります。
ドメイン移管では、 認証コード（AuthCode・オースコード）が必要になる場合があります。 これは不正なドメイン移管を防ぐための確認コードで、 現在のドメイン管理会社から取得します。
ドメインによっては、 移管ロック解除が必要なケースや、 認証コードに有効期限があるケースもあります。 管理会社によって取得方法が異なるため、 事前確認が重要です。
どちらのパターンでも、トラブルの多くはDNS設定、メール設定、切替タイミングで発生します。 特に業務でメールを利用している企業では、WEBサイト以上に慎重な確認が必要です。
DNSには、Aレコード、MXレコード、CNAME、TXTレコードなど複数の設定があります。 WEBサイトの表示にはAレコードやCNAME、 メールにはMXレコードやTXTレコードが関係します。
設定を誤ると、ホームページが表示されない、メールが送受信できない、 メール認証が失敗して迷惑メール扱いされるといった障害につながります。 移管前には、現在のDNSレコードを必ず控えておきましょう。
メールを利用している場合は、MXレコードだけでなく、 SPF、DKIM、DMARCなどの認証設定も確認が必要です。 これらが不足すると、メールが届かない、なりすまし判定される、 迷惑メールに振り分けられるといった問題につながります。
Outlook、Gmail、Microsoft 365、Google Workspaceなどを利用している場合も、 メールサーバ本体だけでなくDNS設定が関係します。 既存メールの移行、アカウント設定、受信確認、送信テストまで含めて確認しましょう。
DNS変更後は、反映まで数時間から72時間程度かかる場合があります。 この期間は、閲覧者や利用環境によって、旧サーバと新サーバのどちらにつながるかが分かれることがあります。
そのため、切替直後に旧サーバを解約するのは危険です。 DNS切替前にはTTL値を短くし、切替後も数日から1週間程度は旧サーバを残して、 サイト表示、メール送受信、フォーム送信などを確認する期間を設けると安全です。
サーバ構成やクラウド、VPSの違いについては、 クラウドとVPSの違い でも整理しています。
移管方法は、何を変えたいのか、どこまで管理を整理したいのかによって変わります。 まずは、現在のドメイン管理会社、DNS管理先、WEBサーバ、メールサーバを一覧にして、 変更したい範囲を明確にしましょう。
| 選び方 | 向いているケース |
|---|---|
| ドメインは残してサーバだけ移管 | まず安全に移行したい、WEBサイトだけ移転したい、メールは現状維持したい |
| ドメイン管理会社ごと移管 | 契約会社を整理したい、管理を一本化したい、長期的に運用をシンプルにしたい |
不安がある場合は、最初からすべてを同時に変えるのではなく、 WEBサーバ、メール、DNS、ドメインの順に影響範囲を分けて確認すると、 トラブルを減らしやすくなります。
WEBサーバ・メールサーバ・DNS移管では、 「ドメインは残してサーバだけ移管するのか」 「ドメイン管理会社ごと移管するのか」によって作業内容が大きく変わります。
ドメインを残す方法は、作業範囲を限定しやすく、比較的安全に進めやすい方法です。 一方、ドメイン管理会社ごと移管する方法は、管理を一本化しやすい反面、 DNS設定やメール設定の引き継ぎを慎重に行う必要があります。
特にメール運用中の企業では、MXレコード、SPF、DKIM、DMARCなどの確認が重要です。 移管前に現在の設定を控え、切替後もサイト表示、メール送受信、フォーム通知を確認しながら、 段階的に進めましょう。