ドメイン更新したのに繋がらない｜原因5つと待ち時間

ドメインの更新料は支払った。更新完了のメールも受け取っている。それなのにサイトを開くと「このサイトにアクセスできません」のままで、何時間待っても画面が変わらない。管理画面の有効期限は来年の日付になっているのに、表に出ている顔だけが止まっている状態です。

この記事は、その「支払いも手続きも終わっているのに直らない」場面だけを扱います。うっかり期限を切らしてサイトごと消えてしまい、まだ取り戻せるのかを知りたい場合は、ドメイン更新忘れでサイトが消えたときの復旧期限のほうが近い話です。ここでは、更新が済んだ後に残っている詰まりを、どこから順に確かめてほどくかだけを書きます。

結論

更新したのに繋がらない原因は、①更新は通ったが反映待ち ②Whois情報の認証が終わっておらずドメインが停止している ③ネームサーバーやDNSレコードの向き先が違う ④サーバー契約かSSL証明書が別に切れている ⑤手元のキャッシュが古いの5つにほぼ収まります。このうち自分の操作だけでは動かせないのは②だけで、残りは今日のうちに切り分けられます。

いちばん多い誤解は「何時間か経てば必ず直る」という前提です。レジストリへの反映自体は速く、JPドメイン名の各種申請は受理後15分程度でレジストリのDNSへ反映されると案内されています。それでも手元の表示が変わらないのは、途中にあるキャッシュDNSが古い答えを持ち続けているからで、保持時間はレコードごとのTTLで決まります。だから「何時間で直る」と一律には言えず、同じ瞬間でも人によって見え方が違います。

もうひとつ先に書いておきます。Webが表示された時点で復旧完了だと判断しないでください。Mihata は自社のDNS移行で、サイトは正常に見えているのにメール認証のレコードだけが引き継がれていない状態を1週間気づかずに走らせました。詳しくは後半の節に書きます。

「いま画面に出ているもの」で原因を分ける

同じ「繋がらない」でも、ブラウザに何が出ているかで原因はかなり絞れます。焦って更新手続きをもう一度やる前に、まず画面の文字列を読んでください。対応表は次のとおりです。

「アクセスできません」とNXDOMAINは同じことを言っている

Chrome に出る DNS_PROBE_FINISHED_NXDOMAIN の NXDOMAIN は、DNS用語を定義した RFC 8499 で「問い合わせで参照されたドメイン名が存在しない」ことを示す応答と説明されています。サーバーが落ちているのではなく、名前そのものが無いと返ってきている状態です。

ここが重要なところで、更新が完了していてもこの応答は出ます。停止措置が付いたままの場合と、失効中に返された「存在しない」という答えが途中に残っている場合の両方があるからです。エラーの文字列だけでは、この2つは区別できません。

レジストラの販売ページが出るとき

自社のサイトではなく、ドメイン登録会社の広告ページや「このドメインは販売中です」といった画面が出ることがあります。これは名前解決が成功している証拠なので、ドメイン自体は生きています。向き先がレジストラ側の仮の場所になっているだけです。

失効中は多くの登録会社が自動でこの向き先に差し替えます。更新後も自動では戻らない設定になっていることがあり、その場合は管理画面でネームサーバーを自社のサーバーへ入れ直す作業が必要です。手続き上は「更新済み」でも、向き先は別の設定だと考えてください。

証明書の警告が出るとき

「この接続ではプライバシーが保護されません」が出ているなら、DNSは正しく引けていて、サーバーにも届いています。残っている問題は証明書だけです。ドメインとサーバーとSSLは別々の契約なので、ドメインを更新しても証明書は自動では延びません。

警告の消し方と、消す前にやってはいけないことは保護されていない通信と出るときの直し方にまとめています。ここまで来ていれば復旧は目前です。

旧サイトや別のサイトが出るとき

移転と更新が重なった直後に多いのがこれです。エックスサーバーの公式FAQは、ネームサーバーの変更中について「移転元・移転先のどちらのサーバーに繋がるか予測できない期間が発生します」と明記しています。人によって新旧どちらが見えるかが違うのは、異常ではなく途中経過です。

この状態で設定を何度も変えると、どの変更が効いたのか分からなくなります。後述の手順で権威側の答えを見て、正しければ触らずに待ってください。

原因1：更新は通っているが、反映を待っている

ドメインの更新が登録簿に届いてから、世界中の人が新しい状態で見られるようになるまでには段差があります。レジストリ側は速い一方で、途中のキャッシュDNSは前回の答えを持ち越します。この保持時間が TTL で、JPRSの用語辞典では「リソースレコードをキャッシュに保持してもよい時間を秒単位で示す」値と定義されています。

