「サイトを新しいサーバーに移したら、その日から問い合わせメールが1通も来なくなった」「でもメールの設定は何も触っていないし、管理画面を見ても設定はちゃんと残っている」——ネームサーバーを変更した直後、この不可解な状態に落ちる人は少なくありません。
結論から言うと、メールの設定は消えていません。ネームサーバーを変更したことで、その設定が誰からも参照されなくなっただけです。旧サーバーの管理画面を開けば今も正常に表示されるため、「設定を確認する」という行動では絶対に見つかりません。しかも、送信元にはエラーも返らないので、届いていないこと自体に気づけません。
株式会社Fyveは、中小企業のWeb運用とAI活用を支援しています。この記事では、私が自社で運営しているWebサイトの移転で実際に起こした事故をもとに、なぜメールだけが静かに止まるのか、どう切り分けて、どう復旧し、復旧後の何を確認すべきかまでを、実行できるコマンド付きで解説します。
結論｜設定は消えていない。「見に行かれなくなった」だけ
最初に、この事故の構造だけ理解してください。ここさえ掴めば、あとの手順はすべて理由が分かった状態で踏めます。
ネームサーバーとは「どの設定表を正とするか」の指定
ドメインには、そのドメインに関する設定（どのIPアドレスでWebサイトを配信するか、どのサーバーでメールを受け取るか）を書いた設定表があります。これをDNSゾーンと呼びます。そしてドメイン名の登録情報には、「このドメインの設定表は、どのサーバーに置いてあるか」を示すネームサーバー（NS）が登録されています。
重要なのは、ネームサーバーの変更が「設定表の引っ越し」ではなく、「参照先の切り替え」でしかないことです。レンタルサーバーAのネームサーバーから、別の事業者Bのネームサーバーへ変更した瞬間に起きるのは、次の1点だけです。
- 世界中のメールサーバーやブラウザが、これ以降Bの設定表だけを見に行くようになる
Aの設定表は削除されません。Aのサーバー上にそのまま残り続けます。ただ、誰も見に来なくなるだけです。
Webは自分で設定するのでズレない。メールは「移し忘れ」に気づけない
サイトの移転作業では、新しい設定表（B）にWebサイト用のレコードを自分の手で書きます。ドメインのルート（apex）を新しいホスティング先に向けるAレコードやCNAMEです。だからWebは正しく表示されます。作業した本人が、その場で結果を目で確認するからです。
ところがメール関連のレコードは、多くの場合レンタルサーバーの契約時に自動で作られていて、自分で書いた記憶がありません。書いた記憶がないものは、移す対象としても思い浮かびません。結果、新しい設定表（B）にはWebのレコードしか無い状態になります。
この「エラーが出ないまま、指示が黙って無視される」構造そのものについては、別記事で仕組みごと整理しています。
だから旧サーバーの管理画面は「正常」に見える
ここが、この事故がいちばん厄介な理由です。旧レンタルサーバーの管理画面にログインすると、メールアカウントは存在し、DNSレコードの一覧にもMXレコードが正常に並んでいます。画面上に異常は1つもありません。
当然です。その設定表は壊れていないのですから。壊れているのは「その設定表が参照されているかどうか」という、管理画面の外側にある事実です。管理画面は自分が書いた内容を映す鏡であって、世界がそれを見ているかどうかは映しません。
実際に起きたこと｜サイトは無傷、メールだけが静かに消えた
私が踏んだ事故の経過を、時系列で書きます。
作業自体は完璧に成功していた
自社で運営しているメディアサイトを、共有レンタルサーバーから静的ホスティングサービスへ移す作業でした。ドメインのネームサーバーを、レンタルサーバー側のもの（5台）から、ドメイン管理側のDNSサービスのもの（3台）へ変更し、新しい設定表にホスティング先を向けるレコードを書きました。
結果は良好で、全ページが正常に表示され、SSL証明書も自動発行され、OGP画像も正しいURLで解決していました。作業は成功したと判断して、その日は終えました。
症状は「静かすぎて症状に見えない」
異常に気づいたのは後日です。そのドメイン宛のメールが、1通も届いていませんでした。
- エラー画面は出ない
- メールソフトにエラーも出ない（受信0通は「今日は来なかった」と区別がつかない）
- 送った相手にもバウンスメール（宛先不明の返信）が返らない
- サイトは200を返し続けていて、監視も緑のまま
つまり症状は「問い合わせが来なくなる」だけです。届かなかった問い合わせが何通あったかは、届かなかったので分かりません。「最近ちょっと静かだな」で数週間過ぎる種類の事故です。
なぜバウンスすら返らないのか（ここが技術的な核心）
普通に考えると、宛先のメールサーバーが無ければ「宛先不明」で送信者に返るはずです。返らなかったのには、はっきりした理由があります。
メール配送の標準仕様であるRFC 5321のSection 5.1に、次の規定があります。
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.（MXレコードが1件も返らなかった場合、そのアドレスは優先度0の暗黙のMXレコードが存在するものとして扱われ、そのホスト自身に向けられる）
これは暗黙のMX（implicit MX）と呼ばれる、MXレコードが普及する以前からの互換性のための規定です。日本語にすると、こういう挙動になります。
- MXレコードが見つからない場合、送信側は「宛先不明」とはしない
- 代わりに、そのドメインのAレコード（Webサイトを配信しているIPアドレス）宛にメールを届けようとする
私のケースでは、新しい設定表にMXレコードが無く、Aレコードだけが静的ホスティングサービスに向いていました。つまり、届いたはずのメールは、Webサイトを配信しているサーバーに向かって配送されていたわけです。当然そこにメールを受け取る仕組みはないので、メールはそのまま消えます。送信側から見れば「宛先はちゃんとある（Aレコードが返ってきた）」ので、宛先不明の扱いにもなりません。
この「MXが無い＝Aレコードへ落ちる」挙動を知っているかどうかが、切り分けのスピードを決めます。エラーが出ないのは不具合ではなく、仕様どおりの動作です。
「ネームサーバーを戻せば直る」が通じない場合がある
ここも実際に踏んだので書いておきます。原因が分かったとき、最初に浮かぶ復旧策は「とりあえずネームサーバーを元に戻す」でしょう。しかし、私のケースではそれでは直りませんでした。
MXが「ドメイン自身」を指して書かれていた
旧レンタルサーバーが自動生成していたMXレコードは、次の形でした。
example.jp. MX 0 example.jp.優先度0で、自分自身のドメイン名を指しています。これはレンタルサーバーの初期設定として珍しくない書き方です。Webもメールも同じサーバーに同居している前提なら、これで正しく動きます。ドメイン自身のAレコード＝そのレンタルサーバーのIPアドレスであり、そこにメールサーバーも同居しているからです。
Webを別サーバーに移した時点で、どちらの設定表でも壊れる
ところがWebサイトだけを別のホスティング先に移すと、この書き方は破綻します。
- ドメイン自身のAレコードは、新しいホスティング先を指すように書き換えた
- MXは「ドメイン自身へ届けろ」と書いてある
- 結果、MXを正しく参照できても、配送先は新しいホスティング先になる
つまり、ネームサーバーを元に戻したとしても、Aレコードを移転先に向けたままである限り、メールは同じ場所へ吸い込まれます。「元に戻せば直る」が成立しない構造です。前述の暗黙のMXと、結果として同じ場所に着地します。
唯一の解は、MXをホスト名で書き直すこと
正しい直し方は1つだけです。MXレコードの宛先を、ドメイン名ではなくメールサーバーの実体のホスト名に書き換えます。
example.jp. MX 0 mail.example-hosting.jp.レンタルサーバーの契約では、この実体のホスト名がサーバー番号を含む形（例: sv####.契約先ドメイン）で割り当てられていることが多く、管理画面のサーバー情報やサーバーパネルのホスト名欄に記載されています。ここを確定させないと復旧できません。
ホスト名がどうしても分からない場合の実務的な手がかりを1つ挙げます。切り替え前のAレコードのIPアドレスを控えておき、それが指すホスト名（逆引き、もしくは契約サーバー情報）と照合すると、実体を特定できます。私はこの方法で確定させました。
診断手順｜5ステップで切り分ける
症状から原因までを、最短で確定させる手順です。dig コマンドを使います（macOSやLinuxのターミナル、WindowsならWSLやオンラインのDNS参照サービスでも代替できます）。
STEP 1：いま権威はどちらにあるかを確認する（1分）
dig NS example.jp +shortここで返ってくるのが、現在参照されている設定表の持ち主です。移転作業で変更した先の事業者が返ってくれば、切り替え自体は完了しています。
STEP 2：新しい設定表にMXがあるかを確認する（1分）
dig MX example.jp +shortここが空なら、この記事の事故が起きています。 何も返ってこないということは、世界中の送信側から見て「このドメインにメールサーバーは指定されていない」状態です。前述のとおり、送信側はAレコードへ落として配送を試み、メールは消えます。
STEP 3：旧サーバーの設定表に何が残っているかを見る（3分）
ここが復旧の鍵です。旧ネームサーバーを直接指定して問い合わせると、今は誰も見に行っていない設定表の中身を読めます。
dig MX example.jp @ns1.old-hosting.jp +short
dig TXT example.jp @ns1.old-hosting.jp +shortここで返ってくるMX・SPF・DKIMの値が、そのまま復旧に使う原本です。管理画面のコピペより、実際に配信されている値を取るほうが確実です。この3種類を控えてください。
STEP 4：MXの指す先が生きているかを確認する（3分）
MXの宛先ホストに、メールサーバーが実際に応答するかを見ます。
openssl s_client -connect mail.example-hosting.jp:587 -starttls smtp220 ESMTP で始まる応答が返れば、サーバー側は生きています。ここが応答しないなら、原因はDNSではなくサーバー側です。
⚠️ ここで1つ落とし穴があります。ポート25で試すと、家庭用インターネット回線からはタイムアウトします。 多くのISPが迷惑メール対策としてポート25の外向き通信を遮断しているためです（OP25B）。これを「サーバーが落ちている」と誤診しないでください。
切り分け方は簡単で、確実に生きているドメインのメールサーバーを対照実験として同じ手順で叩くことです。大手メールサービスのMXホストにポート25で接続してみて、それも同じくタイムアウトするなら、原因は自分の回線側です。私はこの対照実験で、サーバー障害の線を5分で消しました。
STEP 5：SPF・DKIMも一緒に消えていることを確認する（2分）
忘れやすいのがここです。SPFもDKIMも、DNSの設定表に書かれたTXTレコードです。ネームサーバーを変えれば、MXと一緒にまとめて参照されなくなっています。
dig TXT example.jp +short
dig TXT default._domainkey.example.jp +shortMXだけ直して安心すると、今度は「受信は戻ったが、こちらから送ったメールが相手の迷惑メールに入る」という第二の事故が待っています。送信側の認証が失敗する仕組みと診断は、こちらで詳しく解説しています。
復旧手順｜移すのは1レコードではなく3種類
診断で控えた値を、新しい設定表へ投入します。ポイントは3種類まとめて移すことと、MXの書き方を直すことの2点です。
投入する3レコード
種別 | 役割 | 移すときの注意 |
|---|---|---|
MX | このドメイン宛のメールをどのサーバーが受け取るか | 🔴 ドメイン自身ではなくメールサーバーの実体のホスト名で書く |
SPF（TXT） | このドメインを名乗って送信していいサーバーの一覧 | 旧設定表の値をそのまま。 |
DKIM（TXT） | 送信メールへの電子署名の公開鍵 | セレクタ名（ |
MXの書き方だけは「原本のコピー」にしない
SPFとDKIMは原本をそのままコピーします。MXだけは書き換えます。 前述のとおり、旧設定表のMXが 0 ドメイン名 の形式だった場合、そのままコピーするとAレコードに引きずられて壊れたままだからです。
この判断を機械的に書くと、次のようになります。
- 旧MXの宛先がドメイン名そのもの → メールサーバーの実体のホスト名に書き換える（要対応）
- 旧MXの宛先が別のホスト名（
mail.〜や外部メールサービスのホスト） → そのままコピーでよい
後者であれば、そもそも「ネームサーバーを戻せば直る」も成立します。前者だけが、戻しても直らない厄介なケースです。
直したあとが、いちばん危ない
ここが実務で最も価値のある部分だと思っています。レコードを投入したあと、1回確認して「直った」と判断するのが、この事故で最も危険な瞬間です。
権威DNSサーバーは複数台あり、反映は同時ではない
ドメインのネームサーバーは、たいてい2〜5台のセットで登録されています。管理画面でレコードを保存したとき、その値がすべての台に行き渡るまでには時間差があります。
私が計測した実測値は、次のとおりでした。
- 3台構成の権威DNSサーバーで、全台に反映されるまでおよそ10分
- 反映順は登録順（1→2→3）ではなく、3台目→1台目→2台目の順だった
この10分間に何が起きているか。問い合わせた相手によって、MXがある応答と、MXが無い応答が混ざります。 そして、MXが無い応答を引いたメールサーバーは、前述の暗黙のMXに従ってAレコード側（＝Webサイトの配信先）へ配送します。つまりその1通は、復旧作業の最中に消えます。
だから「全台に、直接聞く」まで作業は終わっていない
通常の dig MX example.jp は、自分が使っているDNSキャッシュサーバー1台に聞いているだけです。運良く反映済みの台を引けば、正常に見えます。1回の確認で「直った」と言えるのはこのためです。そして、それは何の証明にもなっていません。
確認すべきは、権威DNSサーバー全台への直接問い合わせです。
# 権威サーバーを列挙する
dig NS example.jp +short
# 列挙された全台に、1台ずつ直接聞く
dig MX example.jp @ns1.dns-provider.jp +short
dig MX example.jp @ns2.dns-provider.jp +short
dig MX example.jp @ns3.dns-provider.jp +short全台が同じ値を返して、はじめて反映完了です。加えて、実際にメールを送ってくる側（外部）から見えているかを確認するため、パブリックDNSからも引いておくと確実です。
dig MX example.jp @8.8.8.8 +short
dig MX example.jp @1.1.1.1 +short
dig MX example.jp @9.9.9.9 +short最後は、実際に1通送る
DNSが全台で正しく見えていても、それは「配送先の指定が正しい」ことの証明にすぎません。最後に必ず、外部のメールアドレスから、自分の独自ドメイン宛に実際に1通送って、受信できることを確認します。
さらに、時間を空けてもう1通送ってください。1通目がたまたま反映済みの経路を引いていた可能性を潰すためです。復旧作業の確認は、この2通目まで含めて1セットです。
移転する前に、3つだけ確認する（予防）
ここまでは起きてしまった後の話でした。起こさないための確認は、驚くほど簡単です。作業前に3分あれば終わります。
① そのドメインで、メールも受け取っているか
dig MX example.jp +short何か返ってくれば、そのドメインはメールも使っています。ネームサーバーを変更する作業は、そのままメールを止める作業でもあると認識してください。ここで返ってきた値を、作業前にテキストファイルに保存しておきます。
② メール関連のレコードを、作業前に全部控える
MX・SPF・DKIMの3種類です。旧設定表がまだ参照されている「作業前」に控えるのが最も簡単です。切り替え後でも、STEP 3の方法で旧ネームサーバーに直接聞けば取れますが、契約解除まで進んでいると取り返しがつかなくなります。
なお、この機会にメールの受け口自体を移すという選択もあります。Webサイトの移転に合わせて、メール受信を独立したサービスへ切り出しておくと、次回以降の移転でこの事故は構造的に起きなくなります。
独自ドメインメールを無料化｜Cloudflareで受信と送信
③ 切り替えた当日に、外部から1通送る
切り替え作業のチェックリストに、「サイトが表示されること」と並べて「メールが1通届くこと」を書いてください。 サイトの表示は誰でも確認します。メールは、確認項目に書いていないと確認されません。
この3つを踏むだけで、この記事の事故は起きません。逆に言えば、この3つを踏まなかっただけで、私は問い合わせを取りこぼしました。
よくある質問
ネームサーバーを変更してから、何時間で影響が出ますか？
数分から数時間です。旧ネームサーバーの情報がキャッシュに残っている間は従来どおり動くため、切り替え直後は正常に見えることがあります。「切り替えて1時間、問題なし」は安全の証明になりません。 最大48時間程度は新旧が混在しうると考えて、翌日にもう一度確認してください。
メールが消えた場合、あとから復旧できますか？
できません。暗黙のMXでWebサーバー側へ配送されたメールは、受け取る仕組みがないため破棄されます。送信者にもエラーが返らないため、送った側も「届いている」と思っています。 復旧後に、主要な取引先へ「この期間のメールが届いていない可能性がある」と伝えるのが現実的な対応です。
MXレコードだけ直せば、とりあえず受信は戻りますか？
受信は戻ります。ただしSPF・DKIMが欠けたままだと、こちらから送るメールが相手の迷惑メールフォルダに入る、あるいは拒否されるようになります。受信の復旧と送信の維持は別問題なので、3種類まとめて投入してください。
Webサイトを移転せず、ネームサーバーだけ変えた場合も起きますか？
起きます。この事故の原因はWebサイトの移転ではなく、参照される設定表が入れ替わったことだからです。新しい設定表にMXを書き写していなければ、Webサイトがどこにあっても受信は止まります。
非エンジニアでも、自分で確認できますか？
できます。dig が使えない環境でも、ブラウザ上でDNSレコードを参照できる無料サービスがあり、「MX」を選んでドメイン名を入力すれば結果が見られます。見るべきは1点だけです——MXの欄が空になっていないか。 空なら、この記事の事故です。
移転作業を外注している場合は、何を頼めばいいですか？
「ネームサーバーを変更する前に、現在のMX・SPF・DKIMを控えて、新しいDNSにも同じ内容を設定してください」と依頼してください。あわせて「切り替え後に、外部から1通送って受信を確認してください」まで作業範囲に含めてもらうことが重要です。Web制作の見積もりでは、メールが作業範囲から抜け落ちていることがよくあります。
まとめ｜壊れるのは、動かしたものではなく動かしていないほう
この事故から持ち帰るべき点を、3つに絞ります。
- 設定は消えていない。参照されなくなっただけ。だから旧サーバーの管理画面はいつまでも正常に見え、「設定を確認する」という行動では見つからない
- MXが無いとエラーにならず、Webサーバー宛に配送されて消える。RFC 5321の暗黙のMXという仕様どおりの挙動であり、送信者にもバウンスが返らない
- 1回の確認で直ったと判断しない。権威DNSサーバーは複数台あり、反映には時間差がある。全台に直接聞き、最後は実際に1通送る
もう一段だけ一般化すると、この事故の本質は「壊れるのは、動かしたものではなく、動かしていないほう」だという点にあります。私はWebサイトを動かし、Webサイトを確認しました。壊れたのは、動かさなかったメールのほうでした。
何かを切り替えるときは、作業対象そのものより先に「いま、この設定に乗っかっているものが他に無いか」を数えてください。数えなかったものは、確認もされません。そして確認されなかった箇所こそが、静かに止まります。
株式会社Fyveでは、中小企業のWebサイト運用とAI活用の伴走支援を行っています。移転や環境の切り替えで「何を確認すべきかの一覧」から作りたい場合は、こうした運用の勘所ごと設計をお手伝いしています。
