DNS設定・ネームサーバー変更のトラブル事例8選と対処法

「ネームサーバーを変えたら、メールが届かなくなった」「言われたとおりにDNSを設定したのに、一日経っても反映されない」。サイト引越し屋さんには、サーバー移転やメール移行のご依頼と並んで、こうしたDNSまわりのご相談が毎月のように寄せられます。

DNSは一行の設定ミスでサイトとメールが同時に止まる一方で、画面上は「保存しました」としか表示されないため、何が起きているのか分かりにくいのが厄介なところです。

この記事では、弊社が実際に対応した案件をもとに、DNS設定・ネームサーバー変更で起きやすいトラブルを8つに分けて、現場で起きたこと・原因・対処法の順に解説します。

今まさに困っている方は、症状に近い見出しから読んでください。

DNS設定で変えているのは「住所台帳の場所」と「台帳の中身」

事例に入る前に、一つだけ前提をそろえておきます。DNS設定と一口に言っても、実際には「どの台帳を使うか（ネームサーバー）」と「その台帳に何を書くか（DNSレコード）」の2層に分かれています。

ネームサーバーを変えると、台帳そのものが丸ごと入れ替わります。一方、レコードの変更は台帳の一行を書き換える作業です。本記事で紹介するトラブルのほとんどは、この2つの取り違えから起きています。

設定項目	役割	間違えたときに起きること	関連する事例
ネームサーバー	どのDNS（台帳）を使うかを指定する	設定したはずの内容が効かない、既存の設定が消える	事例1・3・5
Aレコード・CNAMEレコード	Webサイトの表示先（サーバー）を指定する	サイトが表示されない、SSL証明書が発行されない	事例4・8
MXレコード	メールの配送先（メールサーバー）を指定する	メールが届かない、旧サーバーに届き続ける	事例2・4・6
TXTレコード（SPF・DKIM・DMARC、所有権確認など）	送信元の証明や、外部サービスとの連携に使う	迷惑メール扱いされる、Google Workspaceなどを使い始められない	事例1・3・7

もう一つ大事なのが、DNSの変更は即座に世界中へ届くわけではないという点です。

各地のサーバーが古い情報を一定時間覚えている（キャッシュ）ため、すぐに反映されるわけではありません。

理論上は最大72時間とされており、実際の現場的なリアルな数字でいうと、多くのケースでは数時間、遅くとも24時間以内に反映されています。

この「反映待ち」が、事例2や事例4のトラブルにも関わってきます。

事例1 DNSレコードを設定したのに反映されない

「設定はした。でも何も変わらない」というご相談は、DNSトラブルの中でも特に多いパターンです。反映待ちを疑って何日も待ってしまう方もいますが、実際には「書いた場所」そのものが間違っているケースが少なくありません。

現場で起きたこと

Google Workspaceで独自ドメインのメールを使い始めたい個人事業主の方からご相談がありました。ドメインを取得したサービスのDNS管理画面に、Googleから指定されたコード（TXTレコード）を貼り付けて丸一日経っても、「所有権を確認できません」という表示が続いていたそうです。

同じ年9月には、体験施設を運営する法人様からも似たご相談をいただきました。新しく取得したドメインにアクセスすると「アクセスできません」と表示され、ご自身でDNS設定を試みたものの「しばらくしてからお試しください」といった表示が出て先に進めなかった、という内容です。

原因は「設定した場所」と「ネームサーバー」の食い違い

個人事業主様のケースを弊社で調べたところ、原因は「ドメインのネームサーバーが未設定」でした。TXTレコードの中身は正しくても、ドメインがそのDNS（台帳）を参照していなければ、世界中のどこからもその記述は見えません。何日待っても反映されないのはこのためです。

ドメインを取得した会社、サーバー会社、外部のDNSサービスのいずれもがDNS管理画面を持っているため、「管理画面がある＝そこが使われている」とは限らないのが落とし穴です。

対処法

まずは「どこに書けば効くのか」を確かめてから設定し直します。

1. ドメインの管理画面（またはWhois検索）で、現在のネームサーバーがどこを指しているか確認する
2. そのネームサーバーを提供しているサービスのDNS管理画面で、必要なレコードを追加する（未設定なら、使いたいDNSのネームサーバーを先に設定する）
3. 数時間おいてから、サイト表示や外部サービスの認証をもう一度確認する

