メールアカウント移行：棚卸し、IMAP と段階的切り替え

企業でメールアカウントを移行する作業は、一つの個人用受信トレイのコピーとは異なります。メールは届き続け、利用者は返信し、エイリアスも配送します。DNS の誤りで二つのシステムに配送が分かれることもあります。まず棚卸し、次に事前コピー、最後に切り替えを計画してください。DNS に触れる前にビジネスメールのガイドで全体を確認できます。

PST を書き出す人、Outlook でフォルダーをドラッグする人、全アドレスを普通のメールボックスだと思う人がいます。月曜になって sales@ が受信せず、大きなメールボックスは同期中で、どちらのサーバーが正しい状態か分からなくなります。移行はファイルコピーではなく、稼働中のインフラの切り替えとして扱います。

本ガイドは、管理された手順でメールアカウントを移行する方法を説明します。手動 IMAP、切り替え順序、主要な失敗要因、チームや代理店、MSP 向けの TrekMail の流れを扱います。プラットフォームでスクリプト管理を減らせる場合はありますが、高速化や無停止を保証するものではありません。

メールアカウントを移行するとは

IMAP サーバー間でメールをコピーし、エイリアスや転送を別に再設定して、必要なら自分の管理するドメインの受信先を DNS で変更します。個人の Gmail や Outlook からのコピーで、そのドメインの MX を変更できるわけではなく、元のアドレスも自動では移りません。

この定義は重要です。IMAP は作業の一部しか担いません。フォルダーと対応するメール状態をコピーしますが、周辺機能は別です。RFC 3501 にあるように、IMAP はメッセージのアクセスとメールボックス操作用であり、企業のアカウント情報全体の書き出し形式ではありません。

実際には三つの作業を行います。

1. メールとフォルダー構造をコピーして確認する。
2. 必要な許可を得てエイリアス、配布グループ、転送を再構築する。
3. 独自ドメインの受信先が変わる場合、移行先の準備後に DNS を切り替える。

必要な作業を省けば、移行全体の確認は終わっていません。後からサポート対応になる可能性があります。

IMAP で移るものと移らないもの

移行元とツールが対応していれば、IMAP はメール、フォルダー、通常は既読・未読状態をコピーできます。カレンダー、連絡先、タスク、アプリの署名、クライアント側ルールはコピーしません。利用者が移行先で探す前に、別の移行計画を用意します。

対象範囲を書面で合意してください。TrekMail の文書化された移行は IMAP に基づき、グループウェアの移行を代替しません。そのため、文書は移行元ホスト、ポート、ユーザー名、パスワード、移行先メールボックスを扱い、カレンダーや共有予定表は対象としていません。

次の表を準備の目安にしてください。

最後の項目は見落とされがちです。エイリアスと独立したメールボックスの違いはエイリアスとメールボックスのガイドで確認できます。適切な分類は後の修正を減らす助けになります。

移行前の棚卸し

初回同期前にできるだけ完全な一覧を作り、リスクを抑えます。メールボックス、エイリアス、グループ、転送、容量要件を移行先のオブジェクトと移行の段階に対応付けてください。

ユーザー一覧の書き出しだけでは不十分です。見えにくい機能も調べます。

少なくとも次を確認します。

1. 主要メールボックス：利用中のユーザー、共有メールボックス、役割別のメールボックス。
2. エイリアス：別のメールボックスに届く追加アドレス。
3. 配布リストとグループ：通常の IMAP 受信トレイではない配送オブジェクト。
4. 転送：info@ から owner@ などのサーバー側経路。
5. キャッチオール：維持、制限、停止を意図的に決める。
6. 大きなメールボックス：早めに始めて制限を確認する。

容量の大きなメールボックスは日程全体に影響します。IMAP の制限によって数時間ではなく数日かかる場合があります。長年の添付を含むデータに、測定した試験なしで週末完了を約束しないでください。

例として、金曜に 60 人の切り替えを予定します。役員のメールボックスは 48 GB あり、日曜には 59 人が終わっても、そのコピーは続いています。これは起こり得る計画上のリスクの例で、標準的な所要時間ではありません。事前に考慮する必要があります。

アカウント作成も統一するなら、メールアカウントの一括作成手順のような準備項目を組み合わせてください。移行先の不十分な準備も DNS と同じく問題を起こし得ます。

