MXレコードを変えると、新しく届くメールの配送先が変わります。変更前に必要なのは、新サービスに受信箱や共有アドレスが用意され、ログインできる状態になっていることです。過去メールやメールソフトの設定は、MX変更だけでは移りません。

この記事では、変更前と直後のチェックリスト、旧サービスを止めるまでの注意点を紹介します。個人のメールだけでなく、代表アドレスやフォーム通知も対象になります。

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

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

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

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

変更前のチェックリスト

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

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

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

見落としやすいのは、休暇中の人の受信箱や、複数人で使う共有アドレスです。新サービスへログインできる人だけでなく、受け取る必要のある宛先がそろっているかを見ると抜けを減らせます。

TTLを下げるなら、元のTTLが切れるまでの時間が必要

現在の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を正しく変更したのに一部のメールだけ使えない場合は、この三つに分けて見ると原因を探しやすくなります。