Notes / Web技術

XサーバーからWebだけCloudflare Pagesへ移す。ドメインとメールは残したまま

旧WordPressをAstroに書き換えてCloudflare Pagesに置いた。ドメインはXドメインで契約継続、メールはXサーバー経由のGoogle Workspaceで運用継続したい。WebだけをCloudflareに移すDNS移行の手順を、CloudflareのZone追加から伝播完了まで実機操作で記録する。

Cloudflare Pages DNS migration Xserver Google Workspace

旧WordPressをAstroに書き換えてCloudflare Pagesにデプロイした。残るのはDNSの切替だけ。ドメインはXドメインで契約継続、メールもGoogle WorkspaceをXサーバー経由で使い続けたいので、Webの配信先だけをCloudflareに向ける。

ありがちな構成ですが、「ドメインとメールを残したままWebだけCloudflareに移す」具体的な操作手順は意外と検索でも出てきません。実機操作のスクリーンショットで段階を残します。

出発点と目的の整理

出発点 (Before)

要素場所
ドメイン (<own-domain>)Xドメインで契約
ネームサーバー (NS)Xサーバー (ns1〜ns5.xserver.jp)
Web配信Xサーバー上のWordPress
メール配信Google Workspace (DNSはXサーバー DNSのMXでGoogleに向く)
Search Console認証DNS TXTレコード (google-site-verification=...)

到達点 (After)

要素場所
ドメイン契約Xドメイン (変更なし)
ネームサーバーCloudflare
Web配信Cloudflare Pages
メール配信Google Workspace (変更なし、MXはCF DNSからGoogleを指す)
Search Console認証CF DNSのTXTレコード (引き継ぎ)

切替で動かすのは NSだけ。ドメイン契約は動かさない、メールもMXをCF DNSに転記するだけで運用は変わらない。

事前にできていることの確認

DNS移行前に下記が済んでいる前提です。

  • Cloudflare Pagesプロジェクトが作成済み、<project>.pages.dev で新サイトが配信できている
  • 新サイトのmainブランチが最新化されている (production deploymentが新サイトを返す)
  • WordPress側でリダイレクト元になる旧URL (/recruit、/launch-of-website 等) が _redirects に反映済み
  • 万一に備えてWordPressの全データバックアップ手順が決めてある

特に「mainブランチがproduction deploymentと同期している」は見落としがちです。CF Pagesのproduction branch設定が古いmainを見ていると、DNS切替直後にユーザーが旧版を見ます。今回の作業前にも、redesign/... ブランチで進めていたデザイン刷新をmainにfast-forward mergeしてから着手しました。

DNS切替前のレコード現状把握

切替先 (Cloudflare) に転記するレコードを取りこぼさないため、Xサーバーで配信中のDNSを全部ダンプします。

$ for type in A AAAA CNAME MX TXT NS; do
    echo "--- $type ---"
    dig <own-domain> $type +short
  done

--- A ---
<xserver-ip>
--- AAAA ---
--- CNAME ---
--- MX ---
1 SMTP.GOOGLE.COM.
--- TXT ---
"google-site-verification=..."
"v=spf1 +a:sv<NNNNN>.xserver.jp +a:<own-domain> +mx include:spf.sender.xserver.jp include:_spf.google.com ~all"
--- NS ---
ns1.xserver.jp.
ns2.xserver.jp.
ns3.xserver.jp.
ns4.xserver.jp.
ns5.xserver.jp.

www.<own-domain> 側も忘れずに:

$ for type in A CNAME; do dig www.<own-domain> $type +short; done
<xserver-ip>

把握すべきレコード:

種別内容移行後の扱い
@ AXサーバー (<xserver-ip>)CF PagesのCNAMEに置換
www AXサーバー (<xserver-ip>)CF PagesのCNAMEに置換
@ MX1 SMTP.GOOGLE.COM.そのままCF DNSに転記
@ TXT (SPF)Xサーバー Aレコード + Googleを含むGoogleのみに簡素化検討
@ TXT (verification)Search Console認証そのまま転記
_dmarc TXT未設定新規に追加検討 (p=none 観測モード)
NSXサーバーCloudflareに切替 (移行のかなめ)

