Search Consoleの所有権確認で「v=spf1 include:_mailcust.gandi.net」が検出されたときに確認したこと

結論: 設定ミスではなく、レジストリのNS委任がまだ切り替わっていなかった

Route 53で新規取得した.jpドメインをGoogle Search Consoleにドメインプロパティとして登録しようとしたところ、所有権の確認が通らない。エラーはこうです。

ドメインの TXT レコードで確認トークンが見つかりませんでした。
代わりに検出された DNS TXT レコード:
v=spf1 include:_mailcust.gandi.net ?all

確認トークンのTXTレコードはRoute 53のホストゾーンに正しく追加済み。それでも「見つからない」と言われ、代わりに身に覚えのないGandiのSPFレコードが検出されています。実際のエラーダイアログがこちらです。

Search Consoleの所有権確認エラー。確認トークンが見つからず、代わりにv=spf1 include:_mailcust.gandi.net ?all が検出されたというダイアログ
正しく設定したはずなのに、見覚えのないGandiのSPFレコードだけが検出される

結論から書くと、これは設定ミスではありませんでした。Route 53は.jpを含む一部TLDの登録をレジストラパートナーのGandi経由で行っており、登録直後はJPレジストリ側のNS委任が一時的にGandiのパーキング用ネームサーバーを向いています。Googleが読んでいたのはそのパーキングゾーンで、v=spf1 include:_mailcust.gandi.netはパーキングゾーンに最初から入っているレコードです。委任がRoute 53のネームサーバー（awsdns）に切り替わるのを待って再確認したら、何も変更せずに通りました。

「自分の設定が正しいこと」を切り分けたdigコマンド3つ

待てば直るのか、設定が間違っているのかを見分けるには、3か所のDNSを見比べます。

# 1. 世界から見えているNS（パブリックリゾルバ）
dig +short NS example.jp @8.8.8.8
# → a.dns.gandi.net / b.dns.gandi.net / c.dns.gandi.net が返ってきた

# 2. Route 53の権威サーバーに直接聞く（自分の設定の確認）
dig +short TXT example.jp @ns-XXX.awsdns-XX.com
# → "google-site-verification=..." が正しく返ってきた

# 3. AWSに登録されているNS（あるべき姿の確認）
aws route53domains get-domain-detail --domain-name example.jp \
  --region us-east-1 --query "Nameservers[].Name"
# → ns-XXX.awsdns-XX.com など、Route 53のNSが返ってきた

この3つの結果を並べると状況がはっきりします。自分のゾーン（2）とAWSの登録情報（3）は正しいのに、世界（1）だけがまだ古いGandiのNSを見ている。つまり直すものは何もなく、レジストリの反映を待つだけだと確定できます。

逆に、2でトークンが返ってこなければRoute 53側の設定ミス、3がGandiのNSのままなら委任の更新自体が行われていないので、待っても解決しません。切り分けの価値はここにあります。

巻き添えを食う作業がもう1つある: Let’s Encryptの証明書取得

同じ理由で、certbotによるSSL証明書の取得もこの間は失敗します。Let’s Encryptの検証はレジストリから権威サーバーを辿るため、委任がパーキングNSを向いている間はHTTP-01チャレンジがGandiのパーキングIPに飛んでしまうからです。

当社の作業では、証明書取得を自動リトライさせる前に「委任先にawsdnsが現れたら実行する」という条件を挟みました。

# JPレジストリの権威サーバーに直接聞き、awsdnsに切り替わるまで待つ
dig +short NS example.jp @a.dns.jp | grep -c awsdns

パブリックリゾルバ（8.8.8.8）を監視条件にすると、パーキングIPがキャッシュされている間は誤判定するので、レジストリの権威サーバー（.jpならa.dns.jp）に直接聞くのが確実です。

まとめ: 新規ドメイン取得直後の30分は、DNSを信じない

ドメインを取ったらすぐSearch Console登録・SSL化・サイト公開まで一気にやりたくなりますが、レジストリの委任反映が終わるまでは、TXT確認も証明書取得も「正しく設定したのに失敗する」状態になります。当社のケースでは、AWSからの登録完了メールの後、しばらくしてから委任が切り替わりました。

失敗しても設定を疑って作り直す前に、まずdig +short NS ドメイン名 @8.8.8.8を1本。返ってきたNSが自分のゾーンのものになっているか——それだけで「待つべきか、直すべきか」が判断できます。