はじめに
ドメインやサーバーを移行した直後、
「突然メールが届かなくなった」「受信履歴が止まった」
そんな経験はありませんか？
これは設定ミスではなく、DNS（ドメインネームシステム）の仕組みによる一時的な現象です。
とくに、事業用メール（info@〜 や contact@〜）を運用している場合、
わずか数時間の停止でも機会損失につながることがあります。
この記事では、お名前.com → ConoHa WING に切り替えた際に発生した実例をもとに、
原因・対処法・再発防止のためのワークフローをまとめました。
「メールが届かない」トラブルに強いサイト運営者・クリエイターになれるよう、
このページを“手元のバイブル”として残しておいてください。
📩 1. トラブルのきっかけ：ドメイン移行によるメール停止
今回の事例では、既存ドメイン（仮に example.com）をお名前.com から ConoHa WINGへ移行しました。
移行の目的は「WordPressサブサイト（/school）追加」「サーバー一元化」「SSL対応強化」など。
しかし、DNS切り替えの反映中に、メールの受信が一時的にストップ。
数時間後に送信テストを行ったところ、エラーは出ないものの届かない状態に。
この現象は珍しいものではなく、**ネームサーバー変更直後の“DNS伝播待ち”**が原因でした。
🧩 2. DNS伝播とは何か？（仕組みの理解）
DNSとは「ドメイン名をIPアドレスに変換するシステム」です。
たとえば「mail.example.com → 118.27.122.80」という変換情報を、
世界中のサーバーが順番に更新していきます。
この「情報が世界に広がるまでの時間」がDNS伝播です。
反映速度は利用者の回線や地域ごとに異なり、早ければ数分、遅ければ48時間かかります。
つまり、DNS切り替え直後は
・一部のネットワークでは新サーバーを参照
・一部のネットワークでは旧サーバーを参照
という“二重状態”が発生します。
結果、送信元によってメールが「届く」「届かない」が混在するのです。
🚨 3. 実際に起きた症状
- Webメールにログインできるのに受信が止まっている
- 送信側（GmailやiCloudなど）ではエラーが出ない
- OutlookやiPhoneのメールアプリでは「サーバーに接続できません」エラー
- DNSCheckerで古いMXレコード（お名前.comの設定）が残っている
これらはすべて、「DNS伝播の途中」で起きる典型的な症状です。
🧭 4. 原因の正体：MXレコードの遅延反映
メールの行き先を決めるのが「MXレコード（Mail Exchange Record）」です。
このレコードが古いままだと、メールが旧サーバーへ送信され続けます。
例：
古い設定：mx01.example.ne.jp
新しい設定：mx01.conoha.ne.jp
受信が止まるのは、この「MXレコードの行き先が世界で統一されていない」ため。
つまり、サーバーが壊れたわけでも、設定ミスでもありません。
🔧 5. 解決までのステップ
ここからは、ConoHa WINGとお名前.comを使った実際の復旧手順です。
（アドレスやIPは一例です）
① ConoHa側のDNS設定を確認
ConoHa WING → ドメイン → DNS設定画面を開き、
以下のレコードを登録・反映します。
| タイプ | 名称 | 値 | 備考 |
|---|---|---|---|
| A(通常) | @ | 118.27.95.83 | メインサイト |
| A(通常) | 118.27.122.80 | メールサーバー | |
| MX | @ | mx01.conoha.ne.jp | 優先度 10 |
| MX | @ | mx02.conoha.ne.jp | 優先度 20 |
| TXT | @ | v=spf1 include:_spf.conoha.ne.jp ~all | SPF設定（迷惑メール対策） |
② 伝播状況をチェック
DNS Checker にアクセスし、
「MX」欄に自分のドメインを入力。
🌏 世界地図上のアイコンがすべて「青色（Resolved）」になれば完了です。
③ Webメールで受信テスト
ConoHaのWebメールURL：
👉 https://mail.conoha.ne.jp
- info@～ または sacra@～ でログイン
- 自分自身へメールを送信（送信→受信が即時反映されれば成功）
④ 外部メールから再確認
- Gmail / Yahoo! / iCloud など別ドメインからテスト送信
- エラーが返らなければOK
- 数時間たっても届かない場合は「キャリアDNSのキャッシュ更新待ち」
⑤ メールアプリ側の再設定（必要な場合のみ）
受信（IMAP）
- サーバー：mail.ドメイン名（例：mail.example.com）
- ポート：993（SSL有効）
送信（SMTP）
- サーバー：mail.ドメイン名
- ポート：465（SSL有効）
💡 6. 復旧の確認ポイント
- Webメールで受信履歴が再開している
- 他アカウントからのメールが届く
- メール送信も問題なく動作している
- DNSCheckerの全サーバーが新レコードを参照
これらが揃えば完全復旧です。
🧠 7. 再発防止・ナレッジ化のポイント
DNS関連のトラブルは、原因を理解していれば怖くない。
しかし、知らない状態で発生すると「メールが壊れた！」とパニックになります。
再発防止には次の3点が効果的です。
- DNS変更時にクライアントへ事前告知する
→「24〜48時間、メール受信が一時停止する可能性あり」と明記。 - 金曜夜・日曜深夜の切り替えを避ける
→ サポート対応できない時間に障害が出やすい。 - Webメールの存在を周知する
→ メールアプリで届かなくても、Webでは確認可能。
🗂 8. チェックリスト（保存版）
- お名前.com側ネームサーバーをConoHaに変更
- DNS設定を正しく登録
- DNSCheckerで世界反映を確認
- Webメールで受信確認
- クライアントへ伝播完了報告
- 設定内容をNotionや社内Wikiに保存
🧾 9. 今後のワークフロー設計に活かす
このトラブルを通して学べたことは、技術ではなく「手順の透明化」こそが防御力ということ。
同じ作業を複数人で行うなら、以下のようにワークフローを整えるのがおすすめです。
▷ ステップ型のワークフロー例（Notion管理用）
- ドメイン切り替え前に、現在のDNSをエクスポートしてバックアップ
- 切り替え予定日・時間をチームに共有
- MXレコードとAレコードの新旧を明示
- 反映確認のタイムラインを設定（3h, 12h, 24hでチェック）
- 復旧後に報告＋再発防止メモを残す
🪶 まとめ
DNS切り替えに伴うメール停止は、
「仕組みを理解していれば冷静に対処できる」トラブルです。
今回の流れをワークフロー化しておくことで、
次に同じことが起きた時は、3分で原因を特定し、24時間以内に復旧できるはずです。
サイト運営者・クリエイター・美容サロン経営者など、
メールを命綱にしているすべての人にとって、
この知識は“資産”になります。
🎤 あなたの「好き」を配信にしてみませんか？
ゲーム・雑談・メイク・歌…
普段の趣味や日常を「ライブ配信」という形で発信してみませんか？
私たちはTikTok公認のライバー事務所として、
配信初心者さんのスタートから運営・収益化まで無料でサポートしています✨
地元・姫路をはじめ、全国から登録OK！
あなたのペースで楽しく活動できます😊