体験施設の法人様のケースでは、ドメインとサーバーのログイン情報を共有いただいた上で、ネームサーバーとDNSレコードを弊社で設定しました。情報をいただいた当日中に「Webサイト、メールアドレスともにご利用いただける状態」になり、お客様側でも接続を確認いただいています。

事例2 ネームサーバーを切り替えた直後、メールが届かない・消えた

サーバー移転やメール移行の当日にもっとも気をつけたいのが、切り替え直後のメールです。設定自体は正しくても、反映を待つ間の動き方を間違えると「届いているはずのメールが見当たらない」という事態になります。

現場で起きたこと

制作会社を通じて、ある商社様のメールとドメインをWebARENAからエックスサーバーへ移すご依頼をいただきました。弊社では切り替えを平日の午前中に行い、完了のご連絡とあわせて「メールは数時間〜24時間ほど不安定な状態になります」とお伝えしました。

あわせて、メールソフト（Outlook）の設定変更は「現時点ではまだ変更しないでください」とし、翌日に切り替えていただく流れでご案内しています。切り替え当日に新しい設定へ変えてしまうと、旧サーバーに届いたメールを受け取れなくなるためです。

原因は反映待ちの間、メールが新旧サーバーに分かれること

ネームサーバーを切り替えても、すぐに新しいサーバーへ切り替わるわけではありません。反映が終わるまでは、送り主側のサーバーが古い情報を見るか新しい情報を見るかで、旧サーバーに届くメールと新サーバーに届くメールが混在します。

弊社の経験では、およそ5〜6時間で移行先へ反映されるケースが多いものの、環境によっては一日近くかかることもあります。「届かない」と感じたメールの多くは、消えたのではなく、確認していない方のサーバーに届いています。

対処法

ポイントは、メールの接続方式（POPかIMAPか）によって、メールソフトを触るタイミングが逆になることです。

接続方式	メールソフトを変えるタイミング	順番を間違えると
POP	切り替えが完全に反映されたあと、既存アカウントの設定を更新する	反映前に旧サーバーへ届いたメールを受け取れなくなる
IMAP	切り替えの前に、同じアドレスで新サーバー用のアカウントを追加しておく	既存アカウントの設定を書き換えられず、切り替え後に受信できない時間が生まれる

どちらの場合も、切り替え後しばらくは旧いメール設定を削除せず、新旧両方を確認できる状態にしておきましょう。また切り替えの時間帯は、取引先からのメールが少ない深夜や、土日が休みの会社なら金曜の終業後をおすすめしています。

事例3 ネームサーバーを変えたら、既存のDNSレコードが消えた

Webサイトは表示されているのに、メールや外部サービスだけがおかしくなる。ネームサーバーを変更したあとによく見られる症状です。原因は、引っ越し前の台帳にあった設定の写し忘れです。

現場で起きたこと

Microsoft 365でメールを運用している法人様のサーバー移転とドメイン移管を進めていたときのことです。

移管元の管理会社から「Microsoft 365に対応するため、DNSにいくつかのTXTレコードを追加し、SPFにも追記している。ネームサーバーなどDNSを変更する前に確認してほしい」と、通常は開示しない現行のDNSレコードを特別に共有していただいたことがありました。

また別案件では、海外に拠点を置く飲食グループ様から、以前の管理代行会社のサーバーに残っているDNSを自社管理に移したいというご相談をいただきました。

こちらは、移し先として想定していたドメイン会社の仕様上、ネームサーバーを切り替えるまでDNSレコードを登録できないことが分かりました。そのまま切り替えると、Webサイトもメールも一時的に止まるリスクがある状態です。

原因は台帳ごと引っ越すのに中身を写さなかったこと

ネームサーバーを変えると、その瞬間から新しいDNSに書かれたレコードだけが有効になります。古いDNSにあった設定は自動では引き継がれません。

Webサイト用のAレコードは意識して移す方が多い一方、漏れやすいのはMicrosoft 365やGoogle Workspaceの認証用TXTレコード、SPFやDKIM、メール配信サービスの設定、サブドメインといった「普段は意識しない設定」です。

対処法

ネームサーバーを変える前に、現在のDNSレコードを全件控え、新しいDNSに先に登録しておきます。特に次のレコードは必ず確認してください。

• MXレコード（メールの配送先）
• TXTレコード（SPF、DMARC、GoogleやMicrosoftなどの所有権確認）
• DKIM用のTXT・CNAMEレコード
• wwwやmailなど、サブドメインのA・CNAMEレコード

