CloudflareへDNSを移す時は、Web用A/CNAMEより先に「メールと認証の全レコード」を控えます。MXだけでなくSPF・DKIM・DMARC・ドメイン認証TXT/CNAMEまで新DNSへ移してからネームサーバーを切り替えます。
Cloudflareへネームサーバーを変更すると、Webサイトの表示だけでなく、そのドメインのDNS全体の管理先が切り替わります。WordPressが正常に表示されても、MXやTXTを移し忘れると独自ドメインメールだけが止まることがあります。
僕自身、複数ドメインでDNS・Zoho Mail・WordPressフォームを扱ってきました。DNS移行で大事なのは「Cloudflareの設定を覚えること」より、現在のDNSが担っている役割を1つも落とさないことです。サイト、メール、認証、サブドメインを分けて棚卸ししてから切り替えると事故を大きく減らせます。
Cloudflareへ移す前に保存するDNSレコード
| 種類 | 主な用途 | 移行時の注意 |
|---|---|---|
| A/AAAA | WordPressサーバーIP | Web用。Cloudflare proxy対象になり得る |
| CNAME | www、外部サービス、DKIM等 | Web用と認証用を区別する |
| MX | 受信メールの配送先 | 優先度も含めて完全一致させる |
| TXT SPF | 送信許可サーバー | 複数SPFを作らず1レコードへ統合 |
| DKIM | メール署名の公開鍵 | selector名を含めて移す |
| DMARC | 認証失敗時の方針・レポート | _dmarcのTXTを移す |
| 検証TXT/CNAME | Zoho、Google、各SaaSの所有確認 | 用途不明でも勝手に削除しない |
Cloudflareはオンボーディング時にDNSレコードをスキャンしますが、検出結果が完全である前提にしません。旧DNS画面のエクスポートやスクリーンショットを保存し、Cloudflare側と1行ずつ照合します。
DNSSECが有効なら先に扱いを確認する
Cloudflareのフルセットアップ手順では、既存DNSSECが有効なドメインでネームサーバーを交換する前にDNSSECを無効化するよう案内されています。古いDSレコードが残ったまま権威DNSだけ変更すると、検証に失敗してドメイン自体が引けなくなる可能性があるためです。
Cloudflareでゾーンが有効化したあと、必要ならCloudflare側でDNSSECを再有効化します。DNSSECはセキュリティ機能なので「面倒だから永久にオフ」にするのではなく、移行手順の一部として扱います。
MXとメール用ホストはCloudflareのWebプロキシと分ける
Cloudflare公式ではMXやTXTはプロキシ対象ではなく常にDNS onlyです。またMXが指すメール用ホストがA/AAAA/CNAMEで自前サーバーを指している場合、そのメール用ホストもDNS onlyにする必要があります。Cloudflareの通常HTTPプロキシはSMTPを中継しないためです。
Zoho Mailなど外部メールサービスを使っている場合は、Zohoが案内するMXや認証レコードをCloudflare DNSへ登録します。Cloudflare側で独自に値を置き換えるのではなく、メールプロバイダーの最新値を正本として扱います。
SPFは移行時に勝手に増やさない
旧DNSにSPFがある場合、その完全な値をCloudflareへ移します。Zoho等の設定を見て「新しいSPFを追加しよう」と2本目を作ると、SPF仕様上の問題になります。CloudflareのGoogle Workspace向け公式ガイドでも、複数送信サービスがある場合は同じSPFレコードへincludeをまとめ、2本目を作らないよう案内しています。
DNS移行とメールサービス移行を同日にまとめると、問題が起きた時にどちらが原因か分かりません。可能なら、DNS管理先だけCloudflareへ移す日と、メール提供元を変える日は分けます。
切替24〜48時間前にTTLを下げる
計画できるDNS移行なら、Cloudflare公式のDNSベストプラクティスでは切替の24〜48時間以上前に重要レコードのTTLを短くする方法が案内されています。例として300秒（5分）まで下げると、古い回答が長時間キャッシュされにくくなります。
ただし「ネームサーバーを変える直前にTTLを5分へ変更」しても、すでに旧TTLでキャッシュされた回答はその期限まで残ります。だから前日〜2日前に下げる意味があります。移行が安定したら、必要に応じて3600秒など通常運用向けへ戻します。
既存DNSSECがある場合はDS TTLを待ってからNSを変える
既存DNSSECを外してCloudflareへ移す場合、レジストラ側の古いDSを削除した直後にネームサーバーを変えるのは危険です。Cloudflareは、古いDSのTTLが完全に切れるまで待ち、dig DS example.com等で状態を確認してからNSを変更する手順を案内しています。Cloudflareの学習資料ではDS TTLは典型的に24時間（86,400秒）とされていますが、TLDによって異なるため実値を確認します。
切替手順｜メールを止めにくい順番
- 旧DNSの全レコードを保存する
- 現在のMX・SPF・DKIM・DMARCを外部から確認する
- Cloudflareへドメインを追加する
- Cloudflare側で全DNSを旧環境と照合する
- メール用ホストがあればDNS onlyになっているか確認する
- 必要なら旧DNSSECを切替前に処理する
- ドメイン登録側のネームサーバーをCloudflare指定値へ変更する
- CloudflareでActiveになったことを確認する
- Web、メール受信、メール送信、フォームを個別にテストする
- 安定後にCloudflare DNSSECを必要に応じて有効化する
切替直後にテストする順番
「自分のPCでサイトが見えた」だけでは判断しません。DNSキャッシュの差で、利用者ごとに新旧DNSが混在する時間があります。
| テスト | 確認内容 |
|---|---|
| DNS | NSがCloudflareへ切り替わったか |
| Web | ルート/www/主要サブドメインがHTTPS表示 |
| MX | 期待するメールサーバーが返るか |
| 受信 | 外部Gmail→独自ドメインが届く |
| 送信 | 独自ドメイン→Gmailが届く |
| 認証 | SPF/DKIM/DMARCがpassする |
| WordPressフォーム | 実送信→Zoho等の受信箱まで届く |
| 外部連携 | Search Console等の検証が維持される |
切替後はブラウザだけでなくdigでDNSを確認する
Webが表示されても、DNS移行が完全とは限りません。少なくともNS・MX・TXTを外部から確認し、メール用ホストを使う場合はA/AAAA/CNAMEも確認します。
| 確認 | 例 | 見ること |
|---|---|---|
| 権威DNS | dig NS example.com |
Cloudflare指定NSへ切り替わったか |
| メール配送先 | dig MX example.com |
Zoho等の正しいMXと優先度 |
| SPF/DMARC | dig TXT example.comdig TXT _dmarc.example.com |
旧DNSと同じ認証情報が引けるか |
| DNSSEC | dig DS example.com |
古いDSが残っていないか/再有効化後の値 |
CloudflareではMXとTXTは常にDNS-onlyです。さらにmail.example.comのようなメール専用A/AAAAを使う場合、そのホストもDNS-onlyにします。CloudflareのHTTPプロキシは通常SMTPを中継しないため、メール用ホストをオレンジ雲へするとメール障害の原因になります。
メールが止まった時に最初に見る場所
MXが旧値・空になっている
Cloudflare DNSのMXとメールプロバイダーの案内を比較します。Cloudflare公式のトラブルシューティングでも、MXの解決結果を確認して提供元の期待値と比較する流れが示されています。
mail.example.comがProxiedになっている
MXが自前のmailホストを指している場合、mailホストのA/AAAA/CNAMEがオレンジ雲になっていないか確認します。メール専用ホストはDNS onlyにします。
受信はできるが送信が迷惑メールへ入る
SPF・DKIM・DMARCの移し忘れ、SPF重複、DKIM selectorの誤りを確認します。MXは主に受信先、送信認証はTXT/CNAMEが関係するため、受信成功だけでメール設定完了とは言えません。
Cloudflare Email Routingと既存メールを混在させない
CloudflareにはEmail Routingがありますが、既にZoho MailやGoogle Workspace等でMXを使っているドメインに、意図せずCloudflare Email Routingを有効化するとMX競合の原因になります。Cloudflare公式もGoogle Workspaceの案内でEmail RoutingとGoogle側MXを同一ドメインで併用できないことを説明しています。
転送だけ欲しいのか、送受信可能なメールボックスが必要なのかを先に決めます。Zoho Mailを使うなら、ZohoのMXを正本としてCloudflareはDNS管理に徹する構成が分かりやすいです。
rollbackできるように旧状態を残す
旧ネームサーバー、旧DNSエクスポート、Cloudflare追加前の状態、変更時刻を記録します。問題が起きた時に「元に戻す」選択肢を持つことは大切ですが、ネームサーバーを往復させると反映時間がさらに複雑になります。まずCloudflare側の欠損レコードを直せるかを確認し、全体rollbackは最後の手段にします。
Web表示だけでなく、受信・送信・WordPressフォーム・SPF/DKIM/DMARC・主要サブドメインが全部正常であること。メールは翌日もう一度テストすると安心です。
公式情報・参考資料
仕様確認日：2026年10月1日。設定画面・料金・提供機能は変更されるため、実作業前にリンク先の最新版も確認してください。
- Cloudflare：Change your nameservers
- Cloudflare：Proxy status
- Cloudflare：Troubleshooting email issues
- Cloudflare：Set up email records
- Zoho Mail：SPFレコード
- Cloudflare：DNS移行前のTTL/DNSSEC準備
- Cloudflare：メールDNSのトラブルシュート
あわせて読みたい
まとめ
Cloudflare DNS移行でメールを止めないコツは、Webとメールを別系統として確認することです。全DNSを保存し、MX・SPF・DKIM・DMARC・認証レコードを先に再現し、DNSSECとproxy状態を確認してからネームサーバーを切り替えます。完了判定はサイト表示ではなく、実際の送受信とフォーム到達まで行ってください。
コメント