ここまでが事前準備。

Step 1: Cloudflareに対象ドメインのZoneを追加

ブラウザで dash.cloudflare.com にログインし、左サイドバーから「ドメイン (Domains / Websites)」へ。既存のサイトリストに対象ドメインがなければ、右上の 「ドメインを追加 (Add a domain)」 から登録します。

CloudflareのZoneを新規作成すると、そのZone専用の権威DNSサーバー名 (例: xxx.ns.cloudflare.com 形式の2つ) が割り当てられます。後のステップで、Xドメイン側で参照するNSをこれに切替えるのが移行のかなめの操作です。

入力するのは対象ドメインそのもの (<own-domain> のようなapex)。www. や *. のサブドメインをZoneとして登録する必要はありません。ひとつのZoneで配下のサブドメインも全部管理できます。

「接続」「転送」「購入」の3択は接続を選ぶ

CloudflareのAdd a siteフローでは3つの選択肢が並びます。

選択肢内容今回の用途
ドメインを接続 (Connect)契約は現Registrarのまま、NSだけCloudflareに向ける◯ これ
ドメインを転送 (Transfer)契約自体をCloudflare Registrarに移す (更新料金支払先がCFに)× ドメイン契約はXドメインに残したい
ドメインを購入 (Purchase)新規ドメイン取得× 既にある

「接続」と「転送」は名前が似ていて選び間違えやすいので注意します。NSだけ向けたいなら接続。Cloudflare Registrarの更新料金は他社より安い場合が多いので、長期的に契約自体を移したくなったら別途「ドメインを転送」を実行できます (NSをCFに向けた状態でも転送できます)。

接続時の初期設定3つ

「ドメインを接続」を選ぶと、ドメイン名入力欄と一緒に3つの初期設定が出ます。

DNSレコードのインポート方法: 「自動的にインポート (推奨)」のまま進めます。現RegistrarのDNSをスキャンして、見つかった全レコード (A、MX、TXT等) をCF DNSに自動コピーしてくれるので、手動入力の漏れを防げます。

AIクローラー制御: デフォルトは「すべてのページでAIクローラーをブロック」。OpenAI / Anthropic / Google AI等の学習クローラーをWAF層で全部弾く設定です。コーポレートサイト + 技術Notes記事の構成だと、AI学習データへの無断取り込みを避ける意味でデフォルトのまま (ブロック) が無難。AI検索からの認知を期待するなら許可に変える選択肢もありますが、後から個別記事単位で llms.txt を使う方法もあるので、まずは閉じておきます。

robots.txtでAIボットのトラフィックを指示: デフォルトのオンはオフにします。Cloudflare側にrobots.txtを生成させると、自前 (Astro / SSG) のrobots.txtと二重管理になり、CF側が優先で配信されてしまいます。AIクローラーブロックはWAF層で動くので、robots.txt制御をオフにしても効果は変わりません。

プラン選択は無料で足りる

接続フローの最後にプラン選択画面 (無料 / Pro $20/月 / Business $200/月 / Enterprise) が出ます。コーポレートサイト規模なら無料プランで十分です。

機能無料プラン
Universal SSL証明書 (HTTPS自動化)◯
権威DNS (高速)◯
グローバルCDN◯
Cloudflare Pages (unlimited static sites)◯
Workers (100Kリクエスト/日)◯

Proプラン以降のWAF / 高度なボット検出 / 画像最適化等は、静的SSGにはほぼ不要です。フォームのabuse制御はSaaS側 (Web3Forms等) で完結している前提なら、Cloudflare側で別層を立てる必要はありません。「無料プラン」を選択して次のステップへ。

