CloudflareでDNS設定する方法と注意点

2026年8月20日
Cloudflare

こんにちは。Osukeラーニング、運営者の「osuke」です。

CloudflareのDNS画面を開くと、A、AAAA、CNAME、MX、TXT、TTL、Proxy statusなどの項目が並びます。「どれに何を入れればよいのか」「オレンジ色の雲にすれば全部安全なのか」と迷いますよね。DNSはサイトだけでなく、独自ドメインメールや外部サービスの認証にも関わるため、分からないまま変更するのは避けたいところです。

この記事では、CloudflareでDNS設定する方法を、レコードの種類、入力値、Proxy状態、TTL、DNSSEC、エラー対応まで順番に解説します。osuke本人の体験としては書かず、2026年8月20日時点のCloudflare公式資料と、Xで公開された利用者の成功・失敗事例を照合しました。導入前の流れはCloudflareの始め方と初期設定手順、全体像はCloudflareとは何かを解説した記事をご覧ください。

記事のポイント

A・AAAA・CNAME・MX・TXTの使い分け
ProxiedとDNS onlyの判断基準
TTL・DNSSEC・反映時間の注意点
NXDOMAINやSERVFAILの切り分け方

CloudflareでDNS設定する基本手順

DNS設定は、レコードを追加する前の確認が半分を占めます。まず現在の権威DNSとレコードを保存し、接続先サービスが指定する「種類・名前・値」を確認します。その後、Cloudflareで必要なレコードだけを追加し、表示やメールをテストする流れです。

DNSの管理場所と変更前の準備

最初に、現在どこがDNSを管理しているか確認します。一般的なFull setupでネームサーバーをCloudflareへ変更し、対象ドメインがActiveなら、DNSレコードの編集場所はCloudflareの「DNS Records」です。ドメインを購入したレジストラやレンタルサーバーにもDNS画面が残っている場合がありますが、権威ネームサーバーが参照していない画面を編集しても、公開中の名前解決には反映されません。

Xでは、メール設定でCloudflareを挟んでいることに気づかず、レコード設定まで2時間かかったという公開投稿がありました。この事例は、入力内容以前に「どこを編集するか」で迷うケースを示しています。レジストラのドメイン情報でネームサーバーを確認し、Cloudflareから割り当てられた2件と一致しているなら、変更先をCloudflareへ一本化して考えましょう。

編集前には現在のレコードを保存します。CloudflareではDNS Records画面のImport and Exportからエクスポートでき、公式資料ではゾーンファイルの書き出しと読み込みが案内されています。A、AAAA、CNAME、MX、TXTの値だけでなく、TTL、Proxy状態、MXの優先度も控えます。初めての変更なら、エクスポートファイルと画面のスクリーンショットを両方残すと比較しやすいです。

次に、各レコードへ「Web」「メール」「所有権確認」「不明」の用途を付けます。不明なレコードは削除せず、ホスティング会社やメール会社の設定資料を確認してください。DNSの整理と接続先変更を同日に行うと、問題が起きたときに原因を分けられません。今日はWeb用レコード1件だけ、翌日に不要レコード整理というように、目的を分けるのが安全です。

変更前の準備

現在の権威ネームサーバーを確認
DNSレコードをエクスポート
Type・Name・Content・TTL・Proxy状態を保存
各レコードをWeb・メール・認証・不明へ分類
接続先サービスの公式指定値を用意

A・AAAAレコードの設定方法

Aレコードは、ドメイン名をIPv4アドレスへ向ける設定です。たとえばホスティング会社から192.0.2.10のようなIPv4を指定された場合、ルートドメインならNameへ@、ContentへそのIPv4を入力します。blog.example.comならNameへblogを入れます。AAAAレコードは同じ役割をIPv6アドレスに対して行います。

AとAAAAを両方設定する場合は、両方の接続先が正しく応答することを確認してください。IPv6側のサーバー設定が未完成なのにAAAAだけ残すと、IPv6を優先する環境だけ表示に失敗する可能性があります。接続先サービスがIPv4だけを案内しているなら、推測でAAAAを作らず、その提供会社の指定に従います。Cloudflare公式のDNSレコード型一覧でも、AのContentはIPv4、AAAAはIPv6と明確に分かれています。