複数のメールボックスを段階的に移す

一斉切り替えではなく段階を設けます。試験で認証、対応付け、接続を確認し、事前コピーで過去メールをバックグラウンドでコピーします。追加同期で変化を取り込み、DNS 切り替えと調整します。

実用的な順序は次のとおりです。

第 1 段階：試験

IT 担当、試験アカウント、現実的な容量の通常ユーザー一人を小さな対象として選びます。ポート 993 の TLS、証明書チェーンとホスト名、認証情報を確認してください。送信済み、下書き、アーカイブ、独自フォルダーの対応付けも調べます。

第 2 段階：事前コピー

予定した切り替え週末より前に大部分の同期を始めます。MX が変わってから長年のメールを初めてコピーするのではなく、古いデータを先に移行先へ用意します。

第 3 段階：差分同期と切り替え

切り替え前に新規と変更されたデータを同期します。必要なら独自ドメインの MX を変更して新受信を確認し、その後も古い日付の遅着メール、移動、フラグの変化を追加で同期します。キャッシュと再配送のため、旧 SMTP 受信、管理者アクセス、切り戻し手段を維持してください。利用者の作業先は一つにし、安全な双方向同期だと考えてはいけません。

制限、週末の作業、ユーザー対応を計画に入れ、一度の処理だけに頼らない方法です。

imapsync による手動移行

直接制御が必要なら、imapsync のような IMAP 間同期ツールが選択肢です。バージョンと設定によって再試行、フォルダー対応付け、フラグを扱えますが、結果は別途確認します。

Outlook のドラッグ操作、PST 書き出し、記憶頼みのコマンドは追跡しにくい結果になる場合があります。クライアントでは削除を伴う移動ではなくコピーを行い、ローカルデータを先に保護してください。

繰り返せる一括処理、メールボックスごとのログ、定義された追加同期で確認しやすくなります。TrekMail は一部をまとめ、全構成要素を自分で管理する負担を減らせる場合があります。詳しくは管理者向け imapsync ガイドを参照してください。

次は原文のまま保存した例で、直接実行できる検証済みスクリプトではありません。Shebang が無効なので自分の作業用コピーで修正し、パスワード、ログ、高速化、サイズ比較のオプションを導入済みのバージョンで確認してください。ログ有効化のオプションはログファイル名を受け取る指定ではありません。移行先 IMAP ホストは最新のアプリ設定で確認します。単純なカンマ区切り処理は、引用符、カンマ、改行を含む正規の CSV に対応しません。平文認証ファイルの権限を制限し、パスワードをプロセス一覧やログに露出させない対策が必要です。

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

実務上の注意点です。

キャッシュを意図的に使う。対応したモードならメタデータの再読み取りを減らせる場合があります。任意の機能であり方式に合わせて使います。UID は全体共通の識別子ではなく、キャッシュも内容の完全性を証明しません。

必要なら一時フォルダーを使う。分けて保存すると確認しやすくなる場合がありますが、新旧両方で作業する衝突を解決するものではありません。例の設定は移行先のパスを変え、最終的なシステムフォルダーの対応付けや移動・削除の正しい扱いを保証しません。

メールボックス単位のログを残す。どのメールボックスがどこで失敗したかを特定します。無条件の DONE 表示は成功の証明ではありません。終了状態、機密情報を除いたログ、件数、内容、添付、日時、対応付け、フラグを確認します。ファイルの権限を制限し、診断から秘密情報を取り除いてください。削除の破壊的な反映は別に計画して検証する必要があります。

DNS 切り替えは独立した確認が必要

独自ドメインの受信先を変える場合、MX の TTL を早めに下げ、古いキャッシュの期限も考慮します。移行先準備後に切り替えて不要な旧 MX を計画どおり整理し、新受信を確認します。キャッシュと再配送の遅着メールのため、旧受信と追加同期は残します。

同期の終了だけでは配送先は変わりません。独自ドメインの受信は DNS が指定します。個人のプロバイダーアドレスは旧アカウントの維持や許可された転送が必要です。

調整不足だとメールが二つのホストに分かれ、どちらも一部は動いて見えます。データが分散するので、追加同期とユーザーの作業先切り替えを明確にします。