飲食グループ様のように移し先で事前登録ができない場合、弊社ではCloudflareなどの外部DNSサービスに先に全レコードを作ってからネームサーバーだけを切り替える方法をご提案しています。

このとき現行のDNSを調べると、すでに使われていない旧サーバー向けの設定（mail・ftpなどの接続先やSPFの一部）も見つかったため、移行に合わせて整理することにしました。引っ越しは、古い設定を棚卸しする良い機会でもあります。

事例4 サイトだけ移したのに、メールまで止まりそうになった

「Webサイトは別のサービスへ、メールは今のサーバーのまま」という分け方はよくあります。ただしDNSの書き方によっては、サイトの向き先を変えただけでメールも一緒に動いてしまうことがあります。

現場で起きたこと

弊社が以前からサーバーを管理している法人様のサイトを、制作会社がWixでリニューアル公開することになりました。メールはそのままエックスサーバーを使い、Webに関するDNSだけをWix側へ向ける予定です。

公開当日、制作会社のご担当者が変更前のDNSを確認したところ、MXレコードの宛先がドメイン名そのものになっていることに気づきました。

このままAレコードをWixのIPアドレスに変えると、メールの配送先までWixを向いてしまう――そう判断した上で、作業手順に誤りがないか弊社へ事前に確認をいただきました。

原因はMXレコードがドメイン名を指していたこと

MXレコードにドメイン名が書かれていると、メールの配送先は「そのドメインのAレコードが指すサーバー」になります。サイトとメールが同じサーバーにあるうちは問題が表に出ませんが、サイトだけを別の場所へ移した瞬間にメールも引っ張られます。

SPFに「+a:ドメイン名」のような書き方がある場合も同様で、意図せずWebの移転先を送信元として許可してしまいます。

この案件では、次のような順番で変更する計画が立てられていました（ドメイン名・ホスト名は付替えています）。

レコード	変更前	変更後	変更する理由
MX	example.jp	メールサーバーのホスト名（svXXXX.xserver.jp）	Aレコードを変えてもメールの配送先が動かないようにする
TXT（SPF）	「+a:example.jp」を含む	「+a:example.jp」を削除	WixのIPアドレスを送信元として許可しないため
A（example.jp）	エックスサーバーのIP	Wix指定のIP	WebサイトをWixに向ける
www	Aレコード	Wix指定のCNAME	同上

対処法

サイトだけを移すときは、Aレコードを触る前に「メールがAレコードに依存していないか」を確認します。

1. MXレコードを、メールサーバーの正式なホスト名に変更する
2. SPFに含まれるドメイン名参照（+a:ドメイン名）を整理する
3. 反映を待ってから、Web向けのA・CNAMEレコードを変更する

もう一つ見落としやすいのがメールソフトの設定です。受信・送信サーバー名に「example.jp」や「mail.example.jp」を指定している場合は、サーバーのホスト名への変更が必要になることがあります。

事例5 ドメイン移管の途中でサイトもメールも止まった

ドメイン移管は「管理会社を変えるだけで、サイトやメールには影響しない」と説明されることが多く、実際に通常はネームサーバーもそのまま引き継がれます。ただし、移管の途中でネームサーバーが変わってしまうと、移管が完了するまでどこからも手を出せない状態になります。

現場で起きたこと

貿易会社のご担当者様からお電話をいただきました。Yahoo!ドメインで管理していたドメインを別のドメイン会社へ移すため移管を申請したところ、１週間後からメールが使えなくなり、Webサイトも表示されなくなったというご相談です。

確認すると、問題なく動いていたころとはネームサーバーが変わっていました。さらに、移管先の管理画面では移管が完了するまで設定を操作できず、弊社でも調整のしようがない状態でした。

そこでまず移管元での手続きを完了させるようご案内し、あわせて移管完了後すぐに調査に入れるよう準備を進めました。

結果として移管元での承認手続きが完了し、メールとWebサイトは正常に戻りました。申請から復旧までは10日、実際に止まっていたのは約3日間です。

原因は移管手続きの途中でネームサーバーが変わったこと

この案件の背景には、Yahoo!ドメインのサービス終了（2025年6月30日で終了と告知）に伴う移行がありました。管理会社の移り変わりと移管申請が重なり、移管が完了しないままネームサーバーだけが変わっていたため、Webもメールも正しい場所を参照できなくなっていました。

通常の移管では、ネームサーバーなどのDNSは移管元の設定がそのまま引き継がれます（エックスサーバー よくある質問）。

