2026年8月21日

ドメイン移管の注意点｜サイトとメールを止めない事前確認と手順

ドメイン管理

ドメイン移管で失敗する原因の多くは、移管そのものではなく「移管できない期間に申請した」「旧レジストラのDNSが契約終了と一緒に消えた」「承認メールが届かなかった」といった準備不足です。この記事では、移管前に確認すべき状態、DNSとメールを止めないための段取り、申請から完了確認までの流れを順に説明します。読み終えるころには、自分のドメインがいま移管できる状態か判断し、WordPressサイトを動かしたまま移管を進められるようになります。

移管で変わるもの・変わらないもの

最初に整理しておきたいのは、「ドメイン移管」で変わるのはドメインの契約先（レジストラ）だけだという点です。次の3つは別々のものです。

ドメインの契約（レジストラ）: 更新料を払い、登録者情報を管理する先。移管で変わるのはここ。
DNSの管理（権威DNSサーバー）: どのIPアドレスにつなぐかを答える先。ネームサーバー（NS）の設定で決まる。
Webサーバー・メールサーバー: WordPressやメールが実際に動いている先。

外部のDNS（CloudflareやAmazon Route 53、レンタルサーバーのDNSなど）を使っているなら、移管してもNSは引き継がれ、サイトは通常どおり表示されます。注意が要るのは、旧レジストラが無料で提供しているDNSを使っている場合です。移管が完了して旧レジストラとの契約が終わると、そのDNSのゾーン情報も使えなくなることがあり、サイトとメールが同時に止まります。

移管できない期間と状態を先に確認する

60日ルール

ICANNが管理するgTLD（.com、.net、.orgなど）では、移管ポリシーにより次のタイミングから60日間は移管が拒否されることがあります（2026年10月現在）。

新規登録の直後
前回の移管の直後
登録者の変更（氏名・組織名・メールアドレスなどの変更）の直後。レジストラによっては変更時にこのロックを外す選択肢がある

特に見落としやすいのが3つ目です。移管の準備のつもりで登録者情報を書き換えると、そこから60日間移管できなくなる場合があります。登録者情報の修正は、移管が終わってから移管先で行うほうが安全です。なお、ICANNでは移管ポリシーの見直しが進められており、ロック期間などが今後変わる可能性があります。申請前に移管元・移管先の案内を確認してください。

期限との距離

有効期限が近すぎる、またはすでに切れている状態での移管は避けるのが無難です。gTLDの移管には通常1年分の更新が含まれますが、期限切れ後の猶予期間中に移管した場合の扱いはレジストラによって異なり、更新分が失われることもあります。目安として期限まで1か月以上ある時期に始めると、承認待ちや差し戻しがあっても間に合います。

ステータスの確認

ドメインの状態はwhoisコマンドかRDAPで確認できます。

whois example.com | grep -iE 'Registrar:|Status|Expiry'

# RDAP（.com はVerisignのRDAPサーバー）
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.status, .events'

clientTransferProhibited（RDAPでは client transfer prohibited）は移管ロックが有効な状態で、普段はこれが正常です。移管時だけレジストラの管理画面から解除します。一方、serverTransferProhibited や clientHold、redemptionPeriod、pendingDelete が出ている場合は、利用者側の操作では移管できない状態なので、先に原因を解消する必要があります。

移管前の準備

DNSを移管の影響外に置く

旧レジストラのDNSを使っているなら、移管より前にDNSを独立させます。手順は次のとおりです。

旧レジストラのDNS設定画面から、A・AAAA・CNAME・MX・TXT（SPF、DKIM、DMARC、サイト認証用）などのレコードをすべて書き出す
移管先または外部DNSに同じレコードを登録する
NSを新しいDNSに切り替え、旧DNSの設定は残したまま数日待つ
新しいDNSから正しい値が返ることを確認してから移管を申請する

切り替え前後の確認には dig を使います。

dig NS example.com +short
dig A example.com @新しいDNSのホスト名 +short
dig MX example.com @新しいDNSのホスト名 +short

NSの変更と移管を同時に進めると、どちらが原因で止まったのか切り分けにくくなります。1つずつ片付けるのがつまずきを減らすコツです。

DNSSECを使っている場合

DNSSECを有効にしている状態でDNS事業者を変えると、親ゾーンに登録されたDSレコードと新しいDNSの鍵が合わず、DNSSEC検証をするリゾルバーから名前解決できなくなります。DNS事業者も変える場合は、事前にDNSSECを無効化してDSレコードが消えたことを確認し、TTL分の時間を置いてから切り替え、移管後に改めて有効化するのが簡単です。

連絡先メールとWHOIS代行

移管の承認や通知は登録者のメールアドレスに届きます。そのアドレスが移管するドメイン自身のメールだと、DNSに問題が起きたときに受け取れません。別ドメインのアドレス（GmailやMicrosoftのメールなど）にしておくと安心です。ただし前述のとおり、登録者情報の変更が60日ロックの対象になることがあるため、変更するなら移管の十分前に済ませます。WHOIS情報公開代行を使っている場合は、移管元によって代行の解除が必要なことがあるので案内を確認してください。

移管の流れ

gTLDの一般的な流れは次のとおりです。画面の項目名はレジストラごとに違うため、目的で読み替えてください。

移管元でロックを解除する: 管理画面の「レジストラロック」「移管ロック」などの設定をオフにする
AuthCode（認証鍵、EPPコード）を取得する: 管理画面に表示されるか、メールで届く
移管先で申請する: ドメイン名とAuthCodeを入力し、1年分の更新料を支払う
承認を待つ: 移管元から確認メールが届く場合があり、承認すると早く完了する。何もしなくても通常は最大5日ほどで自動承認される
完了を確認する: whoisのRegistrarが移管先に変わったことを確認する

AuthCodeが「無効」と言われる原因は、コピー時の前後の空白、大文字小文字の違い、再発行前の古いコードの使用が大半です。ロック解除が反映される前に申請して拒否されることもあるため、解除後はステータスから clientTransferProhibited が消えたことを確かめてから申請します。

.jpドメインの場合、移管は「指定事業者変更」と呼ばれ、gTLDとは手続きや有効期限の扱いが異なります。.co.jpなどの属性型JPでは登録者の要件も関わるため、移管元・移管先それぞれの案内に沿って進めてください。

移管完了後に確認すること

whoisでRegistrarと有効期限が想定どおりか
dig NS でNSが変わっていないか（移管先が勝手に自社DNSへ切り替える設定になっていないか）
サイトの表示、管理画面へのログイン、メールの送受信
移管先でロックを有効に戻し、自動更新を設定したか
DNSSECを一時的に無効化した場合は再設定したか
SSL証明書の更新がDNSに依存している場合（DNS-01認証など）、次回の更新に支障がないか

旧レジストラのDNSやメール転送などの付帯サービスは、新しい環境での動作を確認してから解約します。順番を逆にするとサイトが止まる原因になります。

まとめ

移管で変わるのは契約先だけ。旧レジストラのDNSを使っているなら、移管前にDNSを独立させる
新規登録・前回の移管・登録者変更から60日以内は移管できないことがある。登録者情報の修正は移管後に
ステータスとAuthCode、連絡先メールを事前に確認し、期限まで余裕のある時期に申請する
DNSSEC、NS、付帯サービスの解約順に注意し、完了後はロックと自動更新を戻す