ドメインを所有していることを証明する方法、その依頼元がKapsuleHostであれGoogleであれMicrosoftであれ他の誰であれ、そしてKPanelでレコードを追加する方法について説明します。
遅かれ早かれ、何らかのサービスが「ドメインの所有を証明するまでは処理できません」と言ってくるものです。その証明方法はほとんど常に同じ形をしています。相手から文字列を渡され、それをDNSレコードとして公開し、相手がそれを検索します。それが確認できれば、あなたがそのドメインを確かに管理していることになります。なぜなら、そのドメインのDNSを公開できるのは所有者だけだからです。
本ガイドでは、KapsuleHostが求めるレコード、他のサービスが求めるレコード、そしてそのいずれかを追加する方法について説明します。
DNSエディタの場所
サイドバーのドメインをクリックしてドメインを選択し、左メニューのDNSとネームサーバーをクリックします。これが完全なレコードエディタであり、レコードの追加や変更ができるのはここだけです。
サイト配下(Websites、該当サイト、Domain、DNS)にあるDNSビューは読み取り専用です。公開中の内容が表示され、完全なエディタへのリンクも用意されています。追加ボタンを探しても見つからない場合は、読み取り専用のビューを見ていることになります。
このエディタは、DNSがKapsuleHostでホストされているドメインに対してのみ機能します。ドメインがここで登録されていても、そのネームサーバーが別の場所を指している場合は、実際にDNSが存在する場所でレコードを公開する必要があります。Nameserversをご覧ください。
KapsuleHost独自の確認レコード
KapsuleHostが確認レコードを求めるのは、ある一つの状況のみです。それは、DNSを弊社が運用していないドメインにメールボックスを追加しようとしている場合です。
ドメインが弊社に登録されている場合、またはそのDNSが弊社でホストされている場合、弊社はすでに所有権を確認できているため、何もお願いする必要はありません。DNSが他の場所にある場合はそれができないため、そのドメイン宛のメールを受け付ける前に所有権の証明をお願いしています。
レコード
| 項目 | 値 |
|---|---|
| 種類 | TXT |
| 名前 | _kapsule-verify.yourdomain.com |
| 値 | kapsule-verify=の後にパネルに表示されるトークンを付加したもの |
このトークンはお客様のアカウント用に生成され、パネル上に表示されます。名前と値の両方は、再入力せずにコピー用ボタンを使ってコピーしてください。
手順
- KPanelでメールボックスまたはドメインを開き、Deliverabilityセクションに移動します。
- ドメイン確認用のカードを探します。レコード名と値、そしてステータスバッジが表示されています。
- そのTXTレコードを、DNSがホストされている場所に公開します。
- 1、2分待ちます。
- 戻って確認ボタンをクリックします。
このチェックは弊社独自の仕組みではなく、公開されているリゾルバに対してリアルタイムで行われるため、表示される結果はインターネット上の他の誰から見ても同じものです。つまり回答は正確ですが、公開直後の1、2分はキャッシュが追いつかず失敗することもあります。
確認に失敗しても、すぐにレコードが間違っていると判断しないでください。最も多い原因は、レコードが反映される前に確認ボタンをクリックしてしまったことです。2分待ってから再度試してください。次に多い原因は、DNSホストがすでにドメイン名を含んでいる名前に、さらにドメイン名を自動で追加してしまい、_kapsule-verify.yourdomain.com.yourdomain.comのようになってしまうことです。レコードが実際にどのように解決されるかを確認してください。
その後
確認が完了すると、そのドメインは所有者として記録され、その状態が維持されます。ゾーンをすっきりさせたい場合はTXTレコードを削除しても構いません。何も問題は起きません。
一つ注意点があります。そのドメインについて確認作業をやり直す場合、新しいトークンが発行され、以前公開していた値は無効になります。そのため、レコードを削除した後に再度確認を求められた場合は、以前の値を再利用せず、パネルから最新の値をコピーしてください。
他サービス向けの確認レコード
その他の確認レコードもすべて同じ仕組みで動作します。サービス側から値が提示され、それをDNSタブに追加し、戻ってそのサービスの確認ボタンをクリックします。
よくあるものは次のとおりです。
| サービス | 種類 | 一般的な名前 | 値の例 |
|---|---|---|---|
| Google Search Console | TXT | ベアドメイン | google-site-verification=... |
| Microsoft 365 | TXT | ベアドメイン | MS=ms... |
| Meta business domains | TXT | ベアドメイン | facebook-domain-verification=... |
| 各種SaaSツール | TXTまたはCNAME | _somethingサブドメイン | ランダムなトークン |
追加方法
- ドメインに移動し、ドメインをクリックしてからDNSを開きます。
- レコードを追加します。
- 種類を設定します。通常はTXTです。
- 名前欄には、サービス側がベアドメインまたはルートに設定するよう指示している場合は
@を入力します。サブドメインを求められている場合は、_dnsauthのようにラベルのみを入力します。ラベルにドメイン名を含めないでください。 - 値は提示されたとおりに正確に貼り付けてください。自分で引用符を追加したり、末尾にスペースを入れたりしないでください。
- 保存し、数分待ってから、相手サービス側で確認ボタンをクリックします。
エディタが代わりに処理してくれる、よくあるトラブルを避けられる3つのポイントです。
- 長い値でも問題ありません。 単一のDNS文字列の255文字制限を超える確認トークンも、正しく分割されます。
- 引用符の処理も自動です。 値はそのまま貼り付けてください。自分で引用符を付け加える必要はありません。
- 同じ名前の複数のTXTレコードは共存できます。 ベアドメイン上のGoogle確認レコードが、そこにあるSPFレコードを置き換えることはありません。両方とも公開され、両方とも検出されます。これはほかの多くのレコード種別の挙動とは異なるため、よくつまずくポイントです。
既存のSPF、DKIM、DMARCのレコードを確認トークンで置き換えないでください。それらは異なる名前に存在するか、同じ名前に並んで存在します。あるサービスが「TXTレコードを置き換えてください」と指示してきた場合、それはそのサービスが以前に発行したレコードを置き換えるという意味であり、メール認証を担うレコードのことではありません。SPF, DKIM and DMARCをご覧ください。
そのままにしておくべきレコード
DNSエディタを操作していると、自分で作成した覚えのないレコードに気づくことがあります。
_acme-challengeのTXTレコードは、証明書の発行や更新時に自動的に作成・削除されます。手動で削除しないでください。発行後に残ったままでも害はありません。SSL Certificatesをご覧ください。_dmarcと_domainkeyのレコードはメール認証を担っています。これらを削除すると、確認処理ではなくメールの到達率が損なわれます。SPF, DKIM and DMARCをご覧ください。- ドメイン自体のSOAレコードとNSレコードは、ゾーンそのものの基盤部分です。
エディタが対応しているレコードの種類
種類のドロップダウンでは、A、AAAA、CNAME、MX、TXT、NS、SRV、CAAが選択できます。優先度フィールドはMXとSRVの場合にのみ表示されます。これらはこの項目を使う唯一の2種類だからです。
サービス側から一覧にないレコード種別を求められた場合は、別のもので代用しようとせず、サポートチケットを開いてください。Opening a Support Ticketをご覧ください。
反映にかかる時間
変更は弊社のネームサーバー上ではほぼ即座に反映されます。レコードが書き込まれると同時に、弊社の他のネームサーバーにも即座に通知が送られます。エディタではTTLの設定を求められることはないため、その点を気にする必要はありません。
実際に待つことになるのは、他者のキャッシュです。すでにその名前を検索したことのあるリゾルバは、キャッシュされた回答の有効期限が切れるまで古い回答を返し続けます。実際には、確認チェックは通常1、2分以内に成功しますが、まれにそれ以上かかることもあります。
1時間経ってもサービス側がレコードを認識できない場合は、レコード自体が間違っています。まずは名前を確認してください。ラベル内でドメインの接尾辞が重複していることが、圧倒的に多い間違いです。