実際の値はサービスによって固定されていることがあります。たとえば JPDirect のDNSサービスはTTLが10800秒（＝3時間）で固定され、個別の変更は受けられないと案内されています。つまりその環境では、条件が悪ければ3時間は古い答えを見る人が残ります。

さらに厄介なのがネガティブキャッシュです。DNSは「存在する」という答えだけでなく「存在しない」という答えもキャッシュします。RFC 2308 はこの否定応答の保持時間について「1時間から3時間の値がうまく機能することが分かっており、既定値として妥当」「1日を超える値は問題があることが分かっている」と書いています。失効していた間にアクセスした人のキャッシュには、この「存在しない」が残ります。

ここから導けることは1つです。失効から復旧したドメインは、更新した瞬間に全員が見られるようにはならない。自分の端末で直っていなくても、それはまだ失敗ではありません。

JPドメインには更新が止まる時間帯がある

深夜に作業した人が引っかかる点です。JPドメイン名の申請について、公式の案内は「午前3時〜午前5時の間は原則としてJP DNSの更新が停止となり、午前5時以降に申請内容が順次反映されます」と説明しています。

深夜2時に手続きをして、3時に「まだ直らない」と何度も設定を変えるのがいちばん損です。その時間帯はそもそも動いていません。朝まで待ってから確認してください。

原因2：Whois情報の認証が終わっておらず、ドメインが止められている

更新料を払ったのに繋がらないケースで、いちばん見落とされるのがこれです。更新の支払いとはまったく別に、登録者のメールアドレスが有効かどうかを確認する手続きがあり、これを放置するとドメインが停止されます。

根拠は ICANN の登録機関向け契約です。2013年版 RAA の Whois Accuracy Program Specification は、登録者から15暦日以内に有効な応答が得られない場合、登録機関は連絡先を手作業で検証するか、登録を停止する（suspend）か、clientHold および clientTransferProhibited を設定すると定めています。同じ文書の登録者向けの権利と責任の項にも「登録機関からの問い合わせには15日以内に応答しなければならない」と書かれています。

この clientHold が何をするかは、ICANN の EPP ステータスコードの解説が端的です。「このステータスコードは、ドメインをDNSで有効化しないようレジストリに指示するもので、結果としてドメインは名前解決しない」とあります。有効期限がいくら先でも、このフラグが付いている限りサイトもメールも動きません。

日本の登録会社では「2週間・336時間」と案内されている

日本語での一次情報もあります。お名前.comのドメイン情報認証についての告知は、認証メールを受け取ってから2週間以内（336時間）に手続きをするよう求め、期限内に行われない場合は「ドメインの利用制限が行われ、該当のドメインを利用したホームページの閲覧や、メールの送受信ができなくなります」と明記しています。

復旧側の記述も具体的です。同じ告知には「利用制限された場合でも、認証手続きを行うことで数時間〜最大72時間程度で復旧します」「利用制限中もWhois情報の変更等、各種手続きは可能」とあります。つまり、認証を終えた日に直らなくても異常ではありません。

対象になる手続きは、ドメインの新規登録・登録者情報や名義の変更・他社からの移管です。更新そのものではないのに、更新の前後に住所や担当者を直した人がここに引っかかります。認証メールは登録者情報に書かれたメールアドレス宛に届くので、そのアドレスが退職者のものだと誰も気づけません。

停止されているかどうかの見分け方

whois の結果に clientHold や serverHold が出ていれば、それが答えです。この場合、DNSの設定をいくら直しても表示は戻りません。登録会社の管理画面にログインし、未認証のドメイン一覧や認証メールの再送をたどってください。

なお、期限切れの側の状態表示もここで分かります。ICANN の期限切れ登録回復ポリシー（ERRP）は、削除後に30日の Redemption Grace Period を設けると定めており、この期間中はレジストリがDNSの名前解決を無効にすると書かれています。ここに入っているなら、更新ではなく復旧の手続きが必要です。

原因3：ネームサーバーやDNSレコードが別の場所を向いている

ドメインの契約と、そのドメインがどこを指すかの設定は別物です。更新は「契約を延ばす操作」でしかないので、向き先がずれていれば更新しても直りません。移管やサーバー移転と時期が重なったときに起きます。

ネームサーバーを変えた場合の待ち時間は、エックスサーバーの公式FAQが「数時間〜最大24時間程度で徐々に反映します」と案内し、丸1日ほど様子を見たうえでサイトとメールの両方を確認するよう勧めています。徐々に、という表現のとおり、切り替わる瞬間は全員同時には来ません。

確認すべきは3段です。第一に、レジストラ側に登録されているネームサーバーが意図した2台以上になっているか。第二に、そのネームサーバー上にAレコードやCNAMEが正しく入っているか。第三に、手元がその答えを受け取れているか。この3つのどこで止まっているかを分けずに設定を触ると、必ず遠回りになります。

