サーバー移転で意外とつまずきやすいのが「メール移行」です。
WordPress本体の移行はうまくいったのに、メールだけ送受信できない／一部だけ届かない...というトラブルはよくあります。
この記事では、メール移行だけにテーマを絞って、事前準備〜切替〜確認までを手順化しました。
IMAP/SMTPの設定、DNS（MX/SPF/DKIM/DMARC）の扱い、切替後に起きがちな不具合の原因別チェックまでまとめています。
※WordPressの移行手順・ドメインそのままの全体像（サイト側）は別記事で解説し、ここでは扱いません。
全体の流れ（チェックリスト）も合わせて確認したい方は、下記記事もご覧ください。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
作業が不安な場合は、WordPress・メール・DNS/SSLまでまとめて対応する移行代行もご検討ください。
サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応
まず確認：メール移行で「何が変わるか」
サーバー移転に伴うメール移行は、「メールアドレスは同じでも、中身の行き先・接続先が変わる」作業です。
そのため、手順を間違えると急に受信できない／送信だけ失敗する／一部の端末だけ繋がらないといった状況が起きます。
まずは全体像として、今回の移行で何が変わるのかを整理しましょう。
ここを理解しておくと、後半の「DNS設定（MX/SPF/DKIMなど）」や「IMAP同期」の意味がスムーズにつながります。
- 受信（MX）：どのメールサーバーが受け取るか（受信箱の行き先）が変わる
- 送信（SMTP）：どのサーバー経由で送るか（送信時の接続先）が変わる
- 認証・迷惑メール対策（SPF/DKIM/DMARC）：正しく設定しないと届きにくくなる
- メールデータ：サーバーに残る（IMAP）／端末に残る（POP）で移行方法が変わる
- 各端末・各メールソフトの設定：接続先や暗号化方式が変われば再設定が必要になる
IMAP/POP/WEBメールの違いと移行方針
メール移行の方針を決めるうえで最重要なのが、現在どの方式でメールを使っているかです。
特にIMAPかPOPかで「メールの実体がどこにあるか」が変わり、移行作業も大きく変わります。
ざっくり言うと、IMAPは「サーバーにメールが残る」、POPは「端末にメールが落ちる」方式です。
WEBメールは「ブラウザでIMAP的に見る」イメージで、基本的にはサーバー上のメールを見ています。
- IMAP：メールはサーバーに保存。複数端末で同じ受信箱を共有しやすい（移行時はIMAP同期が基本）
- POP：メールは端末に保存されやすい。端末側にしか残っていないメールがある場合は注意（バックアップ前提）
- WEBメール：サーバー上のメールをブラウザで操作。利用中のメールサーバーが変わればログイン先や設定が変わる
結論：迷ったら「IMAP前提」で考える
いま主流の運用は、PC・スマホなど複数端末で使えるIMAPです。
多くのケースでは、移転前後で一時的に並行運用しつつ、IMAPでメールデータを同期（コピー）し、最後にDNS（MX）を切り替える流れが安全です。
逆にPOP中心で運用している場合は、端末内にしかないメールを守るために、先にバックアップ方針を固めてから進めるのが鉄則です。
移行対象チェック（アカウント／転送／自動返信／共有）
メール移行で事故が起きやすい原因は、「メールアドレスだけ移して、周辺設定を移し忘れる」ことです。
特に、担当者が増えるほど転送・共有・自動返信などが増え、移行漏れが発生しやすくなります。
まずは「何を移す必要があるか」を洗い出して、チェックリスト化しておきましょう。
ここが固まると、後工程（新サーバー側の作成／DNS切替／動作確認）が一気にラクになります。
- メールアカウント：アドレス一覧、パスワード、容量、作成ルール（部署・役職など）
- 転送設定：個人→個人、代表→担当者、複数転送、条件付き転送の有無
- 自動返信：不在通知、問い合わせ自動返信、営業時間外メッセージ
- 共有・配布：共有メールボックス、メーリングリスト、グループ配信
- 迷惑メール対策：受信許可リスト、フィルタ、振り分けルール（端末側ルールも含む）
- 利用端末・ソフト：Outlook、Gmail、iPhone/Android、WEBメールなど（再設定が必要な範囲）
チェックのコツ：代表アドレスと「裏で動いている設定」を先に潰す
問い合わせ@ や info@ などの代表アドレスは、転送・共有・自動返信が複合していることが多く、移行漏れの影響も大きいです。
まず代表系を洗い出し、「誰に届く設計になっているか」まで図にしてから移行に入ると安全です。
また、メールソフト側（Outlookなど）に振り分けルールが残っているケースもあるため、サーバー設定だけで完結すると思い込まないのがポイントです。
DNSの基礎：MX・SPF・DKIM・DMARCとTTL
メール移行の成否は、かなりの割合でDNS設定に左右されます。
「新サーバー側のメール環境は作ったのに、切替後に受信できない／迷惑メール扱いになる／一部だけ届かない」といったトラブルは、MXやSPF等のレコードが原因になりがちです。
ここでは、メール移行で最低限押さえるべきDNSの用語と役割を整理します。
先に全体像を理解しておくと、後半の手順（TTLを下げる→切替→確認）が迷わず進められます。
- MX：メールの「受信先」を指定する（どのサーバーが受け取るか）
- SPF：そのドメインで「送信してよいサーバー」を宣言する（なりすまし対策）
- DKIM：送信メールに電子署名を付け、改ざんされていないことを証明する
- DMARC：SPF/DKIMの結果に基づき、受信側へ「どう扱ってほしいか」を示す
- TTL：DNS情報がキャッシュされる時間（切替の反映スピードに直結）
最低限触るレコード（MX / TXT / A・CNAME）
メール移行では主にMXレコードと、迷惑メール対策に関わるTXTレコード（SPF/DKIM/DMARC）を扱います。
さらに、環境によってはWEBメールや自動設定用の名前（ホスト名）としてA/CNAMEを触ることもあります。
「どのレコードが何のために存在するか」を理解しておくと、DNS画面で迷いにくくなります。
MX：受信先の"行き先"を決める
MXは、あなたのドメイン宛のメール（例：info@example.com）をどのメールサーバーで受け取るかを指定します。
サーバー移転の「切替」として一般的に言われるのは、このMXを旧→新へ向け直す作業です。
MXは複数登録でき、優先度（小さい数字ほど優先）を持ちます。
そのため、誤って古いMXが残っていたり、優先度が逆だったりすると「一部だけ旧サーバーに届く」などの混乱が起きます。
TXT：SPF / DKIM / DMARC は"信頼性"に関わる
SPF/DKIM/DMARCは、受信側（Gmailや企業のメールサーバーなど）が「このメールは正規の送信か？」を判断する材料です。
移行後にメールが迷惑メールに入る／届かない／エラーになるとき、原因がこの周辺にあることが多いです。
- SPF（TXT）：送信元として許可するサーバーを列挙（例：旧サーバーの指定が残ると不整合が起きる）
- DKIM（TXT）：送信メールに付く署名の公開鍵をDNSに置く（新サーバー側で発行した鍵に合わせる）
- DMARC（TXT）：SPF/DKIMが失敗した場合の扱い（none/quarantine/reject）を示す
重要なのは、移行後に「送信は新サーバーなのに、SPFが旧サーバーのまま」などのズレが起きると、受信側が不審と判断しやすい点です。
そのため、MXの切替だけで完了と思わず、SPF/DKIM/DMARCもセットで確認します。
A / CNAME：メール移行でも"補助的に"出てくる
A/CNAMEは本来、Webサイトの接続先（IPや別名）を決める用途が中心ですが、メールでも登場することがあります。
例えば、mail.example.com や webmail.example.com といった接続先ホスト名を用意している場合、A/CNAMEの参照先が変わることがあります。
ただし、この記事の主役はあくまでMXとTXT（SPF/DKIM/DMARC）です。
A/CNAMEは「使っているなら確認する」位置づけでOKです。
切替前にやること：TTLを下げる／反映確認のコツ
DNS切替は「設定した瞬間に全員が新しい設定になる」わけではありません。
DNSは各所でキャッシュされ、反映までの時間差が発生します。ここで関わるのがTTLです。
反映待ちの時間差がある状態でMXを切り替えると、「ある人には届くが、別の人には届かない」などが起きやすくなります。
そのため、切替前にTTLを下げて、反映を早めるのが定石です。
TTLとは：DNSが"どれくらいの時間覚えられるか"
TTLは、DNS情報がキャッシュされる秒数です。
例えばTTLが86400（24時間）のままだと、切替後も最大24時間は古い情報が参照される可能性があります。
メール移行で重要なのは、MXとTXT（SPF/DKIM/DMARC）を切替前に短くしておくことです。
これにより、切替後に新しい設定へ寄っていく速度が上がり、混乱する時間を短くできます。
TTLを下げるタイミングと目安
TTLを下げても、キャッシュはすぐには消えません。
「TTLを下げた設定が行き渡ってから」切替するのがポイントです。
- 切替の前日〜数日前に、MX/TXTのTTLを短くする（例：300〜3600秒など）
- TTL短縮後、一定時間おいてからMXを切替する（短縮前のTTL分は残り得る）
- 切替が落ち着いたら、TTLを戻す（短すぎるとDNS参照が増え運用的に不利な場合がある）
反映確認のコツ：見るべきは「自分のPC」だけではない
DNSの反映確認をブラウザや一部ツールだけで判断すると、「自分の環境では見えている＝全員OK」と誤認しやすいです。
実運用では、複数の場所（外部ネットワーク）から参照されるため、切替直後は揺れが起きる前提で進めます。
だからこそ、メール移行では「並行運用」「送受信テスト」「段階的な確認」が重要になります。
次章では、DNS切替を含む全体の移行手順を、ダウンタイム最小化の流れで解説します。
MXやDNS切替の考え方（ネームサーバー変更・移管の違い含む）は、下記記事で詳しく解説しています。
失敗しない移行手順（ダウンタイム最小化）
メール移行で一番怖いのは、切替の瞬間に「受信できない時間が発生する」ことです。
ただし、手順を組めば、ダウンタイム（実質的な取りこぼし）を最小限にしながら移行できます。
ポイントは、新サーバー側の受け皿を先に完成させたうえで、DNS（MX）切替を「最後」に持ってくること。
さらに、切替前後で送受信テストを行い、問題があれば原因別に切り分けて即対応できる状態にしておきます。
- 事前準備（新サーバー側でメール環境を先に完成させる）
- メールデータ移行（IMAP同期などで旧→新へコピー）
- TTL短縮（切替の反映を早める）
- 切替当日：MX切替→送受信テスト→状況監視
- 切替後：旧環境の停止判断、TTL戻し、最終チェック
事前準備：新サーバー側のメール環境を先に完成させる
ダウンタイム最小化の鉄則は、MXを切り替える前に「新サーバー側で受け取れる状態」を作り切ることです。
先にMXを切り替えてしまうと、受信箱が無い／認証が崩れている／容量が足りないなどで、受信エラーや迷惑メール判定が起きやすくなります。
まずは「新サーバーに、今と同じメール運用を再現する」つもりで準備しましょう。
- メールアカウント作成：対象アドレスを全て作る（容量・パスワード・命名ルールも揃える）
- 転送／自動返信／共有：代表アドレス（info@等）から優先して再現する
- 送信設定の確認：SMTPホスト名／ポート／暗号化（SSL/TLS）／認証方式
- 迷惑メール対策（TXT）：SPF/DKIM/DMARCを新環境に合わせる設計を決める
- 運用端末の棚卸し：Outlook・Gmail・スマホ等、再設定が必要な範囲を把握する
先に"試し送受信"できる状態にしておく
MX切替前でも、新サーバー側のメールアカウントは作成できるため、テストは可能です。
例えば、メールソフトの設定を新サーバー向けに作り、別ドメインのメールアドレス（Gmail等）との送受信テストをしておくと安心です。
ここで送信側（SMTP）の設定ミスや、SSL/TLS周りの相性などを先に潰せるため、切替当日の事故が減ります。
切替当日の流れ：並行運用→MX切替→送受信テスト
切替当日は、やること自体はシンプルですが、順番が重要です。
DNSは反映に時間差があるため、「切り替えた瞬間に100%新環境」にはなりません。だからこそ、並行運用しながら確認していきます。
切替前：TTL短縮と最終バックアップ
前章のとおり、MXやTXTのTTLは事前に短くしておくのが定石です。
併せて、POP利用者がいる場合や重要な受信箱がある場合は、切替直前にバックアップ方針も確定しておきます。
- TTL短縮：MX/TXT（SPF/DKIM/DMARC）を切替前に短くしておく
- メールデータの最終同期：IMAPコピーをもう一度走らせて差分を埋める
- 切替担当と連絡手段：社内連絡（チャット等）を用意し、切替中の問い合わせ窓口を決める
切替：MXを新サーバーへ向ける
ここが切替の本丸です。MXを新サーバーへ向け直します。
注意点は、MXを複数登録している場合や優先度がある場合に、古いMXが残らないようにすることです。
また、同時にSPF/DKIM/DMARCも「送信の実態」に合わせて整合させます。
送信が新サーバーに切り替わるのに、SPFが旧のまま、などのズレがあると到達率が落ちます。
切替直後：送受信テスト（原因切り分けのために順番を固定）
切替後は、思いつきでテストするのではなく、順番を固定して確認します。
「受信」「送信」「外部→内部」「内部→外部」の4パターンを押さえると、問題が起きたときに原因が切り分けやすいです。
- 外部（Gmail等）→自ドメインへ送信して受信できるか（受信＝MX側の確認）
- 自ドメイン→外部（Gmail等）へ送信できるか（送信＝SMTP側の確認）
- 自ドメイン→自ドメイン（同一ドメイン内）で送受信できるか
- 代表アドレス（info@等）の転送／自動返信が想定通り動くか
もしここで詰まった場合は、慌てて設定を触り散らすのではなく、次章の「原因別チェック（受信できない／送信できない）」に沿って確認します。
DNSの反映待ちなのか、SMTP設定ミスなのか、SPF/DKIMの不整合なのかが分かれば、対処は難しくありません。
切替後しばらく：旧環境はすぐに止めない
DNSは完全に行き渡るまで時間差があり、切替直後は旧サーバーに届くメールがゼロにはなりません。
そのため、旧環境は一定期間残し、必要に応じて最終同期や取りこぼし確認を行います。
最後に、運用が安定したらTTLを戻し、端末設定の完了状況を確認して移行完了です。
全体の流れ（チェックリスト）も合わせて確認したい方は、下記記事をご覧ください。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
作業が不安な場合は、WordPress・メール・DNS/SSLまでまとめて対応する、移行代行もご検討ください。
メールデータを移す方法（IMAP同期／端末メールの扱い）
DNS（MX）を切り替えるだけでは、過去メール（受信箱の中身）は自動で移りません。
メールデータをどのように移すかは、「今の運用がIMAPかPOPか」で方針が決まります。
結論から言うと、多くのケースではIMAP同期（旧→新へコピー）が最も安全です。
ただし、POP中心で運用している場合は「端末にしか残っていないメール」を守る必要があるため、バックアップと手順を先に固めてから進めます。
- IMAP運用：サーバー上のメールを新サーバーへコピーする（IMAP同期が基本）
- POP運用：端末内メールが主役。端末のバックアップと移行が必要（焦ってMX切替しない）
- 混在：担当者によってIMAP/POPが混ざることがあるため、個別に方針を分ける
IMAP：フォルダごとコピーする手順（基本パターン）
IMAPは「メールはサーバーにある」前提なので、旧サーバー上のメールを新サーバーへコピーすれば移行できます。
実務上もっとも確実なのは、同じメールソフトに"旧アカウント"と"新アカウント"を両方追加し、フォルダ単位でコピーする方法です。
これにより、受信箱だけでなく、送信済み・下書き・ゴミ箱・自作フォルダなども含めて移しやすくなります。
（環境によっては「同期ツール」や「サーバー側移行機能」が使える場合もありますが、まずはこの基本パターンを押さえるのがおすすめです。）
- 新サーバー側で移行対象のメールアカウントを作成しておく（受け皿を先に用意）
- メールソフト（Outlook等）に、旧アカウント（旧IMAP）と新アカウント（新IMAP）を両方追加する
- 旧アカウント内のフォルダ構成が同期できていることを確認する
- 旧→新へ、フォルダごとにメールをコピー（ドラッグ＆ドロップ等）する
- コピー後、件数や最新メールの日付をチェックして取りこぼしが無いか確認する
- 切替直前に、差分が出るので"最終同期（もう一度コピー）"を行う
注意点：コピーは"移動"ではなく"コピー"にする
移行作業中に旧サーバー側を壊さないために、基本はコピーで進めます。
いきなり"移動"してしまうと、途中でトラブルが起きたときに復旧が難しくなります。
旧環境は切替後しばらく残しておき、安定してから停止判断するのが安全です。
注意点：大量メールは時間がかかる（優先順位をつける）
メール数が多いほど、IMAPコピーは時間がかかります。
その場合は、まず「業務影響が大きいアカウント（代表アドレス）」を先に移し、次に個人アカウントへ、と優先順位を付けると混乱が減ります。
また、切替直前〜直後は受信が増減しやすいため、最終同期（差分コピー）を前後で行うのがコツです。
全体の流れ（チェックリスト）も合わせて確認したい方は、下記記事をご覧ください。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
併せて、WordPressを「ドメインそのまま」で移す際の注意点は、下記記事を参照してください。
POP：端末に残るメールを失わないための注意点
POP運用で怖いのは、端末側にしか存在しないメールです。
「サーバー移転＝サーバーを触れば完了」と思っていると、過去メールが消えたように見える事故が起きます。
POPは設定次第で「受信後にサーバーから削除」されていることがあります。
この場合、旧サーバーには過去メールが残っていないため、移行の主役は"端末のメールデータ"になります。
- 端末内メールがどこにあるか：PC（Outlook等）／スマホアプリ／別PCなどを棚卸しする
- 受信後にサーバーから削除していないか：POP設定（サーバーに残す／残さない）を確認する
- バックアップを先に取る：端末データの退避ができてから切替する
現実的な落としどころ：移行を機にIMAPへ寄せる
POP運用を続けると、端末依存が強くなり、将来の引っ越しでも同じ苦労を繰り返します。
可能なら、移行を機にIMAPへ寄せ、「メールはサーバーに集約」する形にすると運用が安定します。
ただし、IMAPへ切り替える前に端末内メールの取り込み・バックアップ方針が必要です。
「急いでMX切替」より、まずデータを守る方を優先してください。
混在ケースに注意：担当者ごとにIMAP/POPが違うことがある
同じ会社でも、古いPCだけPOP、スマホはIMAP、といった混在がよくあります。
この場合は「全員同じ手順」で進めるのではなく、アカウントごと・端末ごとに方針を分けるのが安全です。
次章では、受信できない／送信できないときの原因別チェック（特にSMTPや認証周り）を解説します。
送受信できない原因別チェック（よくある詰まりポイント）
切替後に「送受信できない」となっても、原因はだいたいパターン化されています。
重要なのは、闇雲に設定を触るのではなく、"受信できない"のか"送信できない"のかを分けて順番に切り分けることです。
DNSの反映待ちなのか、MXの設定ミスなのか、SMTPの認証や暗号化なのか、SPF/DKIM/DMARCの不整合なのか。
ここを特定できれば、対応はシンプルになります。
- 受信できない：MX／優先度／反映（TTL）／容量・迷惑メール／転送の問題が多い
- 送信できない：SMTP認証／ポート／SSL(TLS)／From（送信者）不一致が多い
- 一部だけおかしい：端末ごとの設定差、DNS反映差、旧環境が残っている、が多い
受信できない：MX未反映／優先度ミス／容量・迷惑メール
受信トラブルは、まず「どこに届いているのか」を確認するのが最優先です。
MX切替直後は、DNSの反映差で旧サーバーに届くメールが残ることがあります。これ自体は異常ではありません。
ただし、長時間続く場合や、特定の相手からだけ届かない場合は、MXや転送、迷惑メール判定、容量などを疑います。
まず確認：旧サーバーに届いていないか／迷惑メールに入っていないか
「受信できない」と言われたとき、実は別の場所に届いているだけ、というケースがよくあります。
まずは以下を確認してください。
- 旧サーバー側のWEBメールで受信できていないか（切替直後はここに届く可能性がある）
- 新サーバー側のWEBメールで受信できていないか（新側には届いているが端末だけ未設定の可能性）
- 迷惑メールフォルダ／隔離（フィルタ）に入っていないか
- 代表アドレスの場合、転送先に届いていないか（転送の向き先違いの可能性）
よくある原因1：MXが未反映／優先度が逆／古いMXが残っている
受信の行き先はMXで決まります。
特に多いのが、古いMXが残ったまま、もしくは優先度（小さい数字が優先）が逆になっているケースです。
これが起きると「送信者によって届く場所が変わる」「一部のメールだけ旧に届く」といった状態になりやすくなります。
- MXが新サーバーの指定になっているか（ホスト名の打ち間違いにも注意）
- MXが複数ある場合、優先度の順番が意図通りか
- 旧サーバーのMXが残っていないか（意図しないバックアップMXは混乱の元）
- TTLを下げたか／切替直後は反映差がある前提で、一定時間は様子を見る
よくある原因2：容量オーバー／受信制限／転送設定の漏れ
新サーバー側のメールボックス容量が小さいと、切替直後に容量オーバーで受信できないことがあります。
また、代表アドレス（info@など）では転送設定の漏れや向き先ミスが起きやすいです。
- 対象メールボックスの容量が満杯になっていないか
- 転送設定（旧→新、新→担当者など）が移行漏れしていないか
- 自動返信が有効なままでループしていないか（条件次第で発生）
よくある原因3：迷惑メール判定（SPF/DKIM/DMARCの不整合）
受信そのものはできているが迷惑メールに入る、あるいは相手側で拒否される場合は、SPF/DKIM/DMARCの不整合を疑います。
特に移行直後は「送信経路が新サーバーに変わったのに、SPFが旧のまま」などのズレが起きやすいです。
迷惑メール関連は相手側の環境にも左右されるため、切替直後は「取引先（企業ドメイン）」「Gmail」など複数宛先でテストして状況を把握するのがコツです。
送信できない：SMTP認証／ポート／SSL(TLS)設定／From不一致
送信トラブルは、ほとんどがSMTPの設定に原因があります。
受信（MX）が正しくても、送信（SMTP）が合っていないと「受け取るだけのメール」になってしまいます。
「送信ボタンを押すとエラーが出る」「一部の端末だけ送れない」「送れるが相手に届かない」など、症状によって見るポイントが変わります。
まず確認：SMTPホスト名・ポート・暗号化・認証（4点セット）
メールソフトの送信設定は、次の4点が揃っていないと失敗します。
新サーバーの案内（マニュアル）を見ながら、必ず一致させます。
- SMTPサーバー名：例）mail.example.com など（旧のままになっていないか）
- ポート：例）587 / 465 / 25 など（プロバイダや環境で制限がある場合あり）
- 暗号化：SSL/TLS または STARTTLS（設定の組み合わせがズレると失敗しやすい）
- SMTP認証：ユーザー名（メールアドレス）とパスワードで認証するか
よくある原因1：パスワード違い／SMTP認証がOFFになっている
「受信できるのに送信だけできない」は、SMTP認証が原因のことが多いです。
端末側でSMTP認証がOFF、またはパスワードが古いままになっていないか確認します。
特に複数端末で使っている場合、どれか1台だけ古いパスワードのまま、ということがよくあります。
よくある原因2：ポートと暗号化（SSL/TLS）の組み合わせが不一致
例えば「465はSSL」「587はSTARTTLS」など、サーバー側の推奨に合わせる必要があります。
ポートだけ合っていても、暗号化方式が違うと接続できずエラーになります。
端末によって表記が違うため、設定画面では「SSL/TLS」「TLS」「STARTTLS」などの選択肢をよく確認してください。
よくある原因3：From（送信者）不一致／別名送信の制限
送信はできるが届かない、あるいはエラーになる場合、Fromアドレス（送信者）が不一致の可能性があります。
例えば、SMTPはuserAで認証しているのに、差出人をinfo@にしていると、サーバー側が拒否することがあります（なりすまし対策）。
代表アドレスを複数人で使う場合は、「共有アカウントとして認証する」「別名送信を許可する設定があるか」など、運用設計とセットで確認しましょう。
送れるが届かない：迷惑メール判定（SPF/DKIM/DMARC）も確認
送信自体は成功しているのに相手に届かない／迷惑メールになる場合は、SPF/DKIM/DMARCの不整合が関与していることがあります。
送信が新サーバーに変わったら、SPFの送信許可先も新サーバーに合わせるなど、DNS側の整合性を取りましょう。
次章では、主要メールソフト別に「どこを設定すべきか（Outlook／Gmail／スマホ）」のポイントを整理します。
作業が不安な場合は、WordPress・メール・DNS/SSLまでまとめて対応する移行代行もご検討ください。
サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応
MXやDNS切替の考え方（ネームサーバー変更・移管の違い含む）は、下記記事で詳しく解説しています。
主要メールソフトの設定ポイント（Outlook／Gmail／iPhone/Android）
メール移行の最後の詰めは、各端末・各メールソフトの設定です。
MXやサーバー側が正しくても、端末が旧設定のままだと「自分だけ送受信できない」が発生します。
ここでは利用が多い「Outlook」「Gmail（アプリ含む）」「iPhone/Android標準メール」を中心に、設定時の要点をまとめます。
迷ったらまず、受信（IMAP）と送信（SMTP）の接続先が新サーバーになっているか（ホスト名・ポート・暗号化・認証）を確認してください。
- 受信（IMAP）：IMAPサーバー名／ポート／暗号化
- 送信（SMTP）：SMTPサーバー名／ポート／暗号化／SMTP認証
- ユーザー名：多くは「メールアドレス全体」
- 差出人（From）：認証ユーザーと不一致だと送信エラーになる場合がある
Outlook（Windows/Mac）：移行で一番つまずきやすいポイント
Outlookは利用者が多い一方で、プロファイルや資格情報の保存があるため、移行後に古い設定が残って詰まることがあります。
うまくいかない場合は設定をちょこちょこ触るより、新規でアカウントを追加したほうが早いケースもあります。
特に多いのが「受信はできるのに送信だけできない」パターンです。
IMAP（受信）とSMTP（送信）のサーバー名が旧のままになっていないか、最優先で確認しましょう。
- 受信（IMAP）／送信（SMTP）のサーバー名が新サーバーの案内通りか
- SMTP認証が有効か（「送信サーバーは認証が必要」系の項目）
- ポートと暗号化（SSL/TLS / STARTTLS）の組み合わせが正しいか
- 同期が遅い場合、しばらく待っても増えないなら設定先（旧/新）を再確認する
Gmail：取り込み（受信）と送信（別名）のどちらで使っているか確認
Gmailは「Gmailに取り込んで読む」運用と、「別名（差出人）で送る」運用で、チェック箇所が変わります。
送信が止まったときは、Gmail側に残っているSMTP設定が旧サーバーのままになっていないかを疑います。
また、Gmailで受信が止まったように見えるときは、「そもそも新サーバーに届いているか」をWEBメールで確認し、次にGmailの取り込み（POP/転送）設定を見直す流れが安全です。
- 別名送信を使っている場合：SMTPサーバー／ユーザー名／パスワードが新サーバーのものか
- From（差出人）とSMTP認証ユーザーの不一致で弾かれていないか
- Gmail取り込み（POP/転送）運用の場合：取り込み元が旧サーバーのままになっていないか
iPhone/Android：スマホだけ繋がらない場合は"自動設定のズレ"を疑う
スマホは自動設定が便利な反面、サーバー移転後に古い接続先を掴み続けることがあります。
「PCはOKなのにスマホだけ送れない／受信できない」は非常に多いパターンです。
まずはアカウント設定で受信（IMAP）と送信（SMTP）を開き、サーバー名・ポート・SSLの有無・認証を確認します。
うまくいかないときは、端末内にしか残っていないメールが無いことを確認した上で、アカウントを削除→再追加したほうが早いケースもあります。
- 受信（IMAP）／送信（SMTP）のサーバー名が新サーバーになっているか
- SSL/TLS（またはSTARTTLS）とポート番号が新サーバーの案内通りか
- ユーザー名がメールアドレス全体になっているか
- 送信サーバーで認証がONか（端末によって項目が深い場所にある）
まとめ：メール移行は「DNS」と「IMAP同期」を押さえれば事故が減る
サーバー移転のメール移行は、やることが多そうに見えて、実はポイントが絞れます。
事故が起きる原因の多くは、DNS（MX/SPF/DKIM/DMARC/TTL）とメールデータ移行（IMAP同期）のどちらか、または両方の取りこぼしです。
逆に言えば、ここさえ押さえれば、切替当日に「急に送れない／届かない」という混乱を大きく減らせます。
最後に、実務で使えるチェックポイントをまとめます。
- DNSはMXだけで終わらない：SPF/DKIM/DMARCも「送信の実態」に合わせて整合させる
- TTL短縮→切替：切替前にTTLを下げ、反映差による混乱時間を短くする
- IMAP同期は"コピー"で進める：旧環境を壊さず、切替直前・直後に差分同期を入れる
- POP運用は端末メールが主役：サーバーだけ触ると「過去メールが消えた」事故になりやすい
- 切替当日は順番が命：新側の受け皿完成→最終同期→MX切替→送受信テスト→監視
- 送れない/届かないは原因別に切り分け：受信＝MX/反映/容量/迷惑、送信＝SMTP/認証/暗号化/From
- 端末設定を1枚にまとめる：IMAP/SMTPの設定情報を共有すると問い合わせ対応が激減する
最小手順（迷ったらこの順番で）
「何から手を付けるべきか迷う」場合は、まずは下記の順番で進めると失敗しにくいです。
特に、MX切替は最後にするのが鉄則です。
- 新サーバーでメール環境を完成（アカウント／転送／自動返信／送信設定）
- IMAPで旧→新へメールデータをコピー（必要なら複数回で差分を埋める）
- MX/TXTのTTLを短縮（切替の反映を早める）
- 切替当日：最終同期→MX切替→送受信テスト（外部→内部／内部→外部）
- 安定後：旧環境の停止判断、TTL戻し、端末設定の完了確認
「自信がない」「社内で止められない」なら無理に一発で切り替えない
メールは業務の生命線なので、少しでも不安がある場合は、無理に一発勝負にしないのが安全です。
代表アドレスや重要部署のアドレスから優先して移行し、段階的に完了させるだけでも事故は減らせます。
この記事のチェック項目で詰まる場合は、今どの段階で何が起きているか（受信／送信／端末のみ／全員）を整理すると、原因が絞れます。
最後まで落ち着いて進めれば、メール移行は十分にコントロール可能です。
全体の流れ（チェックリスト）も合わせて確認したい方は、下記記事をご覧ください。
サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト
作業が不安な場合は、WordPress・メール・DNS/SSLまでまとめて対応する、移行代行もご検討ください。
サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応
MXやDNS切替の考え方（ネームサーバー変更・移管の違い含む）は、下記記事で詳しく解説しています。
サーバー移転のドメイン設定｜DNS切替・ネームサーバー変更・移管の違いと手順
併せて、WordPressを「ドメインそのまま」で移す際の注意点は、下記記事を参照してください。
（※本ページはプロモーションが含まれています。）
- 広告
- 広告