入力時は、Name、Content、Proxy status、TTLを確認します。WebサイトのHTTP/S通信をCloudflare経由にするなら、A・AAAAはProxiedにできます。一方、接続先サービスが送信元IPの直接確認を要求する場合や、Web以外の専用通信ならDNS onlyが必要なことがあります。CloudflareのIPアドレスをContentへ入れるのではなく、元サーバーのIPを入力する点にも注意してください。

保存後は、ルートドメインとwwwを別々に確認します。@のAレコードだけでは、wwwが自動で追加されるとは限りません。www用Aを同じIPへ向けるか、wwwをルートドメインへ向けるCNAMEを用意します。トップページだけでなく、管理画面、フォーム、画像の表示まで確認すると、接続先が正しいか判断しやすくなります。

A・AAAAの入力例

A / @ / 192.0.2.10：ルートドメインをIPv4へ接続
A / blog / 192.0.2.20：blogサブドメインをIPv4へ接続
AAAA / @ / 2001:db8::10：ルートドメインをIPv6へ接続
接続先が案内していない種類は推測で追加しない

CNAMEレコードの設定方法

CNAMEレコードは、ある名前を別のホスト名へ向ける設定です。接続先サービスからproject.example-host.comのような値を指定された場合、app.example.comを接続するならTypeをCNAME、Nameをapp、Targetを指定されたホスト名にします。IPアドレスを直接入れるAレコードと違い、接続先側のIPが変わっても、CNAMEのTargetが同じならDNSを更新せずに済むことがあります。

Xでは、Cloudflareで取得したドメインをサブドメインに分け、AI経由でCNAME登録まで完了した公開例がありました。CNAMEは複数の小さなWebサービスへapp、tool、demoなどを割り当てるときに便利です。ただし、AIが操作した場合も、Targetのスペル、対象ゾーン、Proxy状態を人が確認する必要があります。

同じNameにCNAMEとA・AAAAを重ねないことも大切です。Xには、AレコードからCNAMEへ移す際、TTLを下げてAを削除し、CNAMEを追加する流れでよいか迷った公開投稿があります。これは実施結果ではなく質問ですが、利用者が迷いやすい点を表しています。移行時は接続先サービスの手順を確認し、旧Aと新CNAMEを同名で同時に残さないようにします。

ルートドメインの@へCNAMEを設定したいサービスもあります。Cloudflareは全プランでゾーン頂点のCNAME flatteningを既定で行い、最終的なIPを回答できます。ただし、ドメイン所有権確認用のCNAMEをFlattenまたはProxiedにすると、第三者サービスが期待するCNAME応答を得られない場合があります。公式のCNAME flattening設定と、接続先サービスの指定を合わせて判断してください。

CNAME変更時の注意

TargetにはIPではなく完全なホスト名を入れる
同じNameへA・AAAAとCNAMEを重ねない
所有権確認用CNAMEはDNS onlyを優先
AI操作後もTargetとProxy状態を確認
ゾーン頂点ではCNAME flatteningの挙動を理解する

MX・TXTレコードの設定方法

MXレコードは、独自ドメイン宛てのメールをどのメールサーバーへ届けるか指定します。Nameは通常@、Mail serverにはGoogle Workspace、Microsoft 365、レンタルサーバーなどが案内するホスト名を入力し、Priorityも指定どおりに設定します。数値が小さいものから優先されるため、複数MXの値を自己判断で並べ替えないでください。

TXTレコードは、SPF、DKIM、DMARC、サイト所有権確認など文字列情報を公開するために使います。同じTXTでも役割が異なるため、長い文字列を省略したり、引用符を二重に付けたりしないようにします。SPFは通常、同じNameへ複数のv=spf1レコードを作るのではなく、利用する送信サービスを1つのポリシーへ統合します。具体値は必ずメール提供会社の資料を優先してください。

Xでは、Cloudflare移行時はWeb用DNSとメール用DNSを分け、メールサーバーへProxyを使わないという公開投稿がありました。Cloudflare公式も、MXはプロキシできず、MXが参照するメール専用A・AAAAもDNS onlyにするよう案内しています。CloudflareはSMTPポート25を既定では中継しないため、メール用ホストをオレンジ雲にすると、メールサーバーではなくCloudflareのIPへ接続して失敗する可能性があります。

