Cloudflare DNSの設定手順｜Webとメールを止めずに切り替える確認項目

CloudflareへDNSを切り替えるときは、既存レコードを照合してからネームサーバーを変更し、Web・メール・外部サービスを別々に確認します。 Cloudflareの自動スキャンだけで、必要なレコードがすべて揃ったとは判断しません。

この記事は、通常のFull setupでCloudflareを権威DNSとして使う場合を扱います。ドメインの登録会社を変更する移管や、Webサーバーの引っ越しとは別の作業です。停止を避けるための確認項目を示しますが、DNSのキャッシュや元環境の条件による影響をゼロと保証するものではありません。

変更前に、ドメインに関わる契約を分ける

最初に「どの会社で何を管理しているか」を整理します。Web制作会社、ドメイン登録会社、メール提供会社が別々というケースは珍しくありません。

管理対象	確認するもの
ドメイン登録	ログインできる担当者、ネームサーバー・DNSSECの変更権限
現在のDNS	全レコードのエクスポート、現在のネームサーバー
Web	A・AAAA・CNAMEの指定値、独自ドメインと証明書の設定
メール	MX、SPF、DKIM、DMARC、メールサーバー名
外部サービス	ドメイン確認用TXT・CNAME、サブドメイン、SRVなど

控えは、値だけでなくレコード名・種類・優先度・TTLも含めます。TTLはDNS情報をキャッシュする時間の目安です。必要に応じて元のTTLを事前に調整しますが、直前に下げても、すでに保持されている情報まで即座に消えるわけではありません。

Cloudflareへ追加し、検出結果を元の一覧と比べる

Cloudflareへ対象ドメインを追加し、利用プランを選びます。DNSのクイックスキャン結果が表示されたら、元DNSの一覧と一件ずつ照合します。公式にも、クイックスキャンがすべての既存レコードを見つける保証はないと記載されています。公式：Full setupの手順

レコード	よくある役割	見落としやすい点
A・AAAA	Webや各サーバーのIPアドレス	IPv4だけ直し、古いIPv6が残る
CNAME	別のホスト名への参照	所有確認用なのかWeb公開用なのか
MX	メールの受信先	優先度と全レコードの組み合わせ
TXT	SPF・DKIM・DMARC・所有確認など	長い値、名前、引用符の扱い
SRVなど	特定サービスの接続先	Webと無関係なため棚卸しから漏れる

SPFやDKIMの値を「Cloudflareへ移すから」という理由だけで作り直さないでください。まず現在のメール提供元が指定する値を保ちます。SPFを追加して同じホストに複数のSPFレコードができるなど、意図しない変更を混ぜないことが大切です。

オレンジ雲は、Web通信に使うかを判断する

CloudflareのDNSレコードには、ProxiedとDNS onlyの状態があります。ProxiedはWeb通信をCloudflare経由にし、DNS onlyは名前解決を提供します。プロキシの対象にできる種類や通信には条件があります。公式：Proxy status

DNSをCloudflareで管理することと、すべての通信をCloudflareのプロキシへ通すことは別です。

• Web公開用のA・AAAA・CNAMEは、利用するホスティングサービスの案内と証明書の状態を確認して選びます。
• メール用ホスト名のA・AAAA・CNAMEは、通常DNS onlyで扱います。
• 所有確認用CNAMEは、サービス側からDNS onlyを求められる場合があります。
• MXやTXTは、Web向けプロキシを通す設定として扱いません。

プロキシを有効にしたら、Cloudflareと接続先サーバーのHTTPS設定も確認します。証明書の問題を避けるために、理由を調べず暗号化設定を弱めないようにしてください。公式：SSL暗号化モード

DNSSECを確認してから、ネームサーバーを変える

通常の移行では、現在のDNSSECを有効にしたままネームサーバーだけを変更すると、古い署名情報と新しいDNSが合わず、名前解決に失敗する可能性があります。

1. 元環境とドメイン登録会社で、DNSSEC・DSレコードの状態を確認する。
2. 通常のFull setup手順に従い、切り替え前に既存DNSSECを無効化する。
3. 古いDS情報の削除・反映を確認する。
4. ドメイン登録会社で、Cloudflareが指定したネームサーバーへ置き換える。
5. Cloudflareでドメインが有効になり、動作を確認してから、新しいDNSSEC設定を行う。

DNSSECを維持したまま移行する専門的な手順もありますが、この記事では通常の切り替えと混ぜません。既存のDNSSEC運用が必須なら、対応する移行手順を先に確認してください。公式：DNSSEC、DNSSECを維持した移行

ネームサーバーは、Cloudflare画面に表示された対象ドメイン専用の値を使います。他社サイトの記事に書かれた値を流用せず、元の値を残したまま追加するのでもなく、案内された構成へ変更します。

Web・メール・外部サービスを別々に確かめる

変更後は、Cloudflareの有効化表示だけで完了にせず、利用者が行う操作を確認します。

確認対象	実施すること
Web	トップ、主要ページ、HTTPS、www有無、フォームを確認
画像・添付	別サブドメインやCDNの素材も取得できるか確認
メール受信	管理下の外部テストアドレスから受信を確認
メール送信	テスト宛先で到達と認証結果を確認
SaaS	ドメイン検証や独自URLの接続状態を確認
DNSSEC	再設定したDS情報と署名検証を確認

技術担当者は、次のような読み取りコマンドも利用できます。example.com は対象ドメインに置き換えます。

dig NS example.com
dig A example.com
dig AAAA example.com
dig MX example.com
dig TXT example.com
dig TXT _dmarc.example.com

DKIMの名前はメール提供元のselectorによって異なります。元の設定一覧から対象名を選んで調べます。ProxiedのWebレコードで、接続先のIPではなくCloudflareのIPが返ること自体は不具合ではありません。

不具合が出たら、何を戻すかを切り分ける

症状	最初に照合すること
ドメイン全体で名前解決できない	ネームサーバーの委任、古いDS、必要レコード
Webだけ開かない	A・AAAA・CNAME、プロキシ、接続先、証明書
メールだけ届かない	MX、メール用ホスト、メール提供元の指定値
一部の利用者だけ古い先へ行く	DNSキャッシュ、旧TTL、ネットワークごとの結果
外部サービスの確認が失敗する	TXT・CNAMEの名前と値、プロキシの指定

レコード不足なら修正で解消できる場合があります。ネームサーバーを戻す場合も、伝播やDNSSECの整合性を確認する必要があり、瞬時に旧状態へ戻るとは限りません。作業前に戻す条件と担当者を決め、元のDNS契約を直ちに解約しないようにします。

よくある質問

ドメインの登録会社もCloudflareへ変える必要がありますか？

通常のDNS切り替えでは必要ありません。登録会社でネームサーバーを変更し、DNSレコードの管理先をCloudflareにできます。

自動スキャンで見つかったレコードだけで足りますか？

保証はありません。メール、所有確認、使っていないように見えるサブドメインも、元の一覧と照合してください。

全レコードをオレンジ雲にすれば安全ですか？

通信の種類とサービスの指定に合わせます。メールや所有確認まで一律にプロキシへ通すと、必要な通信が動かない場合があります。

次に読む記事

• TunnelとAccessで社内Webへ接続する
• WorkersとPagesの選び方
• WordPressからEmDashへ移行する際のURL照合

公式情報の確認日：2026年10月22日。実際の変更はドメイン・メール・ホスティング各社の現行設定と照合して行ってください。