Webサーバーとメールサーバーは、同じ独自ドメインを使ったまま別のサービスへ分けられます。Webサイトの接続先はA・AAAA・CNAMEなど、メールの受信先はMXで指定するためです。サイトは現在のレンタルサーバーへ残し、業務メールだけをGoogle WorkspaceやMicrosoft 365へ移す構成もできます。

ただし、契約を二つにすれば障害や管理まで完全に独立するわけではありません。ドメイン登録やDNSなどが共通なら、そこに問題が起きたときは両方へ影響します。支払いと管理者アカウントも同様です。分ける目的と、分離後も残る依存関係を先に確認した方が良いです。

分けるメリットは機能選択と影響範囲の整理にある

Webとメールを同じレンタルサーバーへ置く構成は、契約と管理画面が少なく済みます。一方、メールの保存容量や迷惑メール対策を重視する会社もあります。共同作業や監査機能まで必要なら、メール専用サービスの方が要件に合う場合があります。Webサイトを移転せず、必要な機能だけを選び直せることが分離の一つ目の利点です。

もう一つは、障害時の影響を分けやすいことです。Webサーバーのアプリケーション障害や過負荷が、別基盤のメールボックスへ直ちに及ぶとは限りません。反対に、メールサービスで障害が起きてもWebページは表示でき、別の連絡方法を案内できます。

この利点は「何が別になったか」で決まります。別サービスでも、DNSを変更できる人が一人だけなら運用上の弱点は残ります。復旧用メールが移行対象のメールボックスだけ、請求先カードが一枚だけという状態も同じです。障害分散を目的にするなら、技術基盤だけでなく連絡と復旧の経路も確認します。

DNSを分けてもドメインの管理責任は一つのままです

DNSの標準仕様では、一つの名前へ用途の異なる情報をレコード種別ごとに持てます。Webサイトの接続先を変えずにMXだけを変更できるのは、この仕組みによるものです。メール切り替えのためにネームサーバー全体やWeb用Aレコードまで変更する必要はありません。

一方、独自ドメインの登録期限と権威DNSは、Webとメールの共通基盤です。ドメインが失効したり、ネームサーバーの設定が失われたりすると、Webもメールも名前解決できなくなる可能性があります。登録者とレジストラは会社の管理資料へ残します。DNS提供会社と更新通知先も記録し、最低2名が確認できる状態にします。

管理画面の権限も分けて考えます。Web制作会社にはWebサーバーだけ、メール管理者にはメールサービスだけを任せ、ドメインとDNSは会社が保持する方法があります。外部へ依頼する場合も、誰がどの設定を変更できるかを契約名義と実際の権限の両方で確認します。

MXを変える前に受信先と過去メールを用意する

SMTPの標準仕様では、送信側が宛先ドメインのMXを調べ、その指定先へメールを配送します。MXを新サービスへ向けると、それ以降の受信先は変わります。しかし、利用者や共有アドレスは自動で作られません。転送設定と過去メールも別に移す必要があります。

現在使っているアドレスを、個人用と代表窓口などの役割で分けます。転送とメーリングリストも別に整理します。新サービスへ同じ受信先を作り、外部から受け取れる権限まで確認してからMXを変更します。退職者のアドレスや用途不明の転送は、引き継ぐ理由と終了日を決めます。

過去メールの扱いも先に決めます。業務上必要な期間を新環境へ移行するのか、検索できる形で別に保管するのかを利用者ごとに確認します。旧サーバーを解約してから不足に気づいても、同じ状態へ戻せない場合があります。

フォームや複合機は受信とは別の送信経路です

MXが決めるのは主に受信先です。会社サイトのフォームや複合機などが、どこから送るかは別に確認します。請求サービスとメール配信サービスも送信元の候補です。Webサーバーを残した場合、フォーム通知だけが旧サーバーから送信を続けることがあります。

同じ独自ドメインを名乗る送信元は、SPF・DKIM・DMARCの対象になります。メール専用サービスだけを正規送信元として登録し、Webフォームを見落とすと、正しい通知が認証不一致になる可能性があります。フォーム通知は自社の認証済みアドレスから送り、訪問者のアドレスはReply-Toへ設定する方法を検討します。

送信経路を移すときは、パスワードをフォーム設定へ直接共有するのではなく、サービスが案内するSMTPリレーやAPIの権限を使います。移行後は通知が届いたかだけでなく、送信ログと受信側の認証結果も確認します。

本番切り替えは戻せる単位で進める

MX変更の前後で何を確認するかを分けると、問題が起きた場所を特定しやすくなります。順序を入れ替えると新着メールを受けられない時間が生じるため、本番作業は次の流れで進めます。

  1. 現在のDNS、全アドレス、転送、送信元、旧メールの保存範囲を記録する
  2. 新サービスへ利用者と受信先を作り、管理者と復旧手段を確認する
  3. SPFやDKIMを準備し、フォームなど各送信経路からテストする
  4. 計画した時刻にMXを公式の指定値へ変更する
  5. 複数の外部サービスとの送受信、共有アドレス、フォーム通知を確認する
  6. 新旧の配送ログとメールボックスを確認し、必要な過去メールを移す
  7. 旧環境の依存がなくなったことを確認してから解約する

切り替え直後は、社内同士の送受信だけで完了としません。異なる外部サービスから送り、外部へ返信し、スマートフォンとパソコンでも確認します。件名へ時刻と経路を入れておくと、DNSの反映待ちと設定不備を切り分けやすくなります。

分離後は障害時に残る共通点を記録する

運用資料にはWebとメールを別の行で記録し、契約先と管理者を分けます。障害情報の確認先と問い合わせ先もそれぞれ残します。

そのうえで、共通するドメインとDNSを明記します。支払いと復旧メールも共通なら同じ印を付けます。別サービスという見た目だけでなく、一つの停止がどこまで広がるかを読める資料にすることが大切です。

まず現在のDNSからWeb用レコードとMXを取得し、メールボックスと送信元の一覧を横へ並べてみてください。分離したい理由と、変更後も共有される管理点が見えれば、必要な作業と契約だけを選びやすくなります。