メールのホスト移行：IMAP と確認手順

メールを別のホストへ移行する作業は簡単に思えます。ところが、同じメールボックスが二度取り込まれたり、送信済みメールの履歴が見当たらなくなったりすると事情が変わります。多くの手順書はこの問題を飛ばし、メールを単なるファイルのように扱います。実際の移行はそれだけではありません。

コピーするのは、稼働中に変化する IMAP データです。二つのサーバーでフォルダーの規則、UID の扱い、送信済みフォルダーの定義が異なる場合があります。誤った前提によって、空に見えるフォルダー、重複する会話、新旧システムに分散したメールが生じることがあります。

確実に進めるには、段階的な IMAP 同期、明確なフォルダー対応付け、切り替え後の厳密な確認が必要です。プロバイダー、価格、管理権限まで含めた計画には、まずビジネスメールのガイドを参照してください。この記事は移行作業そのものに焦点を当てます。

TrekMail へ移る場合は、最新の IMAP 移行の概要を読み、移行元に応じて Gmail または cPanel のガイドを選びます。原文は有料プランのサーバー側 IMAP 移行と月額 $3.50 からの価格、カード不要の無料 Nano、そして有料プランの 14 日間無料トライアルを紹介しています。現在の料金、機能、試用条件を確認してから計画してください。

メールを別のホストへ移すと、何が起きるのか

要点は、IMAP ツールが旧メールボックスにログインし、フォルダーとメッセージを読み取って新メールボックスへコピーすることです。フォルダー名の統一、移行元にある重複の整理、DNS 切り替え時期の調整が自動的に行われるとは限りません。それぞれを手順に組み込む必要があります。

IMAP 移行は二つのメールシステム間のコピーです。純粋なコピー操作では移行元アカウントを保持し、移行先にメッセージのコピー、フォルダー、ツールとプロバイダーが対応する既読・未読などのフラグを作成します。連絡先、カレンダー、ルールはこの IMAP コピーの対象ではありません。両サーバーがメールをどう識別するかも重要です。

RFC 3501 に記載された IMAP の仕組みでは、各フォルダーにメッセージの UID と UIDVALIDITY があります。UID が有効なのは、そのフォルダーと対応する UIDVALIDITY の範囲内であり、全体や異なるサーバーで共通する識別子ではありません。ツールはこれらと保存した対応関係を使う場合があり、状態が変わると既存のコピーを認識できなくなる方式もあります。

そのため、最初の同期が正常に見えても、次の同期で問題が起きる場合があります。画面に「完了」と出ただけで、ユーザーに移行全体の完了を約束してはいけません。

ホストの移行でメールが重複する理由

要点は、ツールが同じメッセージを確実に識別できなくなると重複が起こり得ることです。UIDVALIDITY の変更、移行先フォルダーの再作成、Gmail のラベルを通常フォルダーとして扱うことなどが原因になります。結果は照合方式によりますが、既存メールを新規と判断して再コピーする場合があります。

UIDVALIDITY の落とし穴

フォルダーごとの UID 対応関係を保存するツールもあります。再インデックスが必ず UID を変えるわけではありませんが、フォルダーの再作成、実際の UIDVALIDITY 変更、ツールの保存状態の喪失で対応関係が使えなくなる場合があります。すべてのツールが同じ方式ではありません。imapsync は通常 Message-Id と Received を照合し、UID を使うモードではローカルのキャッシュを利用します。異なるサーバーの UID が同じだと仮定するものではありません。

RFC 3501 の原則では、同じ UIDVALIDITY の下で UID は安定し、関連する変更は UIDVALIDITY によって検出できなければなりません。UIDVALIDITY が変わったら、保存した UID 対応関係を未確認のまま使い続けることはできません。適切な再照合がなければ、次の同期で数千通を再び取り込む可能性があります。

例として、初回は受信トレイから 38,000 通をコピーします。タイムアウト後に管理者が再実行しますが、移行元か移行先のフォルダーは夜間に再作成されていました。古い UID 対応関係を利用できず、照合方式によってはさらに 38,000 通をコピーしてしまいます。

Gmail のラベルをどう扱うか

Gmail のラベルは、一般的なフォルダー型 IMAP と異なります。一つのメッセージに複数のラベルを付けられ、アーカイブしたメールは「すべてのメール」に残ります。Google の Gmail ヘルプも、複数ラベルと、アーカイブが受信トレイからメールを外しても「すべてのメール」には残す仕組みを説明しています。

[Gmail]/All Mail とラベルのフォルダーを計画なく取り込むと、同じメールが移行先の複数フォルダーにコピーされる場合があります。容量が増え、ユーザーが混乱することもあります。ただし、複数のコピーはラベルを表現するための意図的な設計でもあり得ます。移行先で必要な見え方を先に合意してください。