制作会社に任せていて管理画面に入れない、そもそもどこで契約したか分からないという状態なら、先にその整理が必要です。たどり方はドメインとサーバーの管理者が分からないときの調べ方に手順で書いています。連絡がつかない相手が握っている場合は制作会社と連絡が取れなくなったサイトの取り戻し方のほうが実情に近いはずです。

原因4：サーバー契約やSSL証明書が別に切れている

ドメイン・サーバー・SSLは、同じ会社で買っていても別々の契約です。ドメインだけ自動更新にしていて、サーバーの支払いに使ったクレジットカードの有効期限が切れている、というのは実務でよく見ます。この場合、名前は引けるのに中身が出ません。

見分け方は単純で、ブラウザに出るのが「名前が見つからない」系ならDNS側、「タイムアウト」や証明書の警告ならサーバー側です。サーバー会社の管理画面にログインできるなら、契約状態と請求の履歴を先に見てください。

工事中の画面が出たまま戻らないという別パターンもあります。その切り分けはメンテナンス表示のまま戻らないサイトの直し方に分けて書きました。

ここまでの作業は、管理画面さえ開ければご自身でも進められます。Mihata はホームページ制作をしていて、こうしたドメインとサーバーの整理もあわせて引き受けています。記事の途中で恐縮ですが、社内に触れる人がいないまま止まっているようでしたら、よろしければ見てみてください。

原因5：手元のキャッシュだけが古い

ここまで全部正しいのに自分だけ繋がらない、という場合は端末側です。OSのリゾルバーキャッシュや、ブラウザ・社内DNSが古い答えを持ち続けています。特に失効を経験したドメインは、前述のネガティブキャッシュが効いて「存在しない」が残ります。

macOS の場合、Apple の公式手順では OS X Yosemite v10.10.4 以降で sudo killall -HUP mDNSResponder を使うと案内されています。Windows は Microsoft のコマンドリファレンスにあるとおり ipconfig /flushdns で、この操作は「キャッシュから負のキャッシュ エントリと、動的に追加されたその他のエントリを破棄できます」と説明されています。否定の答えを捨てられると明記されている点が、まさに今回効くところです。

社内に自前のDNSやプロキシがある会社では、端末を掃除しても社内側が古いままのことがあります。その場合は情報システム担当に、対象ドメインのキャッシュ破棄を依頼してください。

どこまで直っているかを順に確認する

「直った／直らない」を画面の見た目だけで判断すると、必ず混乱します。ドメインの状態・権威側の答え・手元の答えを分けて見てください。使うものと分かることを並べます。

権威に直接聞くと、待ち時間を切り分けられる

いちばん使えるのは、権威サーバーを名指しして聞く dig example.jp A @ns1.example.net の形です。これはキャッシュを経由しないので、設定した内容が本当に入っているかだけを確かめられます。ここが正しくて手元が違うなら、残りは待ち時間の問題だと確定できます。

Windows で dig が無ければ nslookup でも代わりになります。nslookup example.jp ns1.example.net のように末尾へ問い合わせ先を付けるだけです。大事なのは、権威に聞いた答えと手元の答えを分けて見ることです。

回線を変えるのがいちばん速い切り分け

コマンドに慣れていない人向けの最短手段がこれです。社内Wi-Fiで繋がらないページを、スマートフォンのモバイル回線で開いてみてください。回線を変えて見えるなら、ドメインは直っていて、残っているのは経路上のキャッシュだけです。

逆に、どの回線から見ても同じエラーなら、原因は手元ではなくドメイン側です。原因2のステータス確認へ戻ってください。この一手間で、直っているものを壊しに行く事故がかなり防げます。

ドメインは直ったのに、メールだけ戻らない

ここが、この記事でいちばんお伝えしたい部分です。サイトが表示されたことは、DNSの設定が全部戻った証明にはなりません。WebはAレコードやCNAMEだけで動きますが、メールはMXレコードに加えて、SPF・DKIM・DMARCといった認証用のTXTレコードが別に必要だからです。移行や再設定で引き継がれるのは、たいてい表示に関わるレコードだけです。

Mihata 自身がこれで失敗しています。2026年8月19日にDNSを移した際、サイトは問題なく表示され、当日は「移行完了」と判断しました。実際にはドメイン直下のSPFレコードと、Google Workspace のDKIM用レコードである google._domainkey が移行先に引き継がれていませんでした。気づいたのは1週間後の8月26日で、そこから SPF・DKIM・DMARC・送信用サブドメインのSPF・そのサブドメイン用のDKIM の計5点をそろえ直しています。

やっかいなのは、この間まったく症状が出なかったことです。メールは送れましたし、エラーも返りません。受け取る側で迷惑メール判定されやすくなるだけなので、社内では最後まで気づけません。気づくとしたら、先方から「メールが届いていない」と言われたときです。

