XServerドメイン × Cloudflare DNS × Google Workspace

セカンドドメイン追加時に発生した認証トラブルと解決までの記録

エックスサーバー株式会社で新規取得した .jp ドメインを、Google Workspace にセカンドドメインとして追加しようとした際、カスタムドメインの所有権確認で約24時間パスできない事象が発生しました。

原因はDNSレコード設定の不整合でした。

発生した問題の概要

ドメイン取得直後に Cloudflare へネームサーバーを切り替え（オンボード）したことで、XServer側の既存ネームサーバー情報が適切に整理されないまま、Cloudflare上には最低限のレコードのみが存在する状態になっていました。

その結果、Google Workspaceの所有権確認が正常に完了せず、認証が通らない状態が続きました。

DNSの権威がどこにあるのか、どのレコードが実際に参照されているのかが曖昧になっていたことが本質的な原因でした。

XServerでCloudflareを利用する正しい設定手順

XServerで取得したドメインをCloudflareにオンボードする場合、ネームサーバー設定で「その他のサービスで利用する」を選択し、Cloudflareが指定するネームサーバーを入力する必要があります。

例：

ネームサーバー1

mallory.ns.cloudflare.com

ネームサーバー2

patryk.ns.cloudflare.com

この設定を行わずにCloudflare側のみでDNSを構成すると、想定外の状態になる可能性があります。

Google Workspace所有権認証で重要だったDNSレコード

Google Workspaceがドメイン所有を正しく認識するためには、TXTレコードだけでなく、NSレコードの整合性も重要でした。

Cloudflare側に以下のレコードを追加したところ、所有権認証が即時通過しました。

NS

ns1.xdomain.ne.jp

NS

ns2.xdomain.ne.jp

NS

ns3.xdomain.ne.jp

TXT

"google-site-verification=XXXX"

上記が反映された状態で再度認証を行うと、自動的に次のステップへ進むことができました。

Gmail利用に必要なMXレコード

Google WorkspaceでGmailを使用する場合、MXレコードの追加が必要です。

MX

smtp.google.com

実際の本番環境では、Google指定の優先度付きMXレコードを複数設定することが推奨されます。

最終的にCloudflare側に存在したDNSレコード

最終的に必要だったのは以下の5レコードでした。

NS × 3

TXT（Google認証用）

MX（Googleメール用）

これらが正しく設定されていれば、Google Workspaceでのメール利用は問題なく開始できます。

今回の学び

ドメイン取得直後のネームサーバー変更は、DNS構成を崩しやすい

Google Workspaceの所有権認証はTXTレコードだけでなく、ネームサーバー構成も影響する場合がある

XServer × Cloudflare × Google Workspace構成では、DNSの責任範囲を明確にすることが重要

DNSトラブルの切り分けでは、次の3点を必ず確認するべきです。

権威DNSはどこか

どのレコードが実際に有効か

伝播状況はどうか

DNSは「設定したつもり」と「実際に参照されている状態」が一致していないと、解決までに時間がかかります。

構成変更時は、必ず全体像を把握してから作業することを強くおすすめします。