サイト移行には、大きく分けてサイトのファイルとデータベース、そしてメールサーバーという2つの側面があります。よくあるトラブルのひとつに、MXレコードとウェブサーバーが独立して動きながら連携している仕組みを理解していないことが原因で、メールサーバーが正常に機能しなくなるケースがあります。
実際にはこの2つはアーキテクチャとして独立しているため、サイトのファイルがどこに置かれているか、あるいはどのサーバーがサイトを配信しているかに関わらず、メールは常に設定されたメールプロバイダへ配信されます。
そのため、設定が正しく行われていれば、Kinstaへのサイト移行によりメールサービスが中断されることはありません。この記事では、Kinstaへのサイト移行時に、MXレコードがどのように機能するのかを詳しくご説明します。
独立して動作するMXレコードとサーバー
ドメインネームシステム（DNS）は、サーバーの移行時にも各レコードタイプを個別に管理します。
サーバーを移行する際に変更することになるのは、ブラウザを移行先のサーバーのIPアドレスへ誘導するAレコードです。一方、MXレコードは意図的に変更しない限りそのまま維持されるため、メールサーバーは設定を変更しなくても、これまで利用しているメールプロバイダへメールを引き続き配信します。
Kinstaの移行プロセスでは、移行前のサーバーがトラフィックを処理している間にサイトが複製されます。これにより、両方の環境で同じコンテンツを同時に運用することができます。DNSの伝播が進行している間は、DNSサーバーへの問い合わせ先によって、訪問者ごとに異なるバージョンのサイトが表示されることがあります。この状態が続く時間はTTL値に依存し、通常は数時間程度です。
この期間中も、MXレコードによってメールは途切れることなくメールサーバーへ配信されます。つまり、メールのルーティングはウェブトラフィックとは別のDNS参照経路で処理されています。
3つの移行パターンとMXレコードへの影響
メールのホスティング構成によって、移行時のMXレコードの扱いは異なります。現在メールがどこでホストされているか、そしてサイト移行と同時にメールプロバイダを変更する予定があるかどうかによって、取るべき対応が変わります。
1. メールとサイトが別のサーバーでホストされている場合（最も一般的）
Google WorkspaceやMicrosoft 365などのメールサービスは、ウェブサイトを稼働させるサーバーとは完全に別のインフラ上で運用されています。サイトは1つのプラットフォーム上で動作し、メールは専用のメールサーバーを持つメールプロバイダを通じて処理されます。
Kinstaへ移行する際に変更されるのは、先に触れた通り、訪問者を新たなサーバーへ誘導するAレコードのみです。MXレコードは変更されず、引き続きGoogle WorkspaceやMicrosoft 365を紐づけられます。そのため、移行中も設定を変更することなく、これまでと同じようにメールプロバイダのインフラを通じてメールが配信されます。
Kinstaを利用するCornershop Creativeは、数百のクライアントサイトを管理しています。同社はこれまでに数百件のサイト移行を行ってきましたが、いずれもメールサービスに影響はありませんでした。
これはKinstaがすべてのサイトに推奨している構成です。メールをホスティング環境から切り離しておくことで、サイトの移行やサーバーの更新、インフラの変更を行う際にも、追加の調整を行うことなくメールサービスを継続できます。
2. メールとサイトが同じサーバーでホストされている場合
KinstaのWordPress専用マネージドクラウドサーバーには、メールのホスティングは含まれていません。これはメール配信、スパムフィルタリング、メール認証規格への対応といった処理に特化した専用インフラでメールを運用できるため、望ましい構成といえます。
しかし、一部のサーバーサービスでは、ウェブサーバーとメールのホスティングをセットで提供しています。この場合、メールアカウントがサイトのファイルやデータベースと同じサーバー上に存在するため、メールサービスがホスティング環境と密接に結びついてしまいます。
このような構成から移行する場合は、サイトを移行する前にメールを別のメールプロバイダへ移行するか、メールはそのままにしてサイトのファイルのみをKinstaへ移行するかのいずれかを選択することになります。
移行の前にメールをサードパーティのメールプロバイダへ移行する場合は、メールアカウントの作成、MXレコードの紐付け、メール配信のテストを行ったうえで、Aレコードを変更してサイト移行を進めます。もう1つの方法として、メール用に旧サーバーアカウントを維持することも可能ですが、余計なコストがかかることになるため効率的とは言えません。
3. メールとサイトのサーバーを同時に変更する場合
サイト移行と同時にメールも移行する場合は、新たな設定を本番環境に反映する前に、短いテスト期間を設けて両方のメールシステムを並行して運用する必要があります。
まずは、移行先のメールプロバイダでアカウントを作成し、DNS管理画面でMXレコードを設定します。これらの新たなMXレコードは既存の設定と並行して追加され、最初は優先度を低く設定することで、テスト中に本番メールが新しい環境へ流れないようにします。
次に、MXToolboxなどのツールを使用してメール設定をテストし、レコードが正しく存在しているか、また正しいメールサーバーを指しているかを確認します。
テストメールを送信し、配信時間を確認して、移行先のメールプロバイダを通じて送受信の両方が正しく機能しているかを確認してから変更を行います。
正常に動作していることを確認したら、DNSの変更を行います。具体的には、MXレコードの優先度を更新してメールを移行先のプロバイダへルーティングし、AレコードをKinstaに紐付けます。DNSキャッシュの影響により、一部のメールは旧プロバイダへ配信される場合があるため、最大48時間程度は両方のメールシステムにアクセスできる状態を維持し、遅れて届くメールを受け取れるようにしておくことが重要です。
Kinsta移行時のMXレコード管理
Kinsta上で作成されたサイトには、kinsta.cloudドメインが一時的に割り当てられます。サイトプレビューツールを使用すると、この一時URLにアクセスして、DNSの更新を行う前に移行されたサイトをテストすることができます。
またこのURLでWordPressへのログイン、フロントエンドページの閲覧、フォーム送信、各種機能の確認なども行うことが可能です。その間、本番サイトは元のサーバーを通じて通常どおりトラフィックを処理し続けます。
DNSの伝播を行う前に、問題がないか確認するための検証作業を実施する必要があります。もし問題が見つかった場合でも、この段階で対応すれば本番サイトに影響はありません。すべてが正常に動作していることを確認してからDNSの更新を行います。
Kinstaのカスタマーサポートは、移行後の手順に関するドキュメントや案内を提供しており、質問にも24時間年中無休体制で対応しています。
Kinsta DNSでのメールレコード管理
Kinsta DNSでは、ドメインレコードをレジストラやサードパーティのDNSサービスではなく、MyKinsta上で直接管理できるDNS管理機能を提供しています。これには、メール関連レコードの管理を簡単に行うための機能も含まれています。
Google WorkspaceのMXレコードは簡単に設定可能です。MyKinstaの「DNS」画面でドメインを追加する際、「Gmail MX レコードを追加」を選択すると、必要な5つのMXレコードが正しい優先度とホスト名で自動的に作成されます。
Kinsta DNSに追加済みのドメインの場合は、「DNS」画面に移動して対象のドメインを選択し、ページ上部にある「Gmail MX レコードを追加」をクリックします。これにより、設定を完了する前にGoogle Workspaceの5つのMXレコードを確認できます。
aspmx.l.google.com（優先度1）alt1.aspmx.l.google.com（優先度5）alt2.aspmx.l.google.com（優先度5）alt3.aspmx.l.google.com（優先度10）alt4.aspmx.l.google.com（優先度10）
これらのレコードのTTLは、デフォルトで3,600秒（1時間）に設定されています。これは、世界中のDNSサーバーが更新を確認する前に情報をキャッシュする時間を決めるもので、この設定により、DNSキャッシュの効率と必要時に変更を反映できる柔軟性のバランスが保たれます。
他のメールプロバイダのMXレコードを追加する
Google Workspace以外のメールプロバイダを使用している場合は、手動でMXレコードを設定します。各値は通常、メールプロバイダから提供され、メールサーバーのホスト名や優先度番号が含まれています。
MyKinstaで「DNS」画面に移動し、対象のドメインを選択して、「DNSレコードの追加」セクションの「レコードを追加」をクリックします。レコードタイプとして「MX」タブを選択し、以下の項目を入力します。
- ホスト名：メールアドレスのホスト名を指定（ルートドメインの場合は空欄のままにすることが一般的です）
- 指定先：メールプロバイダのメールサーバーのホスト名を入力
- 優先度：優先度を設定（数値が小さいほど優先度が高くなる）
- TTL（Time to Live）：1時間（推奨デフォルト値）
各項目を設定したら、「DNSレコードを追加」をクリックして設定を保存します。
Microsoft 365では通常、地域のメールサーバーを指す1つのMXレコードを使用します。一方、Zohoでは異なる優先度を持つ複数のMXレコードが必要です。多くのメールプロバイダは複数のMXレコードに対応しているため、それぞれを同じ手順で個別に追加してください。
なお、Kinsta DNSの利用は必須ではありません。ドメイン登録会社や他のDNSサービスでDNSを管理しながら、サイトのみをKinstaでホストすることも可能です。Kinsta DNSを利用すれば、サーバーやメール設定を変更する際のトラブルシューティングや更新作業を簡素化できる場合があります。
よくあるMXレコードの問題とその解決方法
事前に計画や対策を講じていても、問題が発生するかもしれません。例えば、以下のような問題は一般的です。
- CNAMEレコードに紐づいている
- 優先度の値が誤っている
- バックアップサーバーの設定ミス
まず、MXレコードがCNAMEレコードを指している場合、メール配信が失敗する原因になります。メールサーバーはMXレコードを参照した際に、最終的にIPアドレスを持つAレコードまたはAAAAレコードにたどり着くことを前提としています。そのため、MXレコードがCNAMEを指していると参照を正しく解決できず、結果としてメールが送信元に返送されてしまいます。
この問題を防ぐには、MXレコードがAレコードを持つホスト名を直接指すように設定する必要があります。MXレコードはmail.example.comのようなホスト名を指し、そのホスト名にメールサーバーのIPアドレスを含むAレコードが設定されているのが正しい構成です。
優先度の値の設定ミスも、ドメインに複数のMXレコードがある場合にメールルーティングの問題を引き起こします。数値が小さいほど優先度が高くなるため、メインサーバーには10のような値を設定し、バックアップサーバーには20や30などのより大きな値を設定します。これらの値を誤って設定すると、バックアップサーバーがメインサーバーにメールを転送する必要が生じ、配信の遅延につながることがあります。
また、メインのメールサーバーが停止した際に、バックアップサーバーの設定が誤っているとメールを処理できません。存在しないサーバーや適切に構成されていないインフラを指すMXレコードは、バックアップが機能しているかのように見えてしまう原因になります。この問題を確認するには、バックアップサーバーの優先度を一時的に変更してメインとして動作させ、テストメールを送信して配信が正常に行われるかを検証します。
サイト移行を計画する際はメールサーバーの考慮も忘れずに
サイト移行は、特にMXレコードの管理も含めて考える場合、時間を要することがあります。最善策として、移行前にすべてのDNSレコードを記録しておきましょう。優先度の値なども含めて記録しておくことで、DNS設定の完全なバックアップを作成できます。
MyKinstaでは、数クリックでMXレコードを作成できます（Google Workspaceを利用する場合）。移行が完了した後は、すべてが正常に動作しているかを必ず確認しましょう。Kinstaのカスタマーサポートは、このプロセス全体を通して必要なサポートを常時提供しています。
また、KinstaのWordPress専用マネージドクラウドサーバーでは、専門スタッフによる移行サポートに加え、あらゆる規模のサイトに対応できる信頼性の高いインフラと、メール設定を簡単に管理できるDNS管理機能も提供しています。