そして、直しても即座には効きません。Google Workspace の公式ヘルプは、SPFの設定手順で「SPF 認証が機能し始めるまでには、最長で 48 時間ほどかかることがあります」と案内しています。DKIMの設定手順でも、レコード名の例として google._domainkey が示され、追加後も管理コンソールの表示が最長48時間ほど更新されないことがあると書かれています。

したがって、DNSを触った日の確認項目はこうなります。①サイトが開くか ②自社から社外へメールが送れるか ③社外から自社へメールが届くか ④受け取った側でSPFとDKIMが通っているか。④はGmailなら受信メールのメッセージのソースを表示すれば確認できます。①だけで終えないでください。

独自ドメインのメールが受け取れない場合の切り分けは会社のドメインのメールが受信できないときの確認手順に、サーバー移転に伴って止まる時間の考え方はサーバー移転でメールが止まる時間の見積もり方にまとめています。送れてはいるのに相手の迷惑メールに入る場合は会社のメールが迷惑メールに入るときの直し方が該当します。

「◯時間で必ず伝播します」と言えない理由

ネット上には「DNSの反映は24時間」「72時間かかる」といった断定が並んでいますが、正確にはレコードごとのTTLと、経路上のどのキャッシュを踏むかで決まるので一律の答えはありません。ここまで挙げた公式の数字も、レジストリへの反映が15分程度、ネームサーバー変更が数時間〜24時間、否定応答の保持が1〜3時間、登録の停止解除が最大72時間、SPFの有効化が最大48時間と、すべて別のものを指しています。

だから、待っている間にやるべきことは「何度も設定を変えること」ではありません。権威側の答えが正しいことを一度確認したら、その事実を記録して触らないことです。変更を重ねるほど、どのTTLがいつ切れるのかを誰も追えなくなります。

次に作業する予定があるなら、事前にTTLを短く（例えば300秒に）しておくと切り替えが速く済みます。ただし短縮自体も反映に元のTTL分かかるので、作業の数日前にやる必要があります。当日に縮めても当日は効きません。

二度と同じ止まり方をしないために

復旧したら、そのまま次の再発防止までやっておくと安いです。ここは1時間もかかりません。

• 自動更新をオンにする。ドメイン・サーバー・SSLの3つとも別に確認する。1つだけオンになっている状態が最も危ない。
• 支払い用クレジットカードの有効期限を確認する。カードが切れていると自動更新は静かに失敗する。更新期限より前に切れないかを見る。
• 更新通知メールの宛先を確認する。退職者のアドレスや、誰も見ていない共有アドレスになっていないか。Whoisの登録者メールアドレスは認証メールの宛先でもあるので、ここが死んでいると停止まで一直線になる。
• 登録者情報を最新にする。ICANNの規定では、登録機関からの問い合わせに15日以内に応答しない状態が続くと停止の対象になる。連絡が取れることが前提の仕組みになっている。
• 期限をカレンダーに入れる。ドメイン・サーバー・SSLの3件を、期限の1か月前と1週間前の2回。

そもそも誰がどこで契約しているのか分からない、という状態のままだと上のどれも実行できません。その場合は契約の所在を突き止めるところから先に片付けてください。どこに請求が立っているかが分かるだけで、次に止まったときの復旧時間はまるで変わります。

今日やる順番

最後に、上から順に実行できる形にまとめます。該当しない項目は飛ばして構いません。

1. ブラウザに出ている文字列を正確にメモする（対応表で原因を1つに絞る）
2. 登録会社の管理画面とwhoisで、有効期限とステータスを見る。clientHoldがあればそこで止まっているので、認証手続きへ進む
3. whoisのネームサーバーが意図した場所になっているか確認する
4. 権威サーバーを名指しして、Aレコードの答えを直接見る
5. スマートフォンのモバイル回線で同じURLを開き、見えるかどうかを確かめる
6. 見えるなら手元のDNSキャッシュを捨てる（macOSはmDNSResponder、Windowsはipconfig /flushdns）
7. サイトが戻ったら、社外との往復でメールの送受信を確認する。SPFとDKIMが通っているかまで見る
8. 直した内容と日付を記録し、以降は設定を触らずに待つ

丸1日経っても4番の時点で答えがおかしいなら、設定が入っていないということなので、そこだけを直します。4番が正しいのに画面が変わらないなら、やることは待つことだけです。

ドメインとサーバーとメールが別々の会社にまたがっていて、どこから手を付けるか判断がつかないという状況でしたら、今の状態を伺ったうえで確認の順番だけでもお伝えできます。無理にお勧めはしませんので、困っている部分だけでもお聞かせいただければ嬉しいです。