一方で、弊社に届いた移管先サービスの案内メールには「移管申請中にネームサーバーの変更を行うと、ドメイン移管失敗となる可能性がある」とも明記されています。移管中のネームサーバーは、「変えない」が原則です。

対処法

ネームサーバーの変更は、移管申請の前か、移管が完了したあとに行います。サーバー移転とドメイン移管を同時に進める場合も、弊社では「Webとメールの切り替えを先に済ませ、安定してから移管する」順番でご提案することがほとんどです。

また、移管で止まりやすいのが承認メールです。承認メールはWhoisに登録されたメールアドレス宛てに届くため、申請前に「今も受け取れるアドレスか」を確認しておきましょう。

事例2の商社様のケースでも、登録アドレスが旧いプロバイダーのものだったため、移管の前に自社ドメインのアドレスへ変更しています。

事例6 DNSの管理画面がどこにあるか分からない・触れない

いざ設定を変えようとして、そもそもDNSを触れる画面にたどり着けない。制作会社や前任者に管理を任せていた企業様ではとてもよくある状況で、作業そのものよりこの段階で時間がかかることも珍しくありません。

現場で起きたこと

事例2の商社様のケースでは、サーバー（WebARENA）の管理画面には入れたものの、ドメインの管理画面がどこにあるのか分かりませんでした。弊社で調べたところ、ドメインは同じグループの別サービスで管理されていたことが分かり、そこからログイン情報を確認していただきました。

また事例3の飲食グループ様は、ドメインもメールも自社のアカウントで契約していたにもかかわらず、DNSだけが以前の管理代行会社のサーバーに残っていました。「自分たちのものだと思っていたら、権限は他社にあった」というのは、管理を外部に任せていた企業様で特によくあるパターンです。

「触れない」ときのパターンと打ち手

弊社が実際に出会ったケースを、パターンごとにまとめると次のとおりです。

パターン	実際にあった状況	打ち手
管理元が分からない	サーバー会社だと思っていたが、ドメインは別サービスで管理されていた	Whoisとネームサーバーから管理元を特定する
代行会社が権限を持っている	DNSが以前の管理代行会社のサーバーに残っていた	現行レコードを共有してもらい、自社管理のDNSへ移す
レコードを開示・変更できない契約	ホスティングサービスがレコード情報を開示できず、MXレコードも変更できなかった	ドメインごと移管し、移管先でDNSを組み直す
管理画面そのものがない	お客様向けの管理画面がなく、変更は依頼ベースだった	変更内容をまとめて依頼するか、移管を検討する
ログイン情報を渡してもらえない	規定の変更で、管理画面のID・パスワードを開示できないと回答された	必要なDNS情報の共有や設定代行を依頼する

対処法

最初にやるべきなのは、「ドメイン」「DNS」「Webサーバー」「メールサーバー」の4つがそれぞれどこにあり、誰がログインできるのかを一覧にすることです。この4つが別々の会社にあるのは珍しいことではなく、一覧にするだけで「誰に何を頼めばいいか」が見えてきます。

その上で、権限が他社にあるものは、ログイン情報の引き継ぎか移管を先に進めます。移管には先方の対応を待つ時間があるため、サーバーの契約終了日など期限がある場合は、早めに動き始めるのが安全です。

事例7 メールが迷惑メールに入る・送信できない

届くには届くけれど、相手の迷惑メールフォルダに入ってしまう。あるいは、一部の人だけ送信できない。こうした症状も、原因をたどるとDNSの設定に行き着くことが少なくありません。

現場で起きたこと

エステサロンのオーナー様から「サイトのお問い合わせフォームの通知が届かない」とご相談をいただきました。調べると、通知は届いていたもののGmailの迷惑メールに振り分けられており、さらにフォームには2分に1回ほどのペースでスパム投稿が届いていました。

弊社ではフォームにスパム対策を入れ、ブロックリストの解除申請も行いました。その過程でサーバー会社から「このドメインはDKIM、DMARCなど送信元の信頼性を高める設定が行われていない」という回答があり、迷惑メール判定の一因として浮かび上がりました。

また別案件では、海外とも取引のある法人様から「一部の利用者だけメールが送信できない」というご相談もありました。こちらは、すでに契約が終了しているメールフィルタリングサービスの設定がDNS上に残っていたことが分かっています。

原因は送信元認証の未設定と、古い送信経路の残り

受信側のメールサービスは、DNSに書かれた送信元認証の情報を見て「本当にそのドメインから送られたメールか」を判断しています。SPFは「このサーバーからの送信を許可する」という宣言、DKIMはメールに付ける電子署名、DMARCは認証に失敗したメールの扱いを受信側に伝える設定です。

