MXレコードを変更する前に、新しいメールサービスで全利用者の受信箱と共有アドレスを作ってください。MXは新しく届くメールの配送先を変えるだけです。過去メール・メールソフト・転送設定・送信認証までは移しません。新しい環境で受け取れる状態を先に作り、変更後もしばらく旧環境を確認します。

会社のメール移行では、代表アドレスや問い合わせフォームが個人アカウントの確認から漏れやすいです。DNS値を書き換える作業より、どの経路から届くメールを誰が確認するか決める方が停止防止につながります。

MX変更だけではメール移行は終わらない

MXレコードは、外部の送信サーバーが独自ドメイン宛のメールをどこへ渡すか判断するために使います。RFC 5321では、MXの優先度は数値が小さい配送先を先に扱います。複数の値を指定された場合は、新しいメールサービスの案内どおりに名前と優先度を登録します。

MXを変更しても、利用者のメールボックスは自動で作られません。共有アドレス・転送・メーリングリスト・エイリアスも別に準備します。受信拒否や許可の設定も確認してください。旧サービスに保存された過去メールを新環境で見たい場合は、DNS変更とは別のデータ移行が必要です。

送信も別系統です。PCやスマートフォンが使うSMTP設定は、MXを見て自動的に変わりません。Webフォームの送信経路や、複合機と業務システムの通知設定も同じです。受信先の変更と送信元の変更を分けて計画します。

変更前に利用者とメール経路を棚卸しする

最初に、現在存在するメールアドレスと用途を一覧にします。社員の個人アドレスだけでなく、代表・採用・請求・問い合わせ用も対象です。メーリングリストと転送専用アドレスも含めます。誰も使っていないように見えるアドレスでも、Webフォームや取引先のシステムから通知が届いている場合があります。

新サービス側で同じ役割を再現し、利用者へ初期パスワードと設定方法を案内します。切り替え前に新環境へログインできることを確認し、可能なら新サービスから外部アドレスへの送信を試します。管理者アカウントだけで成功しても、一般利用者のライセンスやメールボックスが有効とは限りません。

変更前の確認は次の状態まで進めます。

担当者ごとに任せると、休暇中の利用者や共有アドレスが未確認のまま残ります。変更を実行する人とは別に、利用者一覧と確認結果を集約する人を決めておくと判断しやすくなります。

TTLと現在のDNS設定を前日までに確認する

現在のMX・TTL・SPF・DKIM・DMARCを変更前の記録として保存します。MXには優先度と配送先の組み合わせが必要です。送信認証のTXTは文字列が長いため、スクリーンショットだけでなくコピーできる文字として残します。

TTLを短くする場合は、切り替え直前ではなく、少なくとも現在のTTLが一度満了するだけの余裕を取ります。たとえば元のTTLが24時間なら、変更直前に300秒へ下げても、すでに保存された24時間の回答は消えません。作業日より前に下げ、古いTTLが経過してからMXを変更します。

ネームサーバー自体を同時に変更する計画なら、MX変更とは分けてください。委任先とメール配送先を同時に変えると、レコード不足・キャッシュ・メール側設定を切り分けにくくなります。DNS全体を移す場合は「ネームサーバー変更とは？DNS切り替え前に知るべき基礎」の準備を先に行います。

送信認証はMXと別の作業として用意する

SPF、DKIM、DMARCはMXと目的が異なります。SPFは、そのドメインを使って送信してよいサーバーを示します。DKIMは送信メールへ付けた署名をDNS上の公開鍵で検証します。DMARCはSPFまたはDKIMの結果と、差出人に見えるFromドメインの整合を使います。

新旧サービスから送信する移行期間があるなら、正当な両経路が認証できる状態を設計します。RFC 7208も、SPF変更時には以前の正当なメールが確認される期間を考慮するよう示しています。ただし、v=spf1で始まるTXTを二本作る方法は使えません。新サービスの案内と現在のポリシーを照合し、一つのSPFへ反映します。

DKIMは新サービス側で署名を有効にする操作が必要な場合があります。DNSへ公開鍵を置いただけで完了とせず、実際に送ったメールのヘッダーでdkim=passを確認します。DMARCポリシーを同時に厳しくすると、移行中の未確認経路を拒否する可能性があります。MX変更と認証ポリシー強化は、別の日に評価できるようにします。

MXは指定値へ入れ替え、旧値を予備にしない

準備が完了したら、新メールサービスが指定するMXへ変更します。優先度・末尾のドット・ホスト名の自動補完など、DNS管理画面の入力方法を確認してください。MXの参照先にはIPアドレスではなく、サービスから指定されたホスト名を使います。

「念のため」と古いMXを大きい優先度で残すと、新しい配送先が一時的に応答しない場合に、送信側が古いサービスへ渡す可能性があります。旧環境のアカウントが残っていなければ拒否され、残っていればメールが新旧へ分散します。提供元が明示した構成でない限り、旧MXをバックアップ扱いで残しません。

変更直後に外部からMXを問い合わせ、新しい値と優先度が権威DNSから返ることを確かめます。利用者側のキャッシュには旧MXが残り得るため、この時点では旧サービスを止めません。新旧双方の管理画面で受信状況を確認できる状態を維持します。

外部アドレスとの往復とフォームを試す

社内の同じドメイン同士だけで送受信すると、サービス内部で配送が完結し、公開DNSを通らない場合があります。Gmailなどの外部アドレスから新環境へ送り、新環境から外部へ返信します。件名には試験時刻と宛先名を入れ、遅延や迷惑メール判定も確認します。

切り替え直後の確認項目は次のとおりです。

フォームの通知が届かない場合は、MXを何度も変更する前に送信経路を確認します。WordPressが旧サーバーのローカルメールを使っている可能性があります。SMTPプラグインの旧認証情報や、Fromアドレスと認証ドメインの不一致も確認してください。これらの問題は受信MXだけでは直りません。

旧サービスはキャッシュと業務確認の後に終了する

切り替え後は、旧メールサービスにも遅れて届くメールがないか確認します。古いMXをキャッシュした送信側や、一時的な配送失敗から再試行するサーバーがあるためです。保持期間を一律の時間で決めず、変更前のTTL・旧環境の受信状況・重要メールの確認結果から終了日を判断します。

旧サービスを止める前に、過去メールの移行・アーカイブ・退職者メール・共有アドレスの委任を再確認します。問題がなければ、不要になった旧送信元をSPFから外し、使わなくなったDKIM公開鍵や検証用レコードを提供元の手順に従って整理します。送信経路を止める前に認証だけを消すと、移行中の正当なメールが失敗するため順番が重要です。

最後に変更前後のMX・作業時刻・TTLを運用記録へ残します。送信認証・試験結果・旧環境終了日も必要です。次の担当者が見るべき完了条件は「DNSを変更した」ではありません。外部との送受信・共有アドレス・フォーム・旧環境の残留メールまで確認できたことです。