Step 2: DNSスキャン結果の精査

無料プランを選ぶと、CFが自動的に現RegistrarのDNSをスキャンして、見つかったレコードをCF DNSにコピーした状態の編集画面に進みます。ここで一度立ち止まって、スキャン結果を全件目視で精査します。

CF自身が画面上部で警告しています。

スキャンでは、一般的でないレコードやカスタム サブドメインが見逃されている可能性があります。

つまり「自動インポートを信用しきらず、現DNSと照らし合わせろ」とCFが明言している。今回も実際にいくつかの判断点が出ました。

よくある「想定外」のレコード3種

スキャン結果を眺めていると、設計時に想定していなかったレコードが出てきます。今回見つかった例。

1. ワイルドカード A *

A   *   <xserver-ip>   (Xserver の IP)

レンタルサーバー契約時のデフォルトで、「定義されていないサブドメインへのアクセスを全部メインサーバーに向ける」設定。新サイトでは特定のサブドメインに何かを乗せる予定がなければ削除します。残しておくと、移行後に未使用のサブドメインが旧Xserver IPを引き続き指してしまい、伝播状態が分かりにくくなる。

2. メール送信サービスのDKIM

CNAME   s1._domainkey   →   s1.domainkey.u<account>.wl108.sendgrid.net
CNAME   s2._domainkey   →   s2.domainkey.u<account>.wl108.sendgrid.net

Sendgrid等の外部メール送信サービスを使った時に追加したDKIM認証用CNAME。「過去に使ったまま消し忘れている」「現在も使っている」を判別する必要があります。

削除すると、まだSendgrid経由で送信しているメールがDKIM認証失敗 → 迷惑メール扱いになる可能性があるので、安全側で維持するのが無難。Sendgrid管理画面でアカウントが閉鎖されていることを確認した上で削除に進む、という別タスク扱いにします。

ただし重要な落とし穴: CF DNSの自動スキャンが、DKIM用CNAMEを プロキシON (オレンジ雲) で設定してきます。DKIMはプロキシONだと壊れます (CFがCNAME応答に介入して、メール送信先が正しいDKIM公開鍵を取得できない)。DNSのみ (灰色雲) に手動で切替が必要です。

3. 既設定のDMARC

TXT   _dmarc   "v=DMARC1; p=..."

dig +short で @ のTXTを引いた時には見えなかった _dmarc サブドメインのTXTが、CFスキャンで掘り出されました。事前準備で「DMARC未設定」と判断していたのが間違いと判明。

教訓: 事前準備の dig だけでは取りこぼすレコードがある。CFのスキャン結果と、Xserver DNS管理画面の「全レコード一覧」を両方目視で照らし合わせる工程は必須です。

Web移行で削除すべきAレコード

メール系レコード (MX、SPF、DKIM、DMARC、Search Console verification) は全部維持。Web配信先を変更する目的で削除するのはAレコードのみ。

レコード削除する理由
A *Xserver IPを指すワイルドカード、新サイトでは不要
A <own-domain>Xserver IP、後でCF PagesのCNAMEで置換
A www同上

apexとwwwのCNAMEは、後のCloudflare Pagesカスタムドメイン設定の段階でCFが自動的に作成するので、今は何も追加しません。

編集中の本番への影響はゼロ

「重要なドメインのDNSレコードを削除する」操作は心理的に怖いですが、現時点では本番に影響しません。

NSをまだXドメインでXserverのままにしているので、世界中のDNSリゾルバはXserver DNSを権威として参照しています。CF DNSで何を編集しても、NSをCloudflareに切替えるまでは反映されません。「次にNSを切り替えたらこの状態になる」という設定をしている段階です。

この事実を理解してから編集に入ると、心理的負荷が下がります。

過去の移行で判断記録を残さなかったレコードの末路

