Webサーバーの移転、ネームサーバーの変更、Google Workspace や Microsoft 365 への乗り換えのあとにメールが届かなくなった場合、原因の多くは「移行の手順の中で MX やその関連レコードが抜けた・書き換わった」ことです。この記事では、移行作業に特有の誤設定を可能性の高い順に確認し、新旧の DNS を比べながら修正する方法を説明します。読み終えるころには、どの段階で何が失われたかを特定し、安全に元の受信経路を取り戻せるようになります。
MX の値の書式ミス（名前欄の入れ間違い、末尾ドット、IP や CNAME を値に入れるなど）そのものの直し方は、別記事「MXレコードの誤設定を見つけて修正する方法」で扱っています。この記事は移行作業の前後で起きる問題に絞っています。
最初に「今どのDNSが有効か」を確認する
移行作業ではネームサーバーが切り替わるため、どのサービスのゾーンが実際に使われているかが変わります。まずここを確定させます。
# 現在有効なネームサーバー
dig example.com NS +short
# 新しい権威サーバーと古い権威サーバーの MX を比べる
dig @ns1.new-dns.example.net example.com MX +short
dig @ns1.old-dns.example.net example.com MX +short
# メール用ホストの A レコードも新旧で比べる
dig @ns1.new-dns.example.net mail.example.com A +short
dig @ns1.old-dns.example.net mail.example.com A +shortネームサーバー名は例です。dig example.com NS +short で出たものと、移行前に使っていたものに置き換えてください。古い側の結果は「移行前に正しく動いていた状態」の手がかりになります。古い DNS サービスを解約するとこの比較ができなくなるので、原因が分かるまで解約は待つのが無難です。
移行後によくある原因（可能性の高い順）
1. 新しいゾーンにMXが作られていない
ネームサーバーを新しいレンタルサーバーや DNS サービスへ切り替えると、古いゾーンの内容は自動では引き継がれません。Web 用の A レコードだけを作り、MX や TXT（SPF など）を作り忘れるのが最も多いパターンです。DNS サービスによっては既存のレコードを読み取って取り込む機能がありますが、すべてのレコードを拾えるとは限らないため、取り込み結果を古いゾーンと1件ずつ照合します。
古いゾーンのレコードは dig では全件を一覧できない（ゾーン転送は通常拒否される）ので、古い管理画面のエクスポート機能や画面の控えから確認します。今後の移行では、切り替え前にレコード一覧を保存しておくと、この照合がすぐに済みます。
2. メール用ホストのAレコードを新Webサーバーに向けてしまった
MX が mail.example.com を指し、そのホストの A レコードが Web サーバーと同じ IP だった構成では、Web だけを移転したつもりで mail の A レコードまで新サーバーの IP に変えてしまうことがあります。新サーバーでメールを受ける準備ができていなければ、受信は失敗します。メールを旧サーバーに残すなら、mail の A レコードは旧サーバーの IP のままにしておきます。旧サーバーを止める予定なら、先にメールの移行先を決めてから A レコードと MX を切り替えます。
3. CDN のプロキシをメール用ホストに有効にしている
Cloudflare などのプロキシ型 CDN にネームサーバーを移すと、レコードごとにプロキシの有効・無効を選びます。プロキシは Web（HTTP/HTTPS）の通信を中継する仕組みで、メールの通信（SMTP）は中継しません。MX が指すホストのレコードでプロキシを有効にすると、DNS は CDN の IP を返すため、メールサーバーに届かなくなります。MX が指すホストは「DNS のみ」の設定に戻してください。表示名や警告の出方はサービスや時期によって変わります（2026年10月現在）。
4. 新旧のMXが混在している
Google Workspace や Microsoft 365 に乗り換えた際、新しい MX を追加して古い MX を消し忘れると、優先度の関係で一部のメールが古いメールボックスに届きます。「届く日と届かない日がある」「一部の相手からだけ届かない」という症状はこれが典型です。乗り換え先の管理画面に表示された MX の値と優先度だけを残し、古いものは削除します。値はサービス側で更新されることがあるため、昔の手順書ではなく、乗り換え先の管理画面や公式ヘルプに表示された値を使います。
5. 旧サーバーが自ドメインを「ローカル配送」している
外部のメールサービスへ移ったあと、WordPress のお問い合わせフォームや通知メールのうち自ドメイン宛てのものだけが届かない場合は、Web サーバー側の設定を疑います。Web サーバー自身が「このドメインのメールは自分が受け持つ」と認識していると、MX を見ずにサーバー内のメールボックスへ配送してしまいます。
- レンタルサーバーやコントロールパネル型の環境では、メールの配送先を「外部のメールサーバー」に切り替える設定があることが多い（名称は製品ごとに異なる）
- 自分で Postfix を運用している VPS では、
mydestinationなどにそのドメインが含まれていないかを確認する
この場合は DNS を直しても解決しないため、サーバー側の配送設定を変更します。変更前に設定ファイルのバックアップを取ってください。
修正の手順
- 古いゾーンのレコード一覧（MX、メール用ホストの A、SPF などの TXT）を控える
- 新しい権威サーバーで MX を作成・修正し、
dig @新しい権威サーバー example.com MXで値を確認する - MX が指すホストの A レコードが、実際にメールを受けるサーバーの IP を返すことを確認する
- プロキシ型 CDN を使っているなら、そのホストがプロキシ無効になっていることを確認する
- 外部アドレスから自ドメイン宛てにテスト送信し、受信先のメールボックスで届いたことを確かめる
反映には、変更前のレコードの TTL とネームサーバー切り替えそのもののキャッシュ時間がかかります。NS の切り替えはレジストラ側の設定と上位ゾーンのキャッシュが絡むため、MX 単体の変更より長くかかることがあります。移行中は新旧のメールボックスの両方を確認し、取りこぼしたメールが無いかを見ておくと安心です。
移行前にやっておくと防げること
- 切り替えの数日前から、MX とメール用ホストの TTL を短くしておく
- 新しいゾーンを作ったら、切り替え前に
dig @新しい権威サーバーで全レコードを確認する - メールの移行とWebの移行を同じ日に重ねない。切り分けが難しくなるため
- SPF に新しい送信元（新サーバーやメールサービス）を加える。受信できても送信が迷惑メール扱いになることがあるため
まとめ
- 移行後の不達は「新ゾーンへの MX の作り忘れ」「メール用ホストの A の書き換え」「CDN プロキシ」「新旧 MX の混在」「旧サーバーのローカル配送」の順に疑う
- 新旧の権威サーバーに直接 dig を投げて比べると、何が失われたかが分かる
- 乗り換え先の MX の値は、管理画面や公式ヘルプの最新の表示に従う
- 原因が分かるまで古い DNS サービスやサーバーは解約せず、比較できる状態を残す