これらが未設定だと、Gmailなどで迷惑メール判定を受けやすくなります。反対に、使っていないサービスの設定がSPFやMXに残っていると、存在しない経路を前提にメールが処理され、送信や受信の不具合につながります。

対処法

経路を確かめずに設定だけを足しても、状況が複雑になるだけです。弊社では次の順番で切り分けます。

1. 今使っているメールサーバーと、受信・送信の経路を特定する
2. 使っていないサービスの設定（MX・SPFなど）を整理する
3. SPF・DKIM・DMARCを、実際の送信元に合わせて設定する
4. Gmailなど主要な宛先へ送信テストを行う

なお、設定を整えても、受信側の判定が変わるまでには時間がかかることがあります。エステサロン様のケースでも、最終的には受信側で「迷惑メールではないことを報告」していただくことで、以降は受信トレイに届くようになりました。

事例8 サーバーを移したらSSL証明書が発行されない

切り替え後にサイトを開くと、ブラウザに「保護されていない通信」と表示される。これもDNSが関わるトラブルです。証明書の設定に問題がなくても、DNSの向き先が合っていなければ発行されません。

現場で起きたこと

建設会社様のメール移行を進めていたとき、サーバー会社から次のような通知が届きました。

「www付きドメインのAレコードが、SSL証明書を申し込んだサーバーと異なるIPアドレスを参照している。自動更新版SSLはファイル認証のため、Aレコードに当社サーバーを指定しないと証明書を発行できない」という内容です。

原因と対処法

自動更新型のSSL証明書の多くは、「そのドメインにアクセスすると、本当にこのサーバーにたどり着くか」を確かめてから発行・更新されます。Aレコードが別のサーバーを向いていると、この確認に失敗して証明書が発行されません。

対処法は、Aレコードを証明書を設定するサーバーに合わせることです。このとき「example.jp」と「www.example.jp」は別々のレコードなので、両方の向き先を確認してください。wwwなしだけを移してwww付きが旧サーバーに残っている、という状態は見落とされやすいポイントです。

また、有料のSSL証明書を使っている場合は、旧サーバーから秘密鍵と証明書ファイルを受け取り、新サーバー側で設定して引き継ぐ方法もあります。切り替えの前に、どちらの方法でSSLを用意するかを決めておきましょう。

DNSの切り替えで失敗しないための正しい手順

8つの事例を振り返ると、トラブルの多くは切り替え当日より前の「把握」と「準備」で防げるものでした。弊社がサーバー移転やメール移行でDNSを切り替えるときは、次の順番で進めています。

1. ドメイン・DNS・Webサーバー・メールサーバーの管理元とログイン情報を一覧にする（事例1・6）
2. 現在のDNSレコードを全件控え、使っていない設定も洗い出す（事例3・7）
3. MXやSPFがAレコードに依存していないか確認する（事例4）
4. 新しいDNSに、必要なレコードを先に登録しておく（事例3）
5. ドメイン移管中でないことを確認し、切り替え日時を決める（事例2・5）
6. 切り替え後、Web表示・メールの送受信・SSLを確認する（事例2・7・8）
7. 反映が完了し、問題がないことを確かめてから旧サーバーを解約する

切り替えの時間帯については、取引先からのメールが少ない深夜や、土日が休みの会社なら金曜の終業後がおすすめです。

ちなみに弊社では、平日の9時〜17時であれば追加費用なしの基本料金にてDNS切り替えを行い、それ以外の時間帯（深夜や休日）でもは別途時間外対応費をいただければご対応可能です。

まとめ

DNS設定やネームサーバー変更のトラブルは、設定値そのものの間違いよりも、「どこで管理しているのか」「今何が登録されているのか」を把握しないまま切り替えてしまうことで起きていました。反映待ちの時間やドメイン移管のタイミングも、知っていれば準備できるものばかりです。

一方で、関わる会社が多い、管理画面に入れない、メールを止められないといった条件が重なると、社内だけで安全に進めるのは簡単ではありません。すでに不具合が出ている場合は、設定を重ねて変える前に、一度現状を整理することをおすすめします。

サイト引越し屋さんでは、サーバー移転やメール移行に伴うDNS設定のほか、DNS設定だけのスポットのご依頼もお受けしています。「この設定で合っているか分からない」という段階でも、お気軽にご相談ください。