別ドメインで以前同じXserver → Cloudflare Pages移行を実施した時の最終DNS状態を見返したら、ワイルドカード *.<old-domain> A <Xserver IP> がそのまま残っていました。当時の移行作業ドキュメント (Plans.md / deploy-cloudflare.md / design.md / 移行archive) を全部grepしても、このワイルドカードについての判断記録は皆無。

つまり「残した理由」ではなく「触らなかった理由 (= 検討漏れ)」がそのままレコードとして固定化された格好です。XserverサーバーのIP <xserver-ip> が将来再割当されたら、未定義サブドメインが他テナントのサイトを指してしまう。実害は薄いですが、運用上のbad smellです。

教訓: スキャン結果の各レコードに対して「なぜ残す / なぜ消す」を文書化する工程を移行作業の一部に組み込みます。後で別作業に呼ばれた人 (将来の自分を含む) が「なぜここに * がいるのか」を即時に理解できる状態を維持する。

CF DNS編集の具体操作

スキャン結果のレコード一覧から、Web配信先 (Xserver IP) を指す3件のAレコードを削除。

A   *                  <xserver-ip>   →  削除
A   <apex>            <xserver-ip>   →  削除
A   www                <xserver-ip>   →  削除

外部メール送信サービスのDKIM用CNAME (Sendgrid等) を、プロキシONからOFFに切替。

CNAME   s1._domainkey   →  プロキシ OFF (灰色雲)
CNAME   s2._domainkey   →  プロキシ OFF (灰色雲)

これで残り8レコードの状態に。MX、SPF TXT、DMARC TXT、Search Console verification TXT、Google Workspace用DKIM TXT × 2、Sendgrid DKIM CNAME × 2が維持されます。WebのCNAME (apex + www) は後のCloudflare Pagesカスタムドメイン追加段階で自動的に作成されます。

編集完了したら、画面下部の「アクティベーションに進む」ボタンをクリック。

「プロキシ済みレコードがない」警告は無視してよい

「アクティベーションに進む」を押すと、CFが警告モーダルを出すことがあります。

このドメインは完全に保護されていません。すべてのDNSレコードはプロキシ ステータスがDNSのみ に設定されています。DDoS保護、セキュリティ ルール、キャッシュなどのメリットを得るには、1つ以上のレコードを プロキシ に更新します。

これは正しい指摘ですが、今は無視して進めます。Web配信用のCNAME (apex + www) は後のCloudflare Pagesカスタムドメイン追加段階で自動的にプロキシONで作成されるので、その時点で警告は自然に解消します。

モーダルの「後で実行」を選んで進みます。「戻る」を押すと前の編集画面に戻ってしまうので注意。

Step 3: ネームサーバー案内画面とNS切替前の準備

「アクティベーションに進む」の次は、Cloudflareが割り当てたNS 2つが表示される案内画面に進みます。例えば <assigned-cf-ns-1> と <assigned-cf-ns-2> のようなホスト名のペア。これが移行先NSです。

ここから先の順序を間違えると、NS切替後に「ドメインアクセスは届くけれどCF Pagesのサイトが見つからない」中間状態 (Cloudflareが Site not found を返す) が長く続きます。次の順序が安全。

  1. Cloudflare Pagesにカスタムドメインを追加 (NS切替前)
  2. Registrar側でNSを切替 (NS切替の瞬間)
  3. CF画面で「ネームサーバーを更新しました」をクリック (CFに切替完了を通知)

CF Pagesのカスタムドメイン追加はNS切替後にやる

ここで意外な制約に当たります。CF Pagesのカスタムドメイン追加フローでドメインを入力すると、2ステップ目で「DNS管理を移行 - Pagesプロジェクトに <your-domain> を追加する前に、DNSをCloudflareに移行する必要があります」というメッセージが出て、進めなくなる。

CF Zoneを追加した時点で「ZoneはCFにある」状態ですが、CF PagesはZoneがアクティブ (= NSが実際にCloudflareに向き、Zoneステータスが「アクティブ」になっている) を要求します。NS切替前のPending Zoneでは受け付けない。