手動で Gmail を移行するなら、TrekMail の Gmail からのインポートをアクセス準備の出発点にできます。アプリパスワードの利用可否は二段階認証、アカウント、組織ポリシーによります。TrekMail の文書にある直接インポートは IMAP のユーザー名とパスワードを使い、対話型 OAuth には対応しません。適切な直接認証情報が利用できない場合は、別の OAuth 対応ツールやプロバイダーが認める方法を検討してください。

CLI ツールでは次の例を確認用に使えますが、どの環境にも安全に適用できる完成済みの移行コマンドではありません。

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

ドライランはメールをコピーせず、後の本文転送全体を検証するものでもありません。Message-ID は欠落や重複があり得るため、それだけでは確実な照合を保証できません。「すべてのメール」を除外すると、ほかの取り込み対象ラベルがないアーカイブ済みメールを漏らす可能性があります。アーカイブ全体の取り込みを別途計画し、確認してください。暗号化接続と証明書を検証し、実際のパスワードをコマンド履歴やプロセス一覧に残さないようにします。運用の詳細は imapsync ガイドを参照してください。

移行後にフォルダーが見当たらない理由

要点は、フォルダーが別の階層に入ったり、システムフォルダーではなく通常フォルダーになったり、メールアプリが想定と異なる形で表示するプレフィックスを持ったりする場合が多いことです。本当に取り込まれていない可能性もあるため確認が必要です。

名前空間と区切り文字の違い

IMAP サーバーごとに階層の区切り文字と名前空間が異なります。INBOX.Sent のようにドットを使うもの、Inbox/Sent Items のようにスラッシュを使うもの、INBOX. プレフィックスを要求するものがあります。

取り込み前または取り込み中の対応付けが不適切だと、階層が変わる場合があります。Project.Alpha が Project の子フォルダーになり、システムフォルダーが独自フォルダーとして表示されることもあります。スマートフォンのアプリが別のフォルダーを購読し、本来のフォルダーを表示しない場合もあります。

送信済みフォルダーの名前が違う

移行では送信済みメールが見えないと、特に不安を招きます。あるホストは Sent に保存し、別のホストは Sent Items を使い、さらに別のホストは Sent Messages と表示します。

旧フォルダーを移行先のシステムフォルダーに対応付けず通常フォルダーとしてコピーすると、既定の送信済みフォルダーが空のままになる場合があります。データが別の場所にあっても、ユーザーには長年のメールが消えたように見えます。

移行元フォルダー	移行先システム	確認が必要な対応例
`INBOX.Sent`	Exchange / Microsoft 365	`Sent Items`
`Sent Messages`	Dovecot / 標準 IMAP	`Sent`
`[Gmail]/Sent Mail`	標準 IMAP	`Sent`
`INBOX.Trash`	Exchange / Microsoft 365	`Deleted Items`

移行元が共有ホスティングなら、TrekMail の cPanel やほかのホストからの移行に一般的な IMAP 接続情報の例があります。接続準備を助けますが、実際のログイン、名前空間、特殊用途フォルダー、クライアント設定の確認は必要です。表の対応付けは例であり、そのまま適用できるとは限りません。

メール移行を 3 段階で計画する

要点は、三段階の同期でリスクを管理することです。先に過去のメールをコピーし、切り替えの前後で差分同期を行い、MX 変更後も必要な追加同期を続けます。停止時間と重複のリスクを抑えやすくなりますが、無停止や重複なしを保証するものではありません。

過去のメールの同期。最初に古いメール、例えば 30 日より前のものをコピーします。ユーザーが旧システムを使っている間に、大部分のデータを転送できます。
差分同期。新規または変化したデータを追加で同期します。取り込み済みの履歴との照合が重要です。切り替え中の移動や、古い日付を持つ遅着メールも対象にし、日付の範囲だけで判断しないようにします。
切り替えと追加同期。事前確認後に MX を変更します。旧サーバーのメール受信と管理者の同期アクセスを残してください。DNS キャッシュと配送の再試行によって、TTL 経過後も旧ホストに届くメールがあります。

DNS の誤設定は旧ホストへの配送継続や拒否を招くことがあります。切り替え中は TrekMail の必要な DNS レコードを参照してください。以下は例です。最新文書とアカウント画面で値を確認し、正当な送信サービスの SPF 認可を保持して、有効かつ整合した DKIM 署名を検証します。移行と同時に DMARC を無確認で厳格化しないでください。

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

旧ホストへのユーザーのアクセスと書き込みを制限するのは、結果の確認とクライアントの切り替えが済んでからです。SMTP 受信、管理者による追加同期、切り戻し手段はより長く必要になる場合があります。新旧両方で作業を続けると、受信メールや新しい送信済みメールが分かれ、移行後も突き合わせが必要になります。

