はじめに
ドメインの事業者移管（レジストラ変更）は、Auth-Codeの発行待ちや承認手続きなどで数日〜1週間以上のタイムラグが発生しがちです。
しかし、「レジストラの移管」と「権威DNSサーバーの移行」は完全に独立したレイヤーです。
移管完了を待たずに、現行レジストラ側のネームサーバー（NS）指定のみを先に新DNS（Cloudflare等）へ向けることで、稼働中の自宅メールサーバー等を1秒も止めることなく即座にDNS管理権限を先行移行できます。
本稿ではその移行アーキテクチャの概要と、最も事故が起きやすい「プロキシ透過」の注意点についてまとめます。
無停止先行切り替えのアーキテクチャ
DNSの切り替えで通信断を起こさないための基本原則は「受け皿の事前構築」です。
[ 旧レジストラ/DNS ]
│
├─ (1) レコード情報の完全抽出 (A / AAAA / MX / SPF / DKIM / DMARC)
│
▼
[ 新DNSサービス ]
│
├─ (2) 受け皿となる同一レコードを事前定義（※プロキシ無効化を徹底）
│
▼
[ レジストラ管理画面 ]
│
└─ (3) ネームサーバー（NS）の向け先を新DNSへ切り替え ➔ 即時移行完了
運用上の重要チェックポイント
-
Webとメールのプロトコル特性の違い
- CDN/DNSサービス（Cloudflareなど）のプロキシ機能は、主にHTTP/HTTPS（80/443）トラフィックを対象としています。
- メール配送ホストにプロキシを適用してしまうと、SMTP（25/465/587）やIMAP（993）といった独自ポート通信が遮断され、メール不通事故につながります。メール用A/AAAAレコードは必ず名前解決専用（DNS Only）で構成する必要があります。
- MTA（Postfix/Dovecot等）側の変更要否
- グローバルIPアドレスやホスト名が変わらない限り、外部からの名前解決の向き先が変わるだけなので、サーバー側のコンフィグ書き換えは不要です。
詳細な設定手順・コンフィグ具体例について
お名前.comの管理画面での具体的な操作キャプチャ、Cloudflare側での詳細なレコード設定値（SPF/DKIM等の書き方）、ターミナルでの浸透確認・導通テスト手順の全文は、以下のメインブログにて詳しく解説しています。
実際の構築・切り替え作業時のリファレンスとしてご活用ください。
👉 ブログ本編はこちら：
ドメイン移管の完了を待つな！お名前.comからCloudflareへ「自宅メールサーバー」を先行切り替えする無停止移行マニュアル