更新料金が上がった、管理画面が使いにくい、登録先を1つにまとめたい。それでドメインを移管したいが、メールが止まるのが怖い、という人へ。
ドメインの登録先を替える手続きと、DNS・メールの設定変更は別です。ただし、移管に伴う契約終了や設定変更でメールが止まることがあります。 DNSやメールが移管元の付属サービスなら継続条件を、移管先には現在のネームサーバーを使い続けられるかを確認します。
この記事の設定確認は、DNSを扱える担当者向けです。コマンドを判断できない場合は実行を前提にせず、7節の依頼文で事業者・制作会社に確認してください。確認結果だけで無停止や復旧を保証するものではありません。
- この記事で出来ること
- DNSとメールの管理先・契約継続条件・移管先の制約を確認し、設定担当者と移管の順番を決める
- 前提
- 移管元の管理画面に入れること。登録者のメールアドレスで受信できること
- 所要時間
- 契約条件の確認は事業者の回答次第。DNS変更や移管の日程は担当者と決める
先に結論:私ならこの順でやります
①いまのDNSがどこにあるかを見る → ②移管元のおまけなら、先にDNSを外へ出す → ③数日おく → ④移管する(ネームサーバーは引き継ぐ)
- DNSの引っ越しと移管を、同じ日にやらない。 止まったときに、どちらが原因か分からなくなります。
- 急がない移管は、有効期限の2か月前に始める。 期限の直前に始めて途中でつまずくと、更新切れと移管の失敗が重なります(2か月は私の目安です)。
- 既存DNSを使い続けられるか、移管元・移管先の両方へ確認する。 登録先から独立したDNSでも、移管先が外部DNSの利用を認めない場合があります。例えばCloudflare RegistrarはCloudflareのネームサーバーを使用する必要があります。
目次(9)
1. 5分で見分ける
DNS(ドメインの設定を預けている場所)とメールが、どの会社に置かれているかを見る2行です。見るだけで、何も変わりません。Windowsなら nslookup -type=NS example.com。コマンドを打たないなら、ICANNの登録データ検索(lookup.icann.org。.jp は JPRS WHOIS)の Name Server の欄でも、1行目と同じ答えが見られます。
dig +short example.com NS
dig +short example.com MX
1行目の答えがネームサーバーです。
| NSの答え | 意味 | 移管の前にすること |
|---|---|---|
| 移管元の登録事業者の名前が入っている | DNSが移管元のおまけ。移管後に使い続けられるかは事業者による | 公式ヘルプで確認。使えなくなる、または書いていないなら、先にDNSを外へ出す(4節) |
| レンタルサーバー会社やDNS専業の事業者の名前 | 別の事業者がDNSを提供している可能性 | 契約の継続と移管先での利用可否を確認。名前だけで契約関係を判断しない |
| 制作会社の名前、見覚えのない名前 | 誰かが管理している | 誰が管理しているかを先に突き止める。分からないまま移管しない |
2行目のMXが移管元の事業者のメールサーバを指しているなら、メール転送やメールボックスも移管元のおまけです。ドメインの契約に付属するサービスは移管で終了することがあるので、メールを先に別のサービスへ移します。
よくあるのは、ドメインを取ったときに「おまけのDNS」をそのまま使い始め、何年もたって本人もそれを忘れている形です。移管が完了した数時間後に、サイトもメールも名前が引けなくなり、取引先からの電話で気づきます。
2. 移管とネームサーバー変更は別の作業
| 移管 | ネームサーバー変更 | |
|---|---|---|
| 替わるもの | 契約先の事業者(更新の支払い先) | DNSの答えを返すサーバ |
| 手続きの場所 | 移管先で申し込み、移管元で準備する | いまの契約先の管理画面 |
| かかる時間 | 数日 | 設定はすぐ。行き渡るまではTTLしだい |
| メールへの影響 | DNS・メールの設定と契約が継続するかを確認する | 新しいDNSにMXなどが無ければ届かなくなる |
サーバを乗り換えるだけなら、移管は要りません。
3. 移管の決まり
gTLD(.com など)
ICANNの Transfer Policy の要点です(節番号は、2024年2月21日に更新され、2025年8月21日までに各事業者が実施することとされた版のもの)。
| 項目 | 内容 | 節 |
|---|---|---|
| 移管ロック | 管理画面の「移管ロック」は、レジストリ上の clientTransferProhibited という状態。付いている間は移管できない | I.A.5 |
| 認証コード(AuthInfoコード) | 移管先で入力する、ドメインごとのコード。登録者が自分でコードの取得やロックの解除をできる機能を事業者が用意していない場合、事業者は求めから5暦日以内にコードを渡し、ロックを外す | I.A.5.2 |
| 60日の制限 | 事業者は、登録から60日以内、前回の移管から60日以内の移管を拒否できる | I.A.3.7.5、3.7.6 |
| 登録者情報の変更後 | 登録者の名前・組織・メールアドレスを変えると、60日間の移管ロックがかかる。事業者が、変更の前にロックを辞退する選択肢を用意している場合がある | II.C.2 |
| 移管元の応答 | 移管元が5暦日以内に応答しなければ、承認されたものとして進む | I.A.3.5 |
| 登録期間 | 移管が完了すると登録期間が1年延びる(残りの合計は10年まで) | I.A.8 |
このポリシーは改定の手続きが進行中です。GNSOの作業部会は、60日の制限を30日に短くすることや、認証コードの呼び方を「TAC(Transfer Authorization Code)」に改めることなどを勧告し、GNSO評議会が2025年3月に最終報告書を採択しました。ただし、新しい版の適用日は、この記事の取得日の時点でICANNのページでは確認できませんでした。上の表は現行版の内容です。
ここでの落とし穴は1つです。移管の直前に、登録者のメールアドレスを「ついでに」直さないこと。 移管の確認や通知はそのアドレスに届くので、読めるアドレスにしておく必要はあります。しかし直前に変えると、上の60日ロックの対象になりえます。私なら、アドレスが読めるなら触らずに移管し、直すのは移管の後にします。読めないなら、先に直して60日待ちます。急ぐ理由のない作業です。
WHOISの代理公開は、移管の前に解除が必要な事業者と、そうでない事業者があります。移管元の公式ヘルプで確かめます。
.jp(指定事業者変更)
.jp では、契約先を替える手続きを「指定事業者変更」と呼びます。
- 登録者が、いまの指定事業者を通じて**認証コード(AuthCode)**を受け取り、新しい指定事業者に申し込みます。そのあと、いまの指定事業者からの確認に、登録者が「承認」を回答すると完了します。
- AuthCodeはJPRSがドメイン名ごとに発行し、有効期間は35日です。切れたら最初からやり直します。
- 指定事業者変更ロックやレジストリロックを付けている場合は、先に外します。
- .jp でいう「ドメイン名移転」は、登録者を別の人・組織に替える手続きのことで、事業者を替える手続きとは別です。申し込みの画面で取り違えると、名義を替える手続きを始めてしまいます。
- 属性型・地域型JP(co.jp など)では、変更後の指定事業者で担当者情報を新しく用意する必要があります。
4. 先にDNSを外へ出す
DNSが移管元のおまけだった人は、移管の前にこれをやります。
- 管理画面のレコード一覧を画面ごと保存し、
digでA・MX・TXT・NSも控える - 新しいDNSに、全レコードを写す
- 新しいネームサーバーへ直接聞いて、同じ答えが返ることを確かめる
dig @ns1.new-dns.example example.com MX +short
- 切り替えるレコードのTTLを前日までに下げ、ネームサーバーの指定を替える
- 外部のアドレスと送受信を確かめ、数日おく
置き場所は、登録事業者とは別のDNSサービスを勧めます。 利用中のレンタルサーバーやグループウェアの事業者が提供するDNS、またはDNS専業のサービスです。理由は、登録先とDNSが同じ事業者だと、次に移管したくなったときに、また同じ心配をすることになるからです。ドメインが1つで、移管先のDNSを使い続けるつもりなら、移管先のDNSに先に全レコードを作っておく方法でも構いません。その場合は、移管の前にレコードを登録できるかを移管先の公式ヘルプで確かめてください。
5. 移管の当日
- 移管ロックを外し、認証コードを受け取る
- 移管先で申し込む。事前に確認したネームサーバーの方針と画面の選択が一致するか確かめます。 現在の指定を引き継げる場合は維持します。移管先のDNSが必須の場合は、必要なレコードと送受信を設定担当者が先に確認してから進めます。
- 登録者のメールアドレスに届く確認に応答する
- 完了後、
dig +short example.com NSとMXが手続き前と同じであることを確かめ、移管ロックをかけ直す
それでも短時間つながらなくなったとき、メールが消えにくいのは、送信側のサーバが再送を続けるからです(RFC 5321 4.5.4.1節は、諦めるまでの時間を少なくとも4〜5日とするよう述べています)。ただし当てにしてよいのは「つながらない」場合だけです。
6. 戻し方:どこまでなら引き返せるか
| 工程 | 戻せるか | 戻し方 |
|---|---|---|
| レコードを控える、新しいDNSに写す | 何も変わっていない | — |
| TTLを下げる | 戻せる | 元の値に戻すだけ |
| ネームサーバーの指定を替える(4節) | 戻せる。 移管の前なら、移管元の管理画面で元の指定に戻す | 旧DNSのレコードは消さずに残しておく。消していたら戻り先が無い |
| 移管を申し込む | 完了の前なら、移管元の管理画面や確認メールから拒否・取り消しができる事業者が多い | 公式ヘルプで先に確かめる |
| 移管が完了する | すぐには戻せない。 事業者は前回の移管から60日以内の移管を拒否できる(3節) | 移管先の制約とDNS・メールの状態を担当者に確認する |
| 移管元のDNS・メールの付属サービスが終了する | 戻せない | だから先に外へ出す |
移管後に名前が引けなくなっても、原因をネームサーバーの変更だけに決めつけません。事前の記録、移管先の利用制約、DNSのレコード、契約の状態を設定担当者・事業者に確認します。元の指定へ戻せるかも事業者の条件によります。原因と戻し先を確認せず、設定を変更しないでください。
私なら、移管元のDNSのレコードと契約は、移管が完了して1週間は消しません(1週間は私の目安です)。引き返す先を、自分で先に壊さないためです。
7. 事業者・制作会社に送る文面
移管元に認証コードを出してもらうとき。管理画面で自分で取れるなら不要です。
件名:example.com の移管に伴う認証コード発行と移管ロック解除のお願い
ご担当者様
example.com の登録者、(会社の正式名称)の(氏名)です。
他の事業者への移管を予定しており、下記をお願いします。
1. 認証コード(AuthInfo/AuthCode)の発行
2. 移管ロックの解除
3. 移管後、貴社のDNS・メール転送などの付属サービスがいつまで使えるか
会員ID: /登録者メールアドレス:
3を必ず聞いてください。この答えで、先にDNSを出す必要があるかが決まります。
DNSを制作会社が管理しているとき。
件名:example.com のDNSレコード一覧のご提供のお願い
○○様
ドメインの登録先を整理するため、example.com を別の登録事業者へ移管する予定です。
サイトとメールを止めないよう、事前に次の2点を確認させてください。
1. 現在のDNSレコードの一覧(A、MX、TXT、CNAME など、サブドメインの分も)
2. ネームサーバーは現状のまま引き継ぐ予定ですが、移管によって
貴社側のDNSやサーバの契約に影響が出ないか
設定の変更はお願いしません。サイトの保守は、これまでどおりお願いします。
社長への報告は3行です。
1. 目的:ドメインの登録先を(理由:更新料金/管理の一本化)のため移します。費用は移管料 円で、登録期間が1年延びます。
2. 影響:DNS・メールの継続条件と移管先の制約を確認し、停止リスクと復旧方法を担当者と整理してから進めます。
3. 日程: 月 日にDNS、 月 日に移管。期限( 月 日)の2か月前に終えます。
8. 確認表
| # | 確認すること | 済 |
|---|---|---|
| 1 | 登録・前回の移管・登録者情報の変更から60日を過ぎている(gTLD) | □ |
| 2 | 有効期限まで2か月以上ある。無ければ先に移管元で更新する | □ |
| 3 | 登録者のメールアドレスで受信できる(直前に変えない) | □ |
| 4 | dig のNSとMXで、DNSとメールが移管元のおまけかどうかを見分けた | □ |
| 5 | おまけなら、DNS・メールを先に外へ出し、数日の安定を確かめた | □ |
| 6 | DNSの全レコードを控えた | □ |
| 7 | 移管ロックを外し、認証コードを受け取った(.jp は有効期間35日) | □ |
| 8 | 移管先で現在のネームサーバーを使えるか確認し、設定方針を担当者と決めた | □ |
| 9 | 完了後、NSとMXの答えが変わっていない | □ |
| 10 | 移管ロック、自動更新、管理画面の2要素認証を設定した | □ |
出典(取得日: 2026-09-20。Cloudflare FAQのみ2026-10-05確認)
「期限の2か月前」「数日おく」は、規則の定めではなく筆者の実務上の目安です。
-
ICANN Transfer Policy(2024年2月21日更新版) https://www.icann.org/resources/pages/transfer-policy-2024-02-21-en
-
GNSO Transfer Policy Review(改定作業の状況) https://gnso.icann.org/en/group-activities/active/transfer-policy-review
-
JPRS「ドメイン名の管理指定事業者の変更」 https://jprs.jp/about/dom-rule/agent-change/index.html
-
RFC 5321 Simple Mail Transfer Protocol(4.5.4.1節) https://www.rfc-editor.org/rfc/rfc5321.html
-
Cloudflare Registrar FAQ(外部ネームサーバーの利用制約) https://developers.cloudflare.com/registrar/faq/