段階的な方法は代理店やマネージドサービス事業者にも役立ちます。複数ブランドや顧客ドメインでは、コピーだけでなく作業の調整が課題です。複数ドメインのメールホスティングに向いたプラットフォームは支援できますが、移行管理の全作業を自動でなくすものではありません。

メール移行後の確認項目

要点は、メール件数、最古と最新のメールの日付、フォルダー階層を確認することです。総容量だけを信用しないでください。圧縮、インデックス、添付ファイルの処理で表示容量が変わっても、メールが欠けているとは限りません。

1. 容量だけでなく件数を比較する

移行元の受信トレイが 4,502 件なら、同じ対象範囲と合意した除外条件の下で、移行先も 4,502 件が目安です。容量は変わり得ますが、同数でも完全性の証明にはなりません。メッセージ、本文、添付、フラグ、日付、フォルダー対応も比較します。Gmail は一意のメールとラベルごとのコピーを区別して数えてください。

2. 最古と最新のメールを確認する

日付順に並べ、受信トレイと送信済みなどの主要フォルダーで最古と最新のメールを比較します。最古がなければ過去メールの同期、最新がなければ差分同期や切り替え後の追加同期を調べます。フィルターや対応付けの問題も確認してください。

3. 意図しない場所のフォルダーを探す

最上位の INBOX.Sent、残った [Gmail] フォルダー、複数の送信済みフォルダーを探します。不適切な対応付けの兆候になり得ますが、合意した移行先の構造と照合して判断します。

4. 実際の受信と送信を試す

外部メールボックスから送信し、移行先アカウントから返信します。受信、フィルターや隔離の有無、返信が正しい送信済みフォルダーに保存されたかを確認します。一度のテストで実際の全配送経路が確認できるわけではありません。

5. 新しいクライアント設定を確認する

データが正しくコピーされても、接続先が旧サーバーのままなら移行に失敗したように見えます。切り替え後は最新の TrekMail IMAP・SMTP 設定でアプリを更新します。新プラットフォームが受信しているのに見えない場合は、ログイン、フォルダー購読、フィルターも調べてください。

だからこそ、移行とプロバイダー変更は一緒に計画する必要があります。Titan Email の代替サービスの記事も、サービス変更の観点から同じ点を扱っています。メールボックスのコピーは変更全体の一部です。

手動の方法と TrekMail での管理

要点は、手動移行には繰り返し作業と個別の例外が多くなる場合があることです。サーバー側 IMAP 移行、適切な重複照合、共有ストレージ、集中管理で負担を減らせる場合がありますが、現在のプランと実際の移行元・移行先の対応状況によります。

従来構成で起こり得ること	TrekMail の方法、現行条件の確認が必要
ユーザー単位の料金では追加メールボックスの費用が増える場合がある	プラン単位の料金、過去の例では月額 $3.50 から
管理者がメールボックスごとに手作業する場合がある	対応機能の範囲でドメイン、メールボックス、転送、移行を集中管理
容量がユーザーごとに固定される場合がある	適用されるドメイン・メールボックス制限内で共有ストレージを利用
手動 IMAP スクリプトと独自のフォルダー対応付け	対応する有料プランのサーバー側 IMAP 移行
DNS 設定情報がメモや画面画像に分散する場合がある	SPF、DKIM、DMARC の案内を含む DNS 手順、検証は引き続き必要

小規模チームは管理負担を減らし、代理店は費用を見積もりやすくなる場合があります。管理者は五つの場所に分かれた作業を一か所にまとめられるかもしれませんが、従来の全方式が劣るという意味ではありません。現在の TrekMail 料金を確認してください。無料 Nano と有料プランの 14 日間無料トライアルは原文の説明であり、現在の条件が適用されます。

まとめ

メールを別のホストへ移行する際に重複、フォルダーの欠落、停止のリスクを抑えるには、単なる一括ファイル転送ではなく、管理された IMAP 切り替えとして扱います。先にフォルダーを対応付け、Gmail のアーカイブ全体を取り込む計画を立て、段階的に同期し、件数だけでなく内容も確認します。結果とクライアント変更を確認してから旧サーバーへのユーザーアクセスを停止し、必要な受信と追加同期は残してください。

移行後のホスティングに TrekMail を検討するなら、trekmail.net から始めてください。複数ドメインのプラン料金、共有ストレージ、内蔵 IMAP 移行の現在の条件を確認します。ユーザー追加時の費用や上限はプランによります。すべての移行でデータ損失や停止がないこと、追加費用が生じないことを一律に保証するものではありません。