なのでカスタムドメイン追加はStep 4 (NS切替) を完了させてから実施します。順序を組み替えます。

旧順序 (うまくいかなかった)新順序
1CF Pagesカスタムドメイン追加RegistrarでNS切替
2RegistrarでNS切替CF Zoneアクティブ化を待つ
3CFにネームサーバー更新通知CF Pagesカスタムドメイン追加
4(動作確認)CFにNS更新通知

NS切替先行の影響として、伝播中に新NSを参照したユーザーが「Site not found」を一時的に見る可能性があります。ただし伝播速度は通常数分〜数時間で、コーポレートサイト規模ならアクセス頻度から見て実害は限定的です。

Step 4: RegistrarでNS切替

ドメイン契約元の管理画面 (今回はXドメイン) にログインして、NSを旧 (ns1.xserver.jp 〜 ns5.xserver.jp) からCFの2つに置き換えます。

並行して DNSSEC がオフであることも確認します。CF側もこの段階でDNSSEC未設定なので、オン → オフへの不整合伝播 (古いNSと新NSでDNSSECステータスがずれた状態でリゾルバが解決を試みると失敗する) を避ける必要があります。Xドメイン側でDNSSECオンになっている場合は、NS切替前にオフに戻すか、CF側でDNSSECを有効化してからNS切替する手順に切り替えます。

NS設定を保存して、ここで初めて世界中のDNSリゾルバがXサーバー NS → Cloudflare NSへの移行を始めます。

Step 5: Cloudflareに切替完了を通知

NS切替後、CloudflareのNS案内画面で「ネームサーバーを更新しました」(または「Check nameservers」) ボタンをクリックします。CF側でも独自にNS切替を検出する仕組みが動いていますが、明示的にクリックするとZoneがアクティブ化されるのが早くなります。

数分〜数時間でZoneのステータスが「アクティブ」に切り替わり、CF PagesカスタムドメインのSSLも自動発行されます。https://<own-domain>/ でアクセスすると新サイトが表示されます。

RegistrarでのNS切替の実操作 (Xドメインの例)

Xドメインの管理画面では「ネームサーバー設定」画面で XServer レンタルサーバー / XServer Domain / XServer VPS / その他のサービスで利用する の4択が並びます。Cloudflareに向けるなら「その他のサービスで利用する」を選択し、ネームサーバー 1と2にCloudflareが割り当てた2つのホスト名を入力 (3〜5は空欄)。「確認画面へ進む」→ 「設定を変更する」で確定します。

伝播状況のモニタリング

NS変更がJPRS (jp Registry) に反映されると、世界中の権威DNSが新NSを返します。複数のリゾルバを横並びで確認するのが速い。

# Google DNS が見ている NS
dig @8.8.8.8 <own-domain> NS +short

# Cloudflare DNS (1.1.1.1) が見ている NS
dig @1.1.1.1 <own-domain> NS +short

# ローカルリゾルバが見ている NS
dig <own-domain> NS +short

NS変更直後はまだ旧NS (Xserver) を返します。これはRegistry反映前のキャッシュ、もしくはRegistry自体がまだ更新前の状態です。通常Xドメイン → JPRSへの反映は数分〜数時間。CF画面のステータスが「アクティブ」に切り替わったら、伝播もある程度進んだサインです。

パブリックDNSリゾルバの伝播速度には差がある

NS切替後の伝播は、リゾルバごとに速度が大きく違います。今回の移行で1時間経過した時点の実測。

パブリックDNSNS反映
Cloudflare (1.1.1.1)反映済
Quad9 (9.9.9.9)反映済
OpenDNS (208.67.222.222)反映済
Google (8.8.8.8)キャッシュ中 (旧NS)
Google (8.8.4.4)キャッシュ中 (旧NS)
大手国内ISP (NTT系、KDDI系)反映済

