レンタルサーバーを移転するとき、ホームページだけを見て作業すると「サイトは表示できるのにメールだけ届かない」というトラブルが起こることがあります。
メールを止めないために重要なのは、新サーバー側のメール環境を先に準備し、DNSを切り替えたあともしばらく旧サーバーを残すことです。Webサイトとメールは別々の仕組みなので、移転対象を分けて考えます。
30秒でわかる結論
30秒でわかる結論
- 最初に「Webだけ移すのか」「メールも移すのか」を決める
- Webだけ移すなら、メールサービスを継続する限りMXレコードをむやみに変更しない
- メールも移すなら、新サーバーにメールアドレスを先に作成してからDNSを切り替える
- MX変更後もしばらく旧メールサーバーを解約しない
- DNSキャッシュが残る間は、旧・新の両方にメールが届く可能性を考える
- SPF・DKIM・DMARCなどのメール認証設定も移行する
- 送信・受信・外部宛て・外部からの受信を実際にテストしてから旧環境を終了する
サーバー移転でメールが止まるのはなぜ?
独自ドメインでは、ホームページの接続先とメールの配送先をDNSで別々に指定できます。
| 用途 | 主に関係するDNS設定 |
|---|---|
| ホームページ | A・AAAA・CNAMEなど |
| メール受信先 | MX |
| メール認証 | TXT・CNAMEなど |
サーバー移転時にネームサーバーを丸ごと変更すると、Web用のAレコードだけでなく、メール用のMXやSPF・DKIM・DMARCに関係するDNSレコードも新しいDNS側へ移す必要があります。
典型的な失敗
新しいDNSにWeb用のAレコードだけ設定してネームサーバーを切り替えると、ホームページは表示できても、メール配送先を示すMXレコードがなくなり、受信できなくなる可能性があります。
最初に「Webだけ移すか、メールも移すか」を決める
サーバー移転だからといって、必ずメールサーバーまで移す必要があるわけではありません。 ここを最初に分けると、不要なDNS変更を防げます。
| 移転内容 | MX変更 | 考え方 |
|---|---|---|
| Webだけ移転 | 原則不要 | 現在のメールサービスを継続するなら配送先を維持 |
| Webとメールを移転 | 必要 | 新メールサーバーを準備後に切替 |
| 外部メールを継続 | 原則不要 | Google Workspaceなどをそのまま利用 |
「レンタルサーバー変更=MXレコード変更」ではない
Webサイトだけを新サーバーへ移し、メールは現在のサービスを使い続けるなら、MXレコードを変えない構成があります。 移転前に「Web」と「メール」の契約先を紙やメモに分けて整理してください。
メールを止めないための移転手順
メールも新サーバーへ移す場合は、次の順番で進めると停止リスクを下げられます。
MX・TXT・CNAME・メールアドレス一覧を控える
同じメールアドレスを先に作成する
IMAP移行機能などで既存メールをコピーする
MXと必要な認証レコードを正しく変更する
DNSキャッシュが残る期間を考慮する
複数の外部メールサービスとの間で確認する
STEP1.現在の設定を必ず保存する
作業前に、現在使っているDNSレコードとメール設定を保存します。 スクリーンショットだけでなく、可能なら文字としてコピーしておくと比較しやすくなります。
保存しておきたい項目
- MXレコード
- SPFに関係するTXTレコード
- DKIMに関係するTXTまたはCNAMEレコード
- DMARCレコード
- メールアドレス一覧
- 転送設定
- 自動返信設定
- メーリングリストやエイリアス
- メールソフトの受信・送信サーバー名
- ポート番号と暗号化方式
ネームサーバーを変更する場合は、メール関連だけでなくA・AAAA・CNAMEなどを含むDNSゾーン全体を控えてください。 新DNSへ必要なレコードを移し忘れると、Web以外のサービスにも影響します。
STEP2.DNS変更前に新サーバーへメールアドレスを作る
メールの配送先を新サーバーへ変更してからメールアドレスを作るのではなく、先に受け皿を用意してからMXを変更します。
例
旧サーバーで「info@example.com」「sales@example.com」を使っているなら、新サーバーにも同じアドレスを作成してから切り替えます。
代表アドレスだけでなく、問い合わせフォームの送信先、社員用メール、転送専用アドレスなども一覧化してください。 1つでも作り忘れると、そのアドレス宛てだけ受信できない状態になる可能性があります。
STEP3.過去メールを先に移行する
サーバー上に過去メールを保存している場合は、必要に応じて新サーバーへコピーします。 IMAPを利用している環境では、メール事業者の移行機能やIMAP対応の移行方法を利用できる場合があります。
ただし、DNS切替前に一度コピーしても、その後旧サーバーへ届いたメールは追加で発生します。 そのため、移行機能が差分同期に対応している場合は、切替後にもう一度同期する方法が有効です。
POP利用者は端末内メールにも注意
POPでメールをPCへダウンロードし、サーバーに残さない設定を使っている場合、過去メールが旧サーバーではなく各端末だけに存在することがあります。 サーバー移転前に、メールソフト側の保存状況も確認してください。
STEP4.TTLを確認してからMXレコードを切り替える
DNSにはTTLというキャッシュ時間があります。 TTLの期間中は、外部のDNSサーバーが古いMX情報を保持していることがあります。
TTLが3,600秒の場合
3,600秒 ÷ 60 = 60分
DNSキャッシュ時間の目安は1時間です。ただし、実際の切替時間が世界中で完全に同じになるわけではありません。
移転日が決まっていてDNSサービス側でTTLを変更できる場合は、事前にTTLを短くする方法があります。 ただし、変更前からキャッシュされている情報は、その時点で設定されていたTTLが切れるまで残る場合があります。
TTLを短くする場合は、作業直前ではなく、現在のTTLが一度切れるだけの余裕を持って変更するのが基本です。 利用中DNSサービスに最小TTLや変更制限がある場合は、その仕様を優先してください。
STEP5.MX変更後も旧メールサーバーを残す
ここが最も重要です。 MXレコードを新サーバーへ変更しても、すべての送信元が同時に新しい情報へ切り替わるとは限りません。
DNSキャッシュに古いMX情報が残っている送信元は、旧メールサーバーへ配送することがあります。 そのため、切替直後に旧サーバーを解約すると、その期間に旧側へ届こうとしたメールを受け取れなくなるリスクがあります。
MX変更 → 旧・新サーバーを併用 → 受信状況を確認 → 旧サーバー終了
「何時間残せば絶対安全」という固定時間はありません。 現在のTTL、DNS事業者、移転元・移転先サービスの仕様、送信元側のキャッシュなどによって異なります。
実務では、旧契約を切替当日に終了せず、移転先サービスが案内する併用期間を確保し、その間に旧・新の両方を確認してください。
旧・新の両方に届く期間はどう確認する?
DNS切替中は、送信元によって旧サーバーと新サーバーのどちらへ配送されるかが分かれる可能性があります。
この期間は、旧メールボックスも確認できる状態を維持します。 メールサービスに移行ツールや差分同期機能がある場合は、それを利用すると取りこぼしを減らしやすくなります。
MXの優先度だけで「旧と新へ同時配送」にはならない
MXレコードを2つ登録して優先度を変えても、通常は低い数値の優先MXが利用され、到達できない場合に別のMXが試されます。 旧サーバーと新サーバーの両方へ同じメールをコピーする仕組みではありません。
STEP6.SPF・DKIM・DMARCも移行する
受信できるようになっても、メール認証設定が旧環境のままだと、送信メールの認証に失敗することがあります。
| 設定 | 移転時の確認 |
|---|---|
| SPF | 新しい送信サーバーが許可対象に含まれているか |
| DKIM | 新サービス指定の公開鍵・CNAMEなどを設定したか |
| DMARC | 既存ポリシーを維持し、SPF・DKIMとの整合を確認したか |
古いSPFを丸ごと置き換えない
Webフォーム、外部配信サービス、Google Workspaceなど複数の送信元を利用している場合があります。 新サーバーの値だけを設定して既存の送信元を消すと、別サービスからのメール認証に影響する可能性があります。
STEP7.送受信テストをする
管理画面で「設定完了」と表示されても、実際に送受信できるとは限りません。 移転後は複数方向でテストします。
最低限のテスト
- 外部メール → 独自ドメインメールの受信
- 独自ドメインメール → 外部メールの送信
- 同一ドメイン内での送受信
- PCメールソフトからの送信・受信
- スマートフォンからの送信・受信
- Webメールからの送受信
- WordPressのお問い合わせフォーム通知
- 転送メール・自動返信
可能なら、Gmailなど複数の外部メールサービスを使って確認します。 受信箱だけでなく迷惑メールフォルダも確認し、メールヘッダーでSPF・DKIM・DMARCの認証結果も確認すると確実です。
メールソフトの設定変更が必要な場合もある
メールサーバー自体を変更すると、PCやスマートフォンのメールソフトで使う接続先も変わる場合があります。
| 確認項目 | 例 |
|---|---|
| 受信サーバー | IMAP・POPサーバー名 |
| 送信サーバー | SMTPサーバー名 |
| ポート | 993・995・587・465など |
| 暗号化 | TLS・STARTTLSなど |
| 認証情報 | メールアドレス・パスワード |
同じ独自ドメインのメールアドレスを使い続けても、接続先サーバー名やパスワードが変わることがあります。 社員や店舗スタッフが複数いる場合は、切替日時と新設定を事前に共有してください。
ネームサーバーも変更する場合の注意点
ネームサーバー変更は、MXレコード1つを変更する作業より影響範囲が広くなります。 DNSを管理する場所そのものが切り替わるためです。
新DNS側へ移す代表的なレコード
- A
- AAAA
- CNAME
- MX
- SPFに関係するTXT
- DKIMに関係するTXT・CNAME
- DMARC
- サービス認証用TXT
特に、Webサイトだけを確認して「表示できたから移転成功」と判断しないでください。 メール、サブドメイン、外部サービスのドメイン認証などもDNSを利用している場合があります。
Webだけ移転する場合の最も安全な考え方
メールサービスを変えず、Webサイトだけ移すのであれば、DNS管理先をそのまま維持し、Web用レコードだけ変更できるケースがあります。
例
Web:旧レンタルサーバー → 新レンタルサーバー
メール:Google Workspaceを継続
この場合、メール用MXを変更せず、Web用A・AAAA・CNAMEなど必要なレコードだけ変更する構成が考えられます。
ただし、レンタルサーバー会社の仕様によってDNS管理方法が異なるため、実際の作業前に「ネームサーバー変更が必須か」「個別レコード変更で済むか」を確認してください。
会社サイトでは移転日をどう決める?
会社や店舗では、問い合わせ・注文・予約・請求など重要な連絡がメールに依存していることがあります。 そのため、アクセスが少ない時間帯だけでなく、トラブル時に担当者が対応できる日時を選ぶことが重要です。
個人ブログ
確認:基本
問い合わせ通知が中心なら、新旧メールボックスとWordPress通知を確認します。
会社サイト
確認:厳重
社員用アドレス、代表メール、フォーム、転送、自動返信まで一覧化します。
店舗・予約サイト
確認:厳重
予約通知や自動返信が止まると業務影響が大きいため、実際の予約フローまでテストします。
メールを外部サービスで運用
確認:MX維持
Web移転だけなら、現在のメール用DNSを維持できるかを最初に確認します。
サーバー移転でやってはいけないこと
- 新サーバーにメールアドレスを作る前にMXを切り替える
- ネームサーバー変更時にAレコードだけ移す
- 現在のMX・TXT・CNAMEを保存せずDNSを初期化する
- MX変更と同時に旧サーバーを解約する
- SPF・DKIM・DMARCを確認しない
- メールソフトの接続先変更を利用者へ知らせない
- 管理画面だけ見て実際の送受信テストを省略する
最も重要な考え方
メール移転は「一瞬で旧から新へ切り替わる」と考えず、一定期間は旧・新が並行して存在する移行作業として設計してください。
教科書判定
メールを止めたくないなら「先に新環境を作り、後からDNSを切り替え、最後に旧環境を閉じる」
初心者が最も避けるべきなのは、サーバー移転を「ネームサーバーを変更するだけの作業」と考えることです。
Webだけ移すならメール用MXを維持できるか確認する。メールも移すなら新メールボックスを先に作り、MX変更後もしばらく旧サーバーを残す。 この順番を守るだけでも、メール停止や取りこぼしのリスクを大きく減らせます。
会社・店舗サイトでは、SPF・DKIM・DMARC、フォーム通知、転送、自動返信までテストしてから旧契約を終了してください。
FAQ
Q.サーバーを移転すると必ずメールアドレスも変わりますか?
いいえ。同じ独自ドメインを使い続けるなら、info@example.comなど同じメールアドレスを新サーバーでも作成できます。ただし、メールサーバー名・パスワード・ポートなどの接続設定が変わる場合があります。
Q.MXレコードを変更したら旧サーバーはすぐ解約してよいですか?
おすすめしません。DNSキャッシュに古いMX情報が残っている送信元から、旧サーバーへ配送される可能性があります。旧・新双方の受信を確認し、移転先サービスが案内する移行期間を確保してから終了してください。
Q.Webサイトだけ移転する場合もMX変更が必要ですか?
現在のメールサービスを継続するなら、MX変更が不要な場合があります。Web用レコードとメール用レコードを分けて考えてください。
Q.TTLを短くすればメールは絶対に止まりませんか?
いいえ。TTLを短くするとDNS切替を早めやすくなりますが、設定ミスや新サーバー側の未準備までは防げません。新環境の準備、旧環境の併用、送受信テストも必要です。
Q.古いメールは自動的に新サーバーへ移りますか?
通常、MXレコードを変えるだけでは過去メールは移りません。サービスの移行機能、IMAP移行などを使って別途コピーする必要があります。POPで端末だけに保存しているメールにも注意してください。
まとめ
この記事の結論
- サーバー移転前にWebとメールの移転範囲を分ける
- Webだけ移すならMXをむやみに変更しない
- メールも移すなら新メールボックスを先に作る
- 現在のDNSレコードとメール設定を必ず保存する
- 必要なら過去メールを切替前後で移行する
- MX変更後も旧メールサーバーを一定期間維持する
- SPF・DKIM・DMARCも新しい送信環境に合わせて確認する
- 実際の送受信とWordPressフォーム通知までテストしてから旧環境を終了する
メールを止めないためのポイントは、切替を急ぐことではなく、旧環境と新環境が重なる期間を安全に作ることです。 「新環境を準備 → DNS切替 → 両方確認 → 旧環境終了」の順番で進めてください。
「TTLとは?DNS反映時間との関係をわかりやすく解説」「DNSキャッシュとは?反映されない原因と対処法」「SPFとは?設定方法と確認方法を初心者向けに解説」もあわせて確認してください。