ドメイン移管で失敗しやすいポイントと確認手順

先に要点

ドメイン移管は、サーバー移転やDNS変更とは別の作業です。契約先のレジストラを変える作業として整理します。
失敗しやすいのは、移管ロック、AuthCode、メール受信、DNSレコード移し忘れ、ネームサーバー変更の混同です。
移管前にDNSレコード、メール設定、期限、Whois/登録者メール、移管制限を確認し、移管後にWeb・メール・SSL・サブドメインを確認します。

ドメイン移管は、Webサイトの引っ越し作業の中でも混乱しやすい部分です。
サーバーを変える、DNSを変える、ネームサーバーを変える、ドメイン契約先を変える が同じ話として扱われることがあるからです。

結論から言うと、ドメイン移管は ドメインの契約管理を別のレジストラへ移す作業 です。
Webサーバーの中身を移す作業ではありません。DNSレコードを書き換える作業とも別です。

この記事では、ドメイン移管で失敗しやすいポイントと、移管前・移管中・移管後の確認手順を実務向けに整理します。
サーバー移転との違いを先に押さえたい場合は、ドメイン移管とサーバー移転の違いとは？DNS・ネームサーバー・メール設定の注意点を整理もあわせて読むとつながりやすいです。

まず結論：移管だけならサイトは移動しない

ドメイン移管で最初に押さえたいのは、移管してもWebサイトのデータは移動しないことです。
ドメイン移管は、ドメインの契約先を変える作業です。

作業	変わるもの	主なリスク
ドメイン移管	レジストラ、契約管理先、更新支払い先	移管ロック、AuthCode、承認メール、期限切れ
ネームサーバー変更	DNSの管理先	DNSレコード移し忘れ、メール停止、サブドメイン停止
DNSレコード変更	Webやメールの向き先	古いIP、MX漏れ、TXT漏れ、TTL待ち
サーバー移転	Webサイトやアプリの置き場所	ファイル漏れ、DB移行漏れ、SSL、メールフォーム不具合

この4つを混ぜると事故が起きます。
たとえば、ドメイン契約先を変えるだけのつもりでネームサーバーまで変えてしまうと、Webやメールが止まることがあります。

失敗1：サーバー移転とドメイン移管を同時にやる

よくある失敗は、サーバー移転、DNS変更、ドメイン移管を同じ日にまとめて進めることです。
一気に終わらせたくなりますが、トラブル時の切り分けがかなり難しくなります。

たとえば、移管後にサイトが見えない場合、原因候補が一気に増えます。

移管が完了していない
ネームサーバーが変わった
DNSレコードが足りない
AレコードのIPが古い
SSL証明書が合っていない
サーバー側の設定が違う
メール設定が移っていない

安全に進めるなら、まずサーバー移転を完了させ、Webとメールが安定してからドメイン移管を行う方が分かりやすいです。
逆に、契約整理だけが目的なら、サーバーやDNSは触らず、ドメイン移管だけに絞る判断もあります。

失敗2：移管ロックを確認していない

ドメインは、いつでも自由に移管できるとは限りません。
ICANNのTransfer Policyでは、登録者情報変更後に60日間の移管制限がかかるケースが説明されています。
また、ICANNのFAQでも、登録直後や直近で移管したドメインなど、移管できない条件が案内されています。

よく確認するのは次です。

新規登録から日が浅くないか
直近でレジストラ移管していないか
登録者情報を最近変更していないか
ドメインがロック状態になっていないか
有効期限が近すぎないか
対象TLDで独自の制約がないか

移管直前に登録者メールアドレスを変更すると、移管制限に引っかかることがあります。
連絡先を整える作業は必要ですが、移管直前に不用意に変更しない方がよい場面もあります。

失敗3：AuthCodeを取れない、古い、漏らす

ドメイン移管では、多くの場合AuthCodeが必要です。
AuthCodeは、移管を申請する人がドメイン管理者であることを確認するための認証コードです。
ICANNも、AuthCodeはドメイン名保持者を識別し、不正な移管を防ぐためのコードとして説明しています。

AuthCodeまわりで起きやすい失敗は次です。

現在の管理画面でAuthCodeの取得場所が分からない
ドメインロック解除前でAuthCodeが使えない
古いAuthCodeを使って移管申請する
AuthCodeをチャットやメールに平文で残しすぎる
制作会社や前任者しか管理画面に入れない

AuthCodeは、パスワードに近い扱いで管理します。
誰でも見られるチケットやチャットに残すのは避け、移管完了後は不要な共有を消す運用も考えます。

失敗4：承認メールを受け取れない

移管では、登録者メールや管理担当者メールへ確認メールが届くことがあります。
ここを見落とすと、移管が進まない、期限切れで失敗する、ということがあります。

確認したいのは次です。

登録者メールアドレスを受信できるか
迷惑メールに入っていないか
前任者や制作会社のメールになっていないか
退職者のメールアドレスになっていないか
ドメイン管理画面の通知先が正しいか

ただし、移管直前に登録者情報を変更すると移管ロックにつながる場合があります。
メールが受け取れない場合は、現在のレジストラの仕様を確認しながら進めます。

失敗5：DNSレコードを移し忘れる