Cloudflare DNSは自社の権威DNSなので即時反映。Quad9とOpenDNSは短いTTLポリシーで更新が早い。Google DNSは世界最大級のリゾルバの一つでTTLを尊重する保守的なキャッシュ動作のため、旧NSのTTL (今回は86400秒 = 24時間) が残っている間はキャッシュを返し続けます。

実害の現れ方として、「モバイルでは新サイト、デスクトップでは旧サイト」という非対称が発生しました。

  • モバイル: キャリアDNS (NTT Docomo / au / Softbank等の国内ISP DNS) を使うので、新サイトが見える
  • デスクトップ: ブラウザのDoH (DNS over HTTPS) がGoogle DNSをデフォルトで使う設定だと、旧サイトを見ることになる

確認方法: Chrome / Braveなら chrome://settings/security → 「安全なDNSを使用する」の設定値。Googleや Custom でGoogle DNSが指定されていると当てはまります。

回避方法: 「安全なDNSを使用する」をオフにしてOSのDNS (ISP DNS) を使う。またはDoHのプロバイダーを Cloudflare (1.1.1.1) に切替えれば即時で新サイトが見えます。

TTL短縮を事前にやらない選択の代償

事前にTTLを300秒に短縮しておくと、伝播は数分で完了します。今回はその手順をスキップしたので、Google DNSのキャッシュが切れるまで「デスクトップで旧サイトが見えるユーザー」が一定数残ります。コーポレートサイトのトラフィック規模なら実害は限定的ですが、eコマースや高頻度更新サイトの移行では事前TTL短縮が必須。

Step 6: 本番動作確認

NS切替がCF側でアクティブ化したら、本番動作確認に入ります。確認項目は3系統。

Web配信

主要URLをcurlで全件叩いて200が返ることを確認。CF DNSのAnycast IPに --resolve で直接当てると、自分のローカルキャッシュを介さずCF側の応答を見られます。

for path in / /services/ /about/ /notes/ /contact/ /privacy-policy/; do
  /usr/bin/curl -sI --resolve "<own-domain>:443:<cf-anycast-ip>" \
    -o /dev/null -w "%{http_code}" "https://<own-domain>${path}"
  echo " ${path}"
done

旧URLからのリダイレクトも同じ要領で全件検証。_redirects に書いたエントリが全部期待通りの301を返すかを目視より確実に拾えます。

メール

外部メアドから <personal-account>@<own-domain> 宛にテスト送信して、Workspaceで受信できることを確認。MXレコードはCF DNSに転記済みなので、NS切替が完了した時点でGoogle Workspace経由の受信が継続します。

catch-allメール経路を持っている場合は、<random-string>@<own-domain> のような未登録アドレスにも1通送って、Default Routingの転送先 (今回はXサーバー) に届くことを確認。

フォーム実送信

/contact/ で実フォームを送信して、管理者通知 + 自動返信の2通が届くことを確認。stagingで同等のテストをしていても、本番ドメインからの送信は別経路なので再実施が必要。

5ブラウザ目視は段階的に

docs/staging-checklist.md に書いた「5ブラウザ × 6 URLマトリクス」は、段階的に埋めます。最低限の即時クリアは以下。

  • 自分のメインブラウザ (デスクトップChrome / Safari) でフェード遷移とThree.js背景が動く
  • iPhone Safariでレイアウト崩れなし
  • DoH関連の不整合がないことを chrome://settings/security で確認

EdgeとAndroid Chromeは別タイミングでも問題ありません。重要なのは「Chrome / Safari / iOS Safariで問題なし = ユーザーの90% 以上がカバーされている」状態にあることです。

切替直後にやり残しがちな宿題

Web移行が完了した後、Xサーバーサーバープラン解約に向けて準備すべき宿題が残ります。今回見つかった分。

catch-allメール経路の移行先決定

