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

ただし、契約を二つにすれば障害や管理まで完全に独立するわけではありません。ドメイン登録やDNSなどが共通なら、そこに問題が起きたときは両方へ影響します。支払いと管理者アカウントも同様です。メール機能を充実させたい、Webの移転にメールを巻き込みたくない、という場合には分ける意味があります。一方、費用と管理の手間は増えるため、少人数で基本的な送受信だけなら一つにまとめる構成も合理的です。

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

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

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

ただし、メール障害の連絡先やアカウント復旧先が、その停止したメールだけでは困ります。復旧用に別の連絡方法を持っておけば、Webとメールを分けた利点を生かしやすくなります。

Webとメールを分けてもドメインは共通です

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

一方、独自ドメインの登録期限と権威DNSは、Webとメールの共通基盤です。ドメインが失効したり、ネームサーバーの設定が失われたりすると、Webもメールも名前解決できなくなる可能性があります。登録者や更新通知先が分からなくなると、別々に契約したサービスがまとめて使えなくなることもあります。ドメインの更新管理は、分離後も共通して必要です。

管理画面の権限も分けて考えます。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. 旧メールの利用を終了する。Webが残るサーバー契約は解約しない

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

メールの必要性に合わせて分ければ良いです

分離が向いているのは、メール容量、共有、検索、迷惑メール対策などで、現在のサービスに不足がある場合です。Webサイトの制作会社が変わっても、社員のメール環境を変えずに済む点も利点になります。

反対に、少人数でメール機能に不満がないなら、分けること自体を目的にする必要はありません。サーバー料金に含まれていたメールが利用者ごとの課金になることもあるため、メールサービスの費用比較と合わせて考えると判断しやすいかと思います。