ドメイン移管だけなら、通常はDNSレコードが勝手に変わるとは限りません。
しかし、移管と同時にネームサーバーやDNS管理先を変える場合は、DNSレコードの移し忘れが大きな事故になります。

移し忘れやすいのは、WebのAレコードだけではありません。

Aレコード
CNAME
MXレコード
SPF
DKIM
DMARC
外部SaaS認証用TXT
Google Search Consoleなどの所有権確認TXT
サブドメイン
API、管理画面、ステージング環境

Cloudflareの移管手順でも、移管前にDNSを追加し、DNSレコードを確認する流れが案内されています。
DNS管理先を変えるなら、切り替え先に必要なDNSレコードを全部入れてから変更します。

失敗6：メール設定を軽く見る

ドメイン移管やDNS変更で一番気づきにくい事故がメールです。
Webサイトが見えているので成功したと思ったら、問い合わせメールが届いていない、送信ドメイン認証が壊れている、ということがあります。

メールで見るポイントは次です。

項目	何を見るか
MX	メールを受けるサーバーが正しいか
SPF	送信元として許可するサーバーが入っているか
DKIM	メール署名用のTXT/CNAMEが入っているか
DMARC	SPF/DKIMの検証結果をどう扱うか
フォーム通知	Webフォームからの通知が届くか

移管後は、Gmail、Outlook、独自ドメイン宛など複数宛先へテスト送信する方が安全です。
受信だけでなく、送信、返信、迷惑メール判定も確認します。

移管前チェックリスト

ドメイン移管前に確認する項目です。

現在のレジストラを確認した
ドメイン有効期限を確認した
移管ロックの有無を確認した
AuthCodeを取得できる状態か確認した
登録者メールを受信できるか確認した
ネームサーバーを変更するか、据え置くか決めた
DNSレコードを全部控えた
Web、メール、サブドメイン、外部SaaSのレコードを分けて確認した
サーバー移転と同日にやらない判断をした
失敗時に誰が戻すか決めた

DNSレコードはスクリーンショットだけでなく、テキストでも控える方が実務では扱いやすいです。
可能なら、現在のDNS管理画面からエクスポートします。

移管中に見ること

移管申請後は、焦って何度も設定を変えない方がよいです。
まず移管ステータスを見ます。

移管申請が受理されたか
承認待ちになっていないか
旧レジストラ側で拒否や保留になっていないか
AuthCodeエラーになっていないか
登録者メールに確認が来ていないか
有効期限や更新費用の扱いに問題がないか

この段階で、Webが見えるかどうかだけを見ても十分ではありません。
移管は契約管理の移動なので、Web表示に変化がないまま進むこともあります。

移管後チェックリスト

移管完了後に確認する項目です。

新しいレジストラの管理画面でドメインが見える
ドメイン有効期限が想定通り
自動更新や支払い方法が設定されている
ネームサーバーが想定通り
DNSレコードが消えていない
Webサイトが表示される
www ありなしの両方が想定通り
SSL/TLS証明書エラーがない
問い合わせフォーム通知が届く
メール送受信ができる
SPF/DKIM/DMARCが壊れていない
サブドメイン、API、管理画面が動く
外部SaaSのドメイン認証が外れていない

特に、請求・更新設定は忘れやすいです。
移管できた直後は安心しがちですが、自動更新が切れていると、次の更新時に大きな事故になります。

よくある判断：ネームサーバーは変えるべき？

ドメイン移管時に、ネームサーバーまで変えるべきかはケースによります。

方針	向いている場面	注意点
ネームサーバー据え置き	まず契約先だけ変えたい	DNS管理先が別に残るので管理場所を記録する
ネームサーバーも移す	DNS管理も新しい事業者へまとめたい	DNSレコードを全部再現してから切り替える
Cloudflareなどへ移す	CDN、WAF、DNS管理をまとめたい	プロキシ有効/DNS only、メール系レコードに注意

安全重視なら、ドメイン移管とネームサーバー変更を別日に分けるのも良い判断です。
一度に変えるものが少ないほど、トラブル時の原因を切り分けやすくなります。

まとめ

ドメイン移管で失敗しやすいのは、移管作業そのものより、周辺作業を混ぜてしまうことです。
サーバー移転、DNS変更、ネームサーバー変更、メール設定、ドメイン契約先の変更を分けて考えるだけで、かなり事故を減らせます。

移管前には、レジストラ、有効期限、移管ロック、AuthCode、登録者メール、DNSレコード、メール設定を確認します。
移管後には、Web表示だけでなく、メール、SSL、サブドメイン、外部SaaS認証、自動更新まで確認します。

ドメインは小さな設定に見えますが、Web、メール、認証、SEO、広告、業務連絡の入口です。
移管は「契約先を変えるだけ」と軽く見ず、確認手順を作ってから進めるのが安全です。

参考

ICANN: FAQs for Registrants: Transferring Your Domain Name
ICANN: About Auth-Code
ICANN: Transfer Policy
JPRS: レジストラトランスファーに関する方針
Cloudflare Docs: Transfer your domain to Cloudflare
Cloudflare Docs: Import and export records

ドメイン移管で失敗しやすいポイントと確認手順｜DNS・メール・AuthCodeを整理