Google WorkspaceのDefault RoutingがXサーバーのSMTPに転送する構成は、サーバー解約で sv<NNNNN>.xserver.jp が止まると同時に死にます。Cloudflare Email Routing が最も滑らかな移行先です。*@<own-domain> を任意のアドレスに転送するcatch-all機能を持っていて、CF DNSと統合されているので追加のレコード管理が不要です。

WordPressバックアップ取得

Xサーバーサーバープランを解約する前に、wp-content/ のtarアーカイブとDB dumpを取得して保管します。法定保存期間 (税務関連7年、契約関連は契約満了後5年) を考慮して保管先を決めます。

移行作業ドキュメントの整理

migrate/raw-html/ のような旧サイトのスナップショットをpublic repoに置いていると、GTM ID、Dynatrace endpoint、旧プラグイン構成情報などが漏れます。public repoから退避して別のprivate場所 (Google Drive、社内Notion等) に保管。.gitignore に追加するだけでは追跡済みファイルは消えないので、git rm --cached + 履歴削除 (必要なら git filter-repo) の判断もここで。

DNS切替を伴うWeb移行は、操作自体は数十分で終わる一方で、判断の積み上げで成否が変わります。スキャン結果の各レコードに「なぜ残す / なぜ消す」を文書化する、カスタムドメイン追加の前にmainを最新化する、catch-allメール経路の影響範囲を確認する。事前準備をどこまで丁寧にやれるかで、移行直後のトラブル件数が大きく変わります。

Web配信基盤の移行やDNS設計のご相談はお問い合わせから、業務領域の詳細はServicesへ。

念のためcatch-allメール経路を確認する

Google Workspace + Xサーバーの組み合わせでよくある構成として、「Google Workspaceに登録されていないアドレスへの受信をXサーバー SMTPに転送するcatch-all」があります。SES系のメールがGoogleの強いスパムフィルターに引っかかるのを避けるため、明示的にXサーバー受信に逃がしている運用です。

この構成はGoogle Workspace側の機能 (Gmail → ホスト + ルーティング) で実装されています。重要なのは「Googleが転送先として指定しているSMTPホスト名」が、移行対象ドメインのDNSで解決されるか別ドメインのDNSで解決されるかです。

確認するにはGoogle Workspace Adminで Apps → Google Workspace → Gmail → ホスト と ルーティング を開きます。

転送先ホスト名が sv<NNNNN>.xserver.jp のようにXサーバー独自の xserver.jp ドメイン下のホスト名なら、移行対象ドメインのDNS切替はcatch-allに影響しません。Xサーバー側 (xserver.jp の権威DNS) で解決されるので、移行対象ドメインでNSを変えても無関係。

転送先ホスト名が移行対象ドメイン (<own-domain>) 直下の何か (例えば mail.<own-domain> や smtp.<own-domain>) の場合は要注意。Aレコード削除やNS切替で解決経路が変わる可能性があるので、設定を見直す必要があります。

サーバー解約までにcatch-allの移行先を決めておく

Xサーバーサーバープランを解約すると、sv<NNNNN>.xserver.jp も止まります。WebをCloudflare Pagesに移しサーバー解約に向かう前に、catch-allの受け先を別系統に切替えておく必要があります。

候補:

選択肢コスト備考
Cloudflare Email Routing無料CF DNSと統合、catch-all対応、別アドレスに転送
Forwardemail.net無料 〜プライバシー重視、catch-all対応
Fastmail月 $3〜フル機能メール、catch-all対応

DNSが既にCloudflareに集約された後の運用なら、Cloudflare Email Routingが最も摩擦の少ない選択肢。*@<own-domain> を個人Gmail等に転送する設定が5分で完結します。

これはWeb移行と同タイミングではなく、サーバー解約タスクの一部として別途実施します。今は把握しておけば十分。

← 新しい記事

View Transitionsとstrict CSPの不可避な衝突。Astro security.cspの限界

過去の記事 →

AIエージェントに「今のプロジェクト名」を書くと失敗する

すべての記事を見る