設定後は、DNS画面の見た目だけでなく送受信をテストします。外部メールから独自ドメインへ1通送り、受信後に返信し、迷惑メールフォルダとエラーメールも確認します。Webサイトが正常でもメールだけ壊れることがあるため、トップページ表示をDNS移行の完了条件にしないことが重要です。フォーム通知を使っている場合は、問い合わせ送信と管理者通知も確認します。

種類	Contentの例	主な用途	Proxy	設定ミスの症状
A	192.0.2.10	IPv4へ接続	Webなら可	サイトが別IPへ接続
AAAA	2001:db8::10	IPv6へ接続	Webなら可	IPv6環境だけ失敗
CNAME	host.example.com	別ホスト名へ接続	Webなら可	サブドメインや認証が失敗
MX	mail.example.com	メール受信先	不可	メールを受信できない
TXT	v=spf1 …	送信認証・所有権確認	不可	送信失敗・認証解除

メールDNSの確認項目

MXの参照先とPriority
メール専用A・AAAAはDNS only
SPF・DKIM・DMARCの完全な文字列
外部アドレスとの送受信テスト

Proxy statusの選び方

Proxy statusは、DNSの名前解決だけでなく、その後のHTTP/S通信をCloudflare経由にするか決める設定です。オレンジ色の雲であるProxiedでは、訪問者へCloudflareのAnycast IPを回答し、CDN、DDoS保護、WAFなどを利用できます。灰色の雲であるDNS onlyでは、CloudflareはDNS回答だけを行い、通信は接続先へ直接進みます。

Cloudflare公式は、Webサイト、Webアプリ、HTTP/SのAPIに使うA、AAAA、CNAMEをProxiedにすることを推奨しています。一方、MXとTXTは常にDNS onlyです。メール専用ホスト、FTP、SSH、第三者サービスのドメイン所有権確認用CNAMEなども、CloudflareのHTTPプロキシへ対応しないためDNS onlyを使います。詳しい判断はProxy statusの用途別ガイドで確認できます。

「オレンジ雲にすればすべての通信が守られる」という理解は危険です。Cloudflareで標準的にプロキシできるのは、対応ポートのHTTP/S通信です。公式のProxying limitationsでは、非標準ポートやTCP/UDPアプリは別の対応が必要と説明されています。メール、SSH、データベース接続まで同じスイッチで中継されるわけではありません。

Proxy状態を変更した後は、Web表示だけでなく、オリジンサーバー側のWAFやIP許可設定も確認します。Cloudflare経由では接続元がCloudflareのIP帯になるため、ホスティング側が遮断すると403などになる場合があります。まず対象ホストの用途を1行で書き、「HTTP/Sの公開Web」ならProxied、「メール・認証・非対応通信」ならDNS onlyと判断すると迷いにくくなります。

Proxy状態の判断

Webサイト・Webアプリ：Proxiedが基本
HTTP/S API：接続条件を確認してProxied
メール専用ホスト：DNS only
所有権確認CNAME：DNS only
FTP・SSHなど非HTTP/S：DNS onlyまたは別製品を検討

CloudflareのDNS設定で失敗しない方法

正しいレコードを保存しても、キャッシュ、DNSSEC、接続先側の変更によって問題が起きることがあります。ここからは「待てば直る状態」と「設定を直す状態」を分け、エラー時に変更を増やさず原因へ近づく方法を整理します。

TTLとDNS反映時間の考え方

TTLは、DNS回答を再確認するまでキャッシュしてよい時間です。長いTTLは問い合わせ回数を減らせますが、接続先を変更したときに古い回答が残る時間も長くなります。CloudflareのProxiedレコードはTTLがAutoとなり、公式では300秒、つまり5分に設定されています。この値は編集できません。DNS onlyではプランに応じてTTLを設定できます。

ただし、TTLが300秒だから全員が5分後に必ず新しい表示になるわけではありません。端末、ルーター、インターネット事業者、ブラウザなどに別のキャッシュが残る場合があります。Cloudflare公式のTTL資料も、ローカルDNSキャッシュにより実際の変更体感が5分を超える可能性を説明しています。