最新の TrekMail 文書とアカウント画面でレコードを確認します。次は例であり、そのまま適用しないでください。正当な全送信サービスの SPF 認可を保持し、対応する DKIM 鍵と実際の署名を検証します。DMARC には表示 From と整合した SPF の成功、または有効で表示 From と整合した DKIM 署名が必要です。移行中に未確認でポリシーを厳しくしないでください。

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

切り替えでは次を確認します。

1. 不要な旧 MX を計画どおり整理した。
2. 適切な新 MX を公開した。
3. DNS 名ごとの一つの SPF ポリシーに必要な送信元を保持した。他の TXT は共存できる。
4. DKIM を公開し、実際の有効な署名を検証した。
5. DMARC を公開し、少なくとも一つの成功した検証が From と整合することを確認した。
6. 試験メールが移行先で受信され、旧側の遅着も追跡している。

切り替え後は配送とエラーを監視します。Gmail への送信が重要なら Google Postmaster Tools は追加情報を提供しますが、全体を網羅しません。最後のコピーだけでなく、受信、送信、継続運用も確認する必要があります。

TrekMail でメールアカウントを移行する

TrekMail の文書化されたサーバー側ツールは、適切な IMAP 接続からコピーします。自分の仮想マシンやスクリプト管理を減らせる場合がありますが、管理者は接続、エラー、フォルダー、追加同期を確認します。

考えられる方法の違いです。

現行の手順を確認します。

1. ドメインを追加して DNS を準備する。MX は事前コピーの確認後に切り替える。
2. 移行先メールボックスを作りログインを試す。
3. 画面で移行を開く。
4. 移行元 IMAP ホスト、ポート、ユーザー名、適切なパスワードを入力する。
5. TrekMail の移行先メールボックスを選ぶ。
6. インポートを実行し、状態と実際の結果を確認する。

文書は IMAP 移行の概要、画面からの移行開始、メールボックスの作成、必要な DNS レコードです。直接インポートは IMAP ユーザー名とパスワードを使い、対話型 OAuth ではありません。Gmail のアプリパスワードは二段階認証とポリシーによります。OAuth 必須の場合は別の対応経路が必要です。

原文は Starter が月額 $3.50 から、Nano が $0、有料には Starter、Pro、Agency、Enterprise があると紹介しています。カード不要の無料 Nano と、クレジットカードが必要な有料プランの 14 日間無料試用は原文の条件なので、現行の内容を確認してください。共有容量は大きなメールボックスの配分を助ける場合がありますが、容量と機能の制限は残ります。

比較には現在の TrekMail 料金を使います。

稼働中のチームの切り替え確認

MX 変更前の確認で、足りないエイリアス、古い DNS、間違ったパスワード、未完了の大容量コピーを見つけられる場合があります。リスクを減らしますが、無損失を保証するものではありません。

変更前に確認します。

1. 全移行先メールボックスが存在し、ログインできる。
2. エイリアス、転送、グループを許可に基づいて設定し検証した。
3. 移行元 IMAP は TLS のポート 993 で接続でき、証明書と名前を確認した。
4. 最大容量のメールボックスは早期コピーして確認した。
5. TTL を前もって下げ、旧キャッシュの期限を考慮した。
6. 旧 MX と切り戻し計画を記録した。
7. 切り替え前後の追加同期を予定した。
8. 利用者は旧側の変更をいつ止めるか理解し、プロファイル削除前に未同期ローカルデータを保存した。
9. 一つの試験メールボックスが受信・送信確認に使える。
10. 切り替え後の監視担当を決めた。

地道な作業ですが重要です。管理された移行は、問題が出てから対応するのではなく、事前に不確実な点を確認します。

まとめ：確認できる手順でアカウントを移す

一つのドメインでも五十でもメールアカウントを移行する原則は同じです。機能を棚卸しし、事前コピーし、必要な DNS を慎重に変更して、切り替え後に配送を検証します。IMAP はコピーを行えますが、計画と完全性の確認を代替しません。

直接制御とツール管理を望むなら手動も選択肢です。頻繁に移行する場合、TrekMail の複数ドメインのプラン料金、共有容量、内蔵 IMAP、管理画面が役立つ可能性があります。適合性と費用は現行の条件と要件によります。Nano を検討するか、有料の移行機能が必要なら料金を確認してください。