LASSIC Media らしくメディア
メールサーバー移行先の選び方｜切り替えの段取りと認証設定
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- メールサーバーの移行先は、保守を誰が受け持つかと、過去メールの容量・保存期間から選びます。
- 切り替えは、送信元の棚卸し、TTLの短縮、MXレコードの切り替え、過去メールの移行の順で進めます。
- 送信の口が変わるため、SPF・DKIM・DMARCの設定も移行と一緒に直します。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
社内のメールサーバーが古くなり、保守の期限も近い。ホスティングの契約を見直したいが、移す途中でメールが届かなくなるのが怖い——。自社でメールサーバーを持ってきた会社では、こうした悩みがよく聞かれます。メールサーバーの移行は、社外から届くメールの行き先、社員や機器が送る口、過去のメールを、新しいメールの環境へまとめて移す作業です。
移行先の選び方と切り替えの順番を押さえれば、業務を止めずに進められます。ただし万能な移行先はなく、保守を誰が受け持つかで向き不向きが変わります。本記事では、情報システムの担当者に向けて、移行先の選び方、切り替えの進め方、送信ドメイン認証の見直し、そして外部に頼むときに確認したい点を整理します。
目次
メールサーバー移行とは
総務省は、電子メールの送受信は、インターネット上の多くのメールサーバーが連携して成り立っていると説明しています。*1 メールサーバーの移行は、自社のメールサーバーが受け持っていた役目を、新しいメールの環境へ移す作業です。移す対象は、受信箱の中身だけではありません。
- 受信の届け先：社外から届くメールの行き先を決めるMXレコード（メールの届け先を示すDNSの設定）
- 送信の口：社員のメールソフトに加え、複合機や業務システムが送る通知メール
- 過去のメール：社員ごとのメールボックスに残っている受信・送信の記録
- アカウント：社員のメールアドレス、パスワード、共有のアドレス、転送の設定
- 送信ドメイン認証：自社のドメインから正しく送られたことを受信側に示すSPF・DKIM・DMARCの設定
見落としやすいのは、人以外の送信元です。複合機のスキャン送信や、受注システムの自動返信が古いサーバーを経由していると、切り替えた日から相手に届かなくなります。移行先を決める前に、どの機器とシステムがメールを送っているかを書き出しておくと、後の作業が楽になります。
移行先の選び方
移行先は大きく分けて3つあります。どれが正しいかは会社ごとに違うため、「保守を誰が受け持つか」から考えると選びやすくなります。
| 移行先 | 保守を受け持つ人 | 向いている場面 |
|---|---|---|
| クラウドのメールサービス | サーバーの運用は事業者。アカウントと設定の管理は自社 | 予定表やファイル共有もまとめて使いたいとき |
| ホスティング事業者のメール | サーバーの運用は事業者。メール以外の機能は少ない | 今のメールの使い方を大きく変えずに移りたいとき |
| 自社で新しいサーバーを建てる | サーバーの更新・障害対応・バックアップまで自社 | 社内の規程でメールを社外に預けられないとき |
クラウドのサービスやホスティングを選ぶ場合、IPA（情報処理推進機構）の手引きにあるチェック項目が参考になります。*2 メールの移行で特に確かめておきたいのは次の4点です。
- 稼働率、障害の起きる頻度、障害時の回復目標時間などのサービス品質保証が示されているか*2
- サービスの利用をやめるとき、過去のデータを返してもらう条件が決まっているか*2
- データがどの国や地域のサーバーに保存されるか*2
- 今の過去メールの容量と、社内で決めている保存期間に見合う容量があるか
切り替えの進め方
メールサーバーの移行は、次の4つの段階で進めると、切り替えの日にメールを取りこぼさずに済みます。
- ステップ1：アカウント、過去メールの容量、メールを送っている機器とシステムを書き出す
- ステップ2：新しい環境にアカウントを作り、DNSのTTL（設定を覚えておく時間）を短くしておく
- ステップ3：MXレコードを新しい環境に向け、届け先を切り替える
- ステップ4：過去のメールを移し、古いサーバーをしばらく残してから止める
ステップ2のTTLは、DNSの情報をほかのサーバーが覚えておいてよい時間です。*3 長いままだと、切り替えた後も古い届け先を覚えたサーバーが残り、新旧のサーバーにメールが分かれて届きます。切り替えの数日前に短くしておくと、届け先が早くそろいます。MXレコードには優先度の数値があり、数値の小さいほうが優先されます。*4 新旧の両方を残すときは、この数値で順番を決めます。
過去のメールは、IMAP（サーバー上のメールを読み書きする方式）を使って移すのが一般的です。*5 移したあとは、社員ごとにメールの件数を新旧で比べます。届け先を切り替えた直後は、古い情報を覚えていた送信元から古いサーバーにメールが届くことがあるため、古いサーバーはすぐに止めず、受信できる状態で残しておきます。
SPF・DKIM・DMARCの見直し
送信ドメイン認証は、届いたメールの送信者が名乗るドメインが正しいかを、受信側が確かめるための仕組みです。総務省は、SPFは送信元のIPアドレスを、DKIMは電子署名をもとに、ドメインの正当性を評価すると説明しています。*6 送信の口が変わるメールサーバーの移行では、この設定を一緒に直さないと、自社のメールが迷惑メールとして扱われるおそれがあります。
| 設定 | 移行で直すこと | 気をつけること |
|---|---|---|
| SPF | 新しい環境の送信元を加え、使わなくなった古い送信元を消す | 1つのドメインにSPFのレコードは1つだけ。DNSを引きにいく記述は10個まで*7 |
| DKIM | 新しい環境で署名用の鍵を作り、公開鍵をDNSに載せる | セレクター（鍵ごとの名前）を分ければ、新旧の鍵を同時に置ける*8 |
| DMARC | 移行の前後で、受信側から届く集計レポートを見て、新しい送信元が認証を通っているか確かめる | ポリシーをnoneにすると、受信側に特別な扱いを求めない*9 |
SPFのレコードは、送信元を加えるたびに長くなりがちです。2つ目のSPFレコードを別に作ってしまうと、認証そのものが失敗します。DMARCを段階的に強める進め方やレポートの読み方は、DMARC導入と送信ドメイン認証の整備で扱っています。
外部に頼むときに確認しておきたい点
メールサーバーの移行は、DNS、メールの仕組み、社員の端末の設定が重なる作業です。社内に詳しい人がいない場合は、移行を外部に頼む方法があります。頼む前に、次の点を確かめておきます。
- どこまで頼むか：移行先の選定、アカウントの作成、DNSの切り替え、過去メールの移行、社員への案内のうち、どれを任せるか
- DNSを誰が触るか：ドメインの管理画面に入れる人と、切り替えの日時を誰が決めるか
- 移行の確かめ方：社員ごとのメールの件数を、移行の前と後でどう照らし合わせるか
- 人以外の送信元：複合機や業務システムの送信設定を、誰がいつ変えるか
- 古いサーバーの止め方：いつまで受信できる状態で残し、データをどこへ保管してから止めるか
移行先にMicrosoft 365を選ぶ場合は、テナント名や管理者の権限など、Microsoft 365ならではの決めごとがあります。そちらはMicrosoft 365導入支援で決めておく5つのポイントにまとめています。
まとめ：メールサーバー移行で確かめておきたい3つの点
メールサーバーを移行するうえで、確かめておきたい点は3つに整理できます。第一に、移行先を保守の受け持ちと過去メールの容量から選び、解約時のデータの返し方まで確かめること。第二に、TTLを短くしてからMXレコードを切り替え、古いサーバーをしばらく受信できる状態で残すこと。第三に、SPF・DKIM・DMARCを新しい送信元に合わせて直し、複合機や業務システムの送信設定も忘れずに変えることです。この3点を踏まえておけば、「切り替えた翌日から取引先にメールが届いていなかった」という事態を避けやすくなります。移行の段取りに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
移行にはどのくらいの期間がかかりますか
アカウントの数、過去メールの量、メールを送っている機器やシステムの数で変わります。TTLを短くしてから届け先を切り替えるため、DNSの準備だけでも数日の余裕を見ておくと進めやすくなります。まずは棚卸しをしてから、全体の日程を決めるのがよいでしょう。
過去のメールはすべて移さないといけませんか
必ずしもすべてを移す必要はありません。社内で決めている保存期間に合わせて、新しい環境へ移す期間を決める方法もあります。移さない分は、古いサーバーを止める前にデータを書き出し、必要なときに探せる場所に保管しておきます。
社員のパソコンやスマートフォンの設定は変わりますか
移行先によっては、受信と送信のサーバー名、ログインの方法が変わります。その場合は、端末のメールソフトの設定を直す必要があります。切り替えの日より前に、設定の手順と問い合わせ先をまとめた案内を社員に配っておくと、当日の混乱を減らせます。
メールサーバー移行のご相談
移行先の選定から、DNSの切り替え、過去メールの移行、送信ドメイン認証の見直しまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：総務省「国民のためのサイバーセキュリティサイト」電子メールの仕組み（https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/basic/service/04/）。出典：電子メールの送受信がインターネット上の多くのメールサーバーの連携で実現しているとの記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録7（クラウドサービスの利用の手引き）（https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_7.pdf）。出典：付録7のチェックシートのうち、サービス品質保証（稼働率・障害発生頻度・障害時の回復目標時間）、利用終了時のデータの取扱い条件、データ保存先の地理的所在地の項目を参照（2026年10月確認）
- *3 参考：RFC 1035「Domain Names – Implementation and Specification」（https://www.rfc-editor.org/rfc/rfc1035.txt）。出典：TTL（リソースレコードをキャッシュしてよい時間）の定義を参照（2026年10月確認）
- *4 参考：RFC 5321「Simple Mail Transfer Protocol」（https://www.rfc-editor.org/rfc/rfc5321.txt）。出典：MXレコードの優先度は小さい数値ほど優先されるとの記述（5.1節）を参照（2026年10月確認）
- *5 参考：RFC 9051「Internet Message Access Protocol (IMAP) – Version 4rev2」（https://www.rfc-editor.org/rfc/rfc9051.txt）。出典：IMAPがサーバー上のメールへのアクセスと操作を可能にする方式であるとの記述を参照（2026年10月確認）
- *6 参考：総務省「国民のためのサイバーセキュリティサイト」電子メールとWebサイトにおける対策（https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/admin/05/）。出典：送信ドメイン認証技術（SPFは送信元のIPアドレス、DKIMは電子署名をもとにドメインの正当性を評価する）の記述を参照（2026年10月確認）
- *7 参考：RFC 7208「Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1」（https://www.rfc-editor.org/rfc/rfc7208.txt）。出典：SPFレコードが複数あるとpermerrorになること（4.5節）、DNS問い合わせを伴う記述を10個までに制限すること（4.6.4節）を参照（2026年10月確認）
- *8 参考：RFC 6376「DomainKeys Identified Mail (DKIM) Signatures」（https://www.rfc-editor.org/rfc/rfc6376.txt）。出典：セレクターにより1つのドメインで複数の公開鍵を同時に扱えるとの記述（3.1節）を参照（2026年10月確認）
- *9 参考：RFC 7489「Domain-based Message Authentication, Reporting, and Conformance (DMARC)」（https://www.rfc-editor.org/rfc/rfc7489.txt）。出典：ポリシーnoneの意味と集計レポート（7.2節）の記述を参照（2026年10月確認）