AからCNAMEへ変えるような計画的な移行では、DNS onlyの旧レコードなら事前にTTLを短くし、そのTTLが経過してから本番変更する方法があります。Xでも、TTLを下げてからAをCNAMEへ変更し、後でTTLを戻す手順を検討した公開投稿がありました。ただしこれは質問段階の投稿で、正解は接続先サービスと現在のProxy状態によって変わります。

変更後は何度も値を往復させず、時刻、変更前後の値、端末、回線、結果を記録します。Wi-Fiとスマートフォン回線で結果が違うなら、権威DNSの値は正しくてもキャッシュ差が残っている可能性があります。TTL経過前にさらに別の値へ変えると、複数世代の回答が混在し、原因を追いにくくなります。

TTL変更の考え方

Proxied：Auto 300秒で変更不可
DNS only：計画移行前に短縮を検討
短縮後：旧TTLの経過を待って本番変更
変更後：端末・回線・確認時刻を記録
反映待ち中に値を何度も往復させない

DNSSECを安全に設定する手順

DNSSECは、DNS回答へ暗号学的な署名を付け、偽の応答へ誘導されていないか検証する仕組みです。Cloudflareへ既存ドメインを移す際は、旧DNSのDNSSEC情報がレジストラに残ったままネームサーバーだけ変わると、署名が一致せず接続できなくなる可能性があります。そのため一般的な移行では、旧DNSSECを適切に無効化してからネームサーバーを変更します。

CloudflareがActiveになり、A・CNAME・MXなどの動作確認が終わった後に、CloudflareのDNS SettingsでDNSSECを有効にします。Cloudflareは署名鍵を用意し、DSレコードの値を表示します。Cloudflare Registrar以外を使っている場合は、そのDS情報をレジストラ側へ登録する流れが基本です。公式のDNSSEC手順では、Cloudflare Registrarや一部TLDでは自動化される場合も説明されています。

旧DSレコードがキャッシュされている間に新しい署名へ切り替えると、検証するDNSリゾルバーがSERVFAILを返すことがあります。公式では、通常の移行で旧DSのTTLが切れるまで24〜48時間かかることがあると案内しています。DNSSECは「ONにすれば安全」という単独スイッチではなく、Cloudflare側の署名とレジストラ側のDSを一致させて初めて正しく動作します。

設定後はCloudflareの確認表示だけでなく、外部からDSとDNSKEYが正しく参照できるかを確認します。もしSERVFAILが出たら、Aレコードを何度も変える前に、レジストラに古いDSが残っていないか見ます。WebレコードのContentが正しくても、DNSSEC検証に失敗すれば利用者は接続できないため、通常のNXDOMAINと分けて考える必要があります。

DNSSECの安全な順番

旧DNSSECとレジストラのDS状態を確認
必要に応じて旧DSを削除しTTL経過を待つ
CloudflareへのDNS移行と動作確認を完了
Cloudflare側でDNSSECを有効化
表示されたDSをレジストラへ登録・確認

NXDOMAINとSERVFAILの直し方

DNS_PROBE_FINISHED_NXDOMAINは、問い合わせた名前に対応するDNSレコードがないと判断された状態です。ルートドメインは開くのにwwwだけNXDOMAINなら、www用AまたはCNAMEがない可能性があります。Cloudflare公式のNXDOMAIN確認手順でも、ゾーン頂点と使用中の各サブドメインに必要なレコードがあり、正しい接続先を指すか確認するよう案内しています。

SERVFAILは、DNSサーバーが正常な回答を返せなかった状態で、DNSSEC不整合が代表的な原因の一つです。旧DSとCloudflareのDNSKEYが一致しない、委任先ネームサーバーが間違っている、権威DNS側の応答に問題がある場合などが候補になります。NXDOMAINのように「レコードを追加すればよい」とは限らないため、エラー名を記録してから調べます。

最初の確認順は、CloudflareでゾーンがActiveか、レジストラのネームサーバーが今回割り当てられた2件と一致するか、対象Nameのレコードがあるか、Contentが正しいか、DNSSECのDSが一致するかです。トップページだけではなく、www、blog、apiなどエラーが出た正確なホスト名を確認してください。ルートとサブドメインは別レコードです。

