自社サイトのドメインを「制作会社に任せている」「毎年料金を払っている」だけでは、乗っ取りや更新漏れが起きたときに、誰が何を直せるかまでは分かりません。
最初に確認したいのは、登録会社、DNSの管理会社、Web・メールの運用会社と、それぞれの変更権限を持つ人です。この記事では、事業責任者やWeb担当者が、社内の技術担当者・委託先と一緒に点検できる順番に整理します。設定を変更する前に、管理画面と契約書を見ながら確認結果を残しましょう。
まず「どこで管理しているか」を3つに分ける
ドメインはWebサイトだけでなく、メールにも使われます。ひとつの変更が複数の業務に影響するため、サイト制作の契約先だけを把握して終わらせないことが大切です。
- 登録会社（レジストラ、JPドメインでは窓口となる指定事業者）：ドメインの登録・更新の窓口。利用するDNSの担当先であるネームサーバーも、ここで設定するのが一般的です。
- DNS管理：ドメイン名からWebサイトやメールの接続先を案内する設定を管理します。
- Web・メールの運用：サイトのプログラムやメールサービスそのものを動かします。Webとメールで別会社の場合もあります。
登録会社とDNS管理会社が同じでも、役割は分けて記録します。DNSは名前と接続先を結び付ける仕組みです。オーストラリア政府のドメイン管理者向け解説
これは管理分担を整理する図です。実際の通信はキャッシュやCDNなども経由しますが、点検ではまず「どの会社の、誰の管理画面で変更できるか」を押さえます。
会社名が分からない場合は、請求書・登録完了メール・制作契約から確認します。公開の登録情報も手がかりになりますが、非表示・代理公開があるため、それだけで契約者や管理責任者を断定しないでください。
1. 自社で契約と更新を確認できるか
委託先の担当者が交代しても、自社のドメインを維持できる状態にします。
- 登録者情報は、現在の会社・契約と一致しているか。
- 更新期限、自動更新、支払い方法の有効性を誰が確認するか。
- 更新失敗や登録情報の確認メールが、退職者の受信箱に届いていないか。
- 委託契約が終わる場合、管理権限・設定・記録をどう引き継ぐか。
「自動更新ON」を確認したら、次は更新が実際に完了したかを確認します。 例えばCloudflareも、決済失敗などで自動更新が成功しない場合があると説明しています。更新時期と再試行の扱いは登録会社によって異なります。Cloudflareのドメイン更新案内
委託先名義になっていた場合も、その場で登録情報を書き換えるのではなく、現在の契約と変更手順を確認してください。登録者情報の変更に伴う制限が設けられている場合があります。
2. ログインだけでなく「復旧の入口」も確認する
登録会社とDNS管理サービスの両方で、多要素認証、操作できる人、使われていない権限を点検します。多要素認証とは、パスワード以外の要素も使って本人確認する仕組みです。公的なドメイン保護ガイドでも、認証の強化とアクセス権限の制限が勧められています。ドメイン・DNSアカウントの保護
そのうえで、次の場面を想定して担当者に確認します。
「管理者のスマートフォンが壊れたら、誰がどう復旧しますか？」
復旧コードの保管責任者、予備の認証手段、サポートへ本人確認する手順を決めておけば、担当者が不在のときにも動けます。復旧コードや秘密鍵そのものを点検票・メールに貼る必要はありません。
もうひとつは、「自社ドメインのメールが止まっても連絡できますか？」です。同じドメインのメールだけに復旧を依存しているなら、サービスが認める別の連絡手段を用意できるか確認します。代替のメールアカウントも、会社が管理し、認証を保護する必要があります。
複数人で運用する場合は、サービスが対応していれば個別のアカウントと必要な権限を使います。委託先には作業範囲だけを渡し、退職・契約終了時の権限見直しを引き継ぎ項目にします。
3. 「ロック済み」が何を止めるのかを確かめる
ロックという名前だけでは、守られている範囲を判断できません。特に混同しやすいのが、登録会社の移管と、DNSにある接続先の変更です。
| 確認する保護 | 主に確認したい範囲 | 別途確認が必要なこと |
|---|---|---|
| 移管ロック | 別の登録会社への移管を制限するか | 同じ管理画面でのDNS変更を止めるとは限らない |
| レジストリロック | 登録情報・ネームサーバー等の変更に追加の制限がかかるか | 対応ドメイン、解除手順、費用、DNS側の設定保護 |
| DNS管理の権限制御 | 接続先の設定を誰が変更できるか | 管理画面だけでなくAPIなどの変更経路も対象か |
ICANNの状態コードでは、移管を止める「clientTransferProhibited」と、登録情報の更新を止める「clientUpdateProhibited」が別に定義されています。「移管ロックが有効だからDNSも安全」とは読み替えられません。ICANNの状態コード解説
レジストリは、.jpなどのドメイン群の登録情報を管理する組織です。JPRSのレジストリロックは、登録情報やネームサーバー設定などの変更を制限します。ただし取り扱いと提供範囲は指定事業者によって異なり、利用できない窓口もあります。JPRSのレジストリロック
海外サービスの一例では、CloudflareのCustom Domain ProtectionはEnterprise向けで、対応するドメインへのRegistry Lockや、変更時の別経路による本人確認を案内しています。すべての契約に標準で付くものではありません。Cloudflareの追加保護
レジストリ側でネームサーバーの指定を守っていても、指定先のDNSサービスでWebやメールの接続先を書き換えられれば、別の問題が残ります。 DNS側の権限も独立して点検しましょう。
問い合わせるときは、「ロックできますか」ではなく、次のように具体化します。
- 別会社への移管、登録者変更、ネームサーバー変更のうち、どれが止まるか。
- ロック解除時は誰を、どの連絡先・手段で確認するか。
- 夜間の緊急変更にどれくらい時間がかかるか。
- DNSレコードの変更を制限する機能は別にあるか。
追加保護は、停止したときの事業への影響と、普段の変更頻度を踏まえて検討します。
4. サイトが開くかと、設定が変わったかを分けて監視する
サイトが正常に表示されていても、メールの配送先だけが変わる可能性があります。逆に、表示の異常がすべてドメインの問題とは限りません。
担当者と相談し、主に次の変化を検知できるか確認します。
- 登録会社側：ネームサーバー、登録情報、ロック、管理者の変更。
- DNS側：Webの接続先（A・AAAA・CNAME）、メールの配送先（MX）など、重要な設定の変更。
- 利用者側：Webサイトへの到達と内容、メールの送受信の異常。
これは監視対象の整理例です。実際に通知・監査ログ・外部監視で何が分かるかはサービスによって異なります。通知先、最初に確認する人、不在時の連絡先まで決めると、検知後に止まりにくくなります。
変更前の正常な設定は、担当者が安全な場所へ記録しておきます。CDNなどが接続先を自動で変える構成では、変化をすべて異常扱いせず、予定された変更と区別する運用が必要です。
5. 不審な変更があったときの連絡先を先に決める
身に覚えのない移管・ネームサーバー変更通知や、偽サイトへの誘導を確認した場合は、通常の定期点検を待たず、登録会社・DNS管理会社と社内の対応責任者へ連絡します。ICANNも、不正な移管や登録者変更では登録会社へ速やかに相談するよう案内しています。ICANNの不正変更への案内
事前に決めておきたい初動は次の順です。状況に応じて並行して進めます。
- 対象と時刻を記録する。 対象ドメイン、異常を見た時刻、通知メール、画面、変更履歴を保存する。
- 契約済みの窓口へ連絡する。 登録会社とDNS管理会社を取り違えず、管理権限の保護、変更の停止、復旧を相談する。
- 利用者への影響を止める。 ログインや決済を控える案内、別の連絡手段への切り替えなどを責任者が判断する。
- 安全な状態から復旧する。 アカウント・認証情報・変更経路を確認し、正常なDNS設定へ戻したうえで、Webとメールを別々に確かめる。
DNSレコードやネームサーバーを一括で消すと、Webだけでなくメールなども止まります。自己判断で消して終わらせず、担当者・提供会社と影響を確認してください。また、設定を戻してもキャッシュの影響ですぐに全利用者へ反映されるとは限りません。
担当者と埋める「ドメイン点検票」
以下を社内文書へコピーして、まず主要なドメイン1つから埋めてみてください。これは管理用のひな形であり、認証情報の保管場所ではありません。
| 項目 | 記録すること |
|---|---|
| 対象と用途 | ドメイン名／Web・メール・認証などの用途 |
| 登録と更新 | 登録会社／登録者の確認結果／更新期限／支払い確認担当 |
| DNS管理 | DNSサービス／ネームサーバー／正常な設定記録の保管先 |
| 変更権限 | 自社責任者／委託先の作業範囲／多要素認証の確認結果 |
| ロック | 止められる変更／解除の承認者／問い合わせ先 |
| 復旧 | 認証手段を失ったときの手順／同じドメインに依存しない連絡手段 |
| 検知と初動 | 通知対象／受信担当／夜間連絡先／利用者への案内担当 |
| 次の対応 | 未確認事項／担当者／確認期限／最終点検日 |
最初から全欄を埋められなくても構いません。ただし、「分からない」を空欄にせず、誰にいつまでに聞くかを書きます。
例えば「登録会社とDNS会社は判明したが、退職した担当者にしか更新通知が届かない」なら、次の対応は会社の管理下にある連絡先への引き継ぎです。「移管ロックはあるがDNSの変更者が不明」なら、次はDNS管理の権限確認です。点検の成果は、チェックの数ではなく、次に誰が何を直すかが決まることです。
担当者・委託先・DNSサービスの変更時と、更新期限前には、この票を見直す機会を設けましょう。
情報確認日：2026年11月11日。画面名や保護機能、更新・復旧手順は提供会社とドメインの種類によって異なります。