所有権をどう証明するか
「このサイトはあなたのものですね」を、Googleはどうやって確かめているのか。
Search Consoleにサイトを登録すると、所有権の証明を求められます。方法は5つ提示されますが、それぞれ証明している中身が違います。同じ「所有権」という言葉でくくられているせいで、そこが見えにくくなっています。
5つの確認方法が何を根拠にしているか、DNSのTXTレコードだけが別格である理由、ドメインプロパティでDNS確認しか認められていない理由。そして実際に登録するときの注意点。
5つの方法は、証明の強さが違う
Search Consoleが提示する確認方法を、「何ができる人だと証明しているか」で並べ替えるとこうなります。
| 方法 | 証明していること |
|---|---|
| Googleアナリティクス | そのGA4プロパティを編集できる |
| Googleタグマネージャー | そのGTMコンテナを編集できる |
| HTMLタグ | そのページのHTMLを書き換えられる |
| HTMLファイル | そのサーバーにファイルを置ける |
| DNSレコード | そのドメインそのものを支配している |
上の4つは、いずれも「サイトの中身に手が届く」ことしか示していません。制作を請け負っている人でも、CMSの編集権限を持っている人でも通せます。
DNSだけが違います。DNSレコードを書き換えられるということは、そのドメインをどのサーバーに向けるかを決められるということです。極端に言えば、サイトの中身を丸ごと別の場所に差し替えられます。所有者でなければ持てない権限です。
Search Consoleのドメインプロパティは、www の有無もサブドメインもすべてまとめて扱います。cms.kisaku.site のような、まだ存在しないサブドメインまで対象に含みます。まだ無いサブドメインにファイルは置けません。だから「ドメイン全体の持ち主である」ことを、上の階層で一度に証明する必要があります。それができるのはDNSだけです。
TXTレコードとは何か
DNSは本来、名前をIPアドレスに変えるための仕組みです。レコードには種類があります。
| 種類 | 用途 |
|---|---|
| A / AAAA | 名前をIPアドレスに変換する |
| CNAME | 名前を別の名前に転送する |
| MX | メールの宛先サーバーを示す |
| NS | このドメインを管理するサーバーを示す |
| TXT | 任意の文字列を置ける（用途は決まっていない） |
TXTだけが異質です。「好きな文字を書いておける場所」として定義されていて、何に使うかは決められていません。
この自由さが、あとから来た用途に次々と使われました。所有権の証明もそのひとつです。SPF（メールの送信元認証）も、DKIMも、TXTレコードの上に成り立っています。
ホスト名 （空欄。管理画面によっては @ と表示される）
種別 TXT
値 google-site-verification=（発行された文字列）
TTL 既定のままホスト名を空欄にするのは、ドメインそのもの（kisaku.site）に対して置くという意味です。ここに www と入れると www.kisaku.site のレコードになり、ドメインプロパティの確認には使えません。
なぜこれで証明になるのか
仕組みは単純です。
1. Googleが、あなた専用のランダムな文字列を発行する
2. あなたが、その文字列を kisaku.site のTXTに登録する
3. Googleが、世界中から見えるDNSに問い合わせる
4. 発行した文字列が返ってくれば、確認完了ポイントは3番です。GoogleはあなたのサーバーやCMSを見に行っていません。公開されているDNSに問い合わせているだけです。
そしてDNSの内容を書き換えられるのは、ドメインを管理している人だけです。第三者があなたのドメインのTXTレコードに勝手な値を入れることはできません。「書き換えられた」という事実そのものが証明になっているわけです。
この方式のうまさは、Googleに何の権限も渡していないことです。サーバーのログイン情報も、CMSの管理権限も渡していません。「あなたにしかできない操作を実際にやってみせる」だけで済んでいます。所有権の証明としては、これがいちばん筋の通った形です。
反映を自分で確かめる
DNSの変更は、登録した瞬間に世界中へ伝わるわけではありません。管理画面で保存したあと、実際に公開されるまでに時間がかかります。
「確認」を押して失敗したとき、原因が登録内容の間違いなのかまだ反映されていないだけなのかは、画面からは分かりません。ここで待ち続けるか設定を疑うかを間違えると、時間を大きく無駄にします。
自分で問い合わせれば、すぐに区別できます。
dig kisaku.site TXT +short
"v=spf1 include:spf21.gmoserver.jp ~all"
"google-site-verification=..."ブラウザだけでも確認できます。https://dns.google/resolve?name=kisaku.site&type=TXT を開くと、Googleのリゾルバが見ている内容がJSONで返ってきます。Googleが実際に何を見ているかを、Googleに聞くので、Search Consoleの判定と食い違いません。
実際、私は1回目の「確認」で失敗しました。設定を疑う前にDNSへ直接問い合わせたところ、返ってきたのはSPFの1件だけで、確認用の文字列はまだ公開されていませんでした。失敗の原因が「間違い」ではなく「待ち」だと分かったので、設定をいじり回さずに済みました。
保存できたのに、公開されない
ここからは、実際に私がはまった話です。
管理画面でTXTレコードを追加し、「保存しました」と表示されました。ところが何時間経っても、DNSに問い合わせると返ってくるのはSPFの1件だけ。TTLは600秒——10分です。10分待てば消えるはずのキャッシュを、何時間も疑っていました。
原因は、編集していた管理画面が、そのドメインの答えを持っていなかったことでした。
ドメインの管理画面は、1つとは限らない
ドメインを買った会社と、そのドメインの問い合わせに実際に答えるサーバーは、別々にできます。どちらが答えるかを決めているのがNSレコードです。
dig kisaku.site NS +short
dns01.gmoserver.jp.
dns02.gmoserver.jp.返ってきたのはレンタルサーバー側のDNSでした。ドメインを買った会社の管理画面ではありません。
| できること | 今回の状態 | |
|---|---|---|
| ドメイン登録側の管理画面 | NSレコードを決める | ここを編集していた |
| NSが指しているDNS | 実際の答えを返す | こちらが本番だった |
権限のない側の画面に書いた設定は、エラーにならずに保存され、そして誰にも参照されません。これが厄介なところです。間違いを教えてくれる仕組みが、どこにもありません。
管理画面の保存成功は、その画面のデータベースに書けたことしか意味しません。それが世界から参照されるかどうかは別の話です。DNSに限らず、設定が複数の場所に分かれている仕組みでは同じことが起こります。
先に、答えている場所を特定する
この失敗を避ける手順は単純です。レコードを追加する前に、NSを引く。
# 誰が答えるか
dig kisaku.site NS +short
# ブラウザだけでも見られる
https://dns.google/resolve?name=kisaku.site&type=NS返ってきたサーバー名で、どこの管理画面を開けばいいかが分かります。*.gmoserver.jp ならレンタルサーバーのコントロールパネル、*.vercel-dns.com ならVercel、*.cloudflare.com ならCloudflareです。
正しい画面かどうかは、開いた瞬間に判断できます。すでに動いているレコードが並んでいる画面が本番です。今回で言えば、AレコードとSPFとサブドメインのCNAMEが揃っている画面。逆に、実際のサイトが動いているのに空っぽの一覧が表示されたら、そこは参照されていない画面です。
既存のレコードを消さない
DNSの編集で、いちばん怖いのはこれです。
TXTレコードには、すでにSPF（メールの送信元認証）が入っていることがよくあります。これを消すと、送ったメールが迷惑メール扱いされるようになります。サイトの表示には何の影響もないので、しばらく気づきません。
「TXTはひとつしか置けない」と誤解して、既存のSPFを上書きしてしまう事故が起きます。同じホスト名に複数のTXTレコードを共存させられます。追加するのは1行だけで、既存の行はそのまま残します。
もっと危険なのはAレコードやCNAMEです。ここを触るとサイト全体が見えなくなります。DNSは、間違えたときの影響がサイト全体に及ぶ数少ない設定です。作業前に現在の内容を控えておくと、戻せます。
今回の学び
まず、同じ「所有権の証明」でも、証明している中身が違うということ。ファイルやHTMLタグは「中身に手が届く」ことしか示しません。DNSだけが「ドメインの持ち主である」ことを示します。選択肢が並んでいると同じものに見えますが、強さが違います。
次に、TXTレコードは「用途が決まっていない」から使われていること。所有権の証明もSPFも、DNSの設計時には想定されていない用途です。汎用の置き場所をひとつ用意しておいたことが、後から効いています。
そして、失敗したときは「間違い」か「待ち」かを先に切り分けること。DNSは反映に時間がかかる仕組みなので、この2つが同じ見た目になります。切り分けずに設定をいじると、正しかったものまで壊します。
さらに、「保存できた」は「効いている」ではないこと。今回いちばん時間を取られたのは、参照されていない管理画面に正しい値を書き続けていたことでした。書き込む前にNSを引いて、答えている場所を先に特定する。これだけで防げます。
最後に、影響範囲の広い設定ほど、触る前に控えを取ること。DNSは間違いがサイト全体に及びます。しかもメール側の不具合は、しばらく誰も気づきません。