DNS以外のエラーも分けます。名前解決が成功してCloudflareのIPまたはオリジンIPが返るのに、ブラウザで403、522、526などが出る場合は、WAF、オリジンへの接続、SSL証明書などDNS後段の問題です。DNSレコードを追加し続けるのではなく、エラーが「名前を引けない」のか「接続後に拒否される」のかを判断すると、確認範囲を半分にできます。

エラー別の最初の確認

NXDOMAIN：対象NameのA・AAAA・CNAMEが存在するか
SERVFAIL：DNSSECのDS・DNSKEYと委任状態
403：Cloudflare WAF、ホスト側WAF、アクセス制限
522：Cloudflareからオリジンへの接続
526：元サーバー証明書とSSLモード

接続先IP変更と運用の注意点

DNS設定は一度保存すれば永久に終わるとは限りません。固定IPを提供しないホスティング、移行中のサーバー、外部SaaSでは、接続先が変わることがあります。Aレコードへ古いIPを残すと、Cloudflare自体が正常でも訪問者を停止済みサーバーへ案内します。ホスティング会社からIP変更通知が来たら、対象A・AAAAのContentを更新し、旧IPを削除します。

Xでは、RailwayのIPアドレス変更へ対応できる仕組みになっておらず、サービス停止後に復旧したという公開事例がありました。投稿には具体的なレコード型が書かれていないため、Aレコードが原因だと断定はできません。ただし、接続先が変動する環境で固定IPを前提にすると保守が必要になる、という運用上の問題を示しています。

接続先サービスがCNAME用ホスト名を指定しているなら、自己判断で現在のIPを調べてAレコードへ固定せず、公式手順のCNAMEを使うほうが変更へ追従しやすい場合があります。反対に、固定IPを正式に指定するサービスならA・AAAAを使います。Xでも、独自ドメイン割り当てでCNAME/Aレコードを使う運用への言及があり、接続先がホスト名かIPかが基本の判断軸になります。

月1回はDNSレコードの用途と接続先を確認し、ホスティング会社の変更通知を受け取れるメールアドレスを維持します。AIやAPIでDNSを自動更新する場合も、Global API Keyではなく対象ゾーンのDNS Editだけに絞ったTokenを使い、変更履歴を残します。自動化は便利ですが、誤ったレコードを高速に広げる可能性もあるため、削除や大量変更には人の承認を入れるのが安心です。

DNSの保守項目

ホスティング会社のIP・ホスト名変更通知
月1回の接続先と用途の棚卸し
変更される接続先では公式CNAME指定を検討
API Tokenは対象ゾーンの必要権限だけ
変更前後の値と実行者を記録

DNS設定後の確認を完了する

CloudflareのDNS設定を終える条件は、レコードが保存できたことではありません。Webサイト、www、使用中のサブドメイン、メール送受信、外部サービスの所有権確認が動き、異なる回線でも同じ結果になることです。変更したレコード1件に対して、どのURLまたは機能で成功を確認するかを先に決めると、判断が曖昧になりません。

今回調べたX投稿群では、CNAME登録までAIが進めた成功例がある一方、CloudflareがDNS管理先だと気づかず2時間かかった例、メールのProxyを分ける運用、接続先IP変更へ追従できず停止した例がありました。共通点は、DNSの文法だけでなく「管理場所」「サービスの用途」「変更後の保守」が結果を左右していることです。個々の投稿はCloudflare全体の仕様ではないため、仕様判断は公式資料を優先します。

設定後24時間は、主要ページ、メール、フォーム、サブドメインを時間を空けて再確認します。エラーが出たら、時刻、回線、端末、URL、エラーコード、直前に変えたレコードを記録してください。複数のレコードを一度に編集していると原因が分からなくなるため、問題がないことを確認してから次の変更へ進みます。

今日できる最初の一歩は、CloudflareのDNS Recordsから現在のゾーンをエクスポートし、各レコードへ用途を書くことです。A・AAAAはIP、CNAMEはホスト名、MXはメール受信先、TXTは認証という分類ができれば、不要な変更を減らせます。次は、元サーバーまで含めてHTTPSを安全にするCloudflareのSSL設定を扱います。

DNS設定の完了チェック