メール移行チェックリスト: 消失ゼロの切り替え手順

メール移行チェックリストが必要なら、まず次の原則を押さえてください。メール移行は、フォルダーをドラッグ操作で移すだけの作業ではありません。メッセージの状態は刻々と変わり、エイリアス、転送設定、スロットリング、不具合のあるクライアントが存在し、作業中もユーザーはメールを送り続けます。準備不足の切り替えが失敗するのはこのためです。移行後のメール環境をまだ選定している段階なら、まず小規模企業向けビジネスメールをお読みください。移行が決まっているなら、このランブックを使って、何事も起きない移行を目指しましょう。

問題は単純です。多くのチームはメールをコピーし、MXを切り替え、あとはうまくいくことを祈ります。すると月曜になって、創業者のアーカイブ、請求書用の転送設定、実際には五人が同じアカウントにログインしていた共有メールボックスなどの欠落が発覚します。このメール移行チェックリストは、事前調査、先行同期、検証、再試行、ロールバックを一つの運用文書にまとめ、この問題を防ぎます。

最初の一通をコピーする前のメール移行チェックリスト

メール移行チェックリストは、現状を可視化するところから始まります。一バイトでも移動する前に、メールボックス、エイリアス、転送ルール、メールボックス容量、移行元の制限をプログラムで棚卸しする必要があります。事前調査が不十分だと、その後のすべての工程が遅くなり、リスクとコストも増大します。

人事部門のエクスポートや、顧客が先月メールで送ってきた表計算ファイルをうのみにしてはいけません。移行元プラットフォームから直接データを取得し、次の五つの問いに答えられる一覧を作成します。

1. どのメールボックスが存在し、現在もメールを受信しているのはどれか。
2. 各メールボックスには、どのエイリアスと役割アカウントが紐づいているか。
3. ストレージ使用量が突出しているユーザーは誰か。
4. 受信トレイ、メール転送経路、メールボックス単位で有効な転送ルールはどれか。
5. 個人用ではなく、実際には共同利用されている業務用アドレスはどれか。

最後の項目は、一般に考えられている以上に重要です。invoices@、support@、hello@は、切り替え当日までは普通のメールボックスに見えがちです。ところが当日になると、担当者も、ログインしたままの端末も分からず、返信メールが行方不明になります。

問題のあるデータも事前に検査してください。不正なMIME、サイズ超過の添付ファイル、極端に複雑なフォルダー構造を探します。IMAPは多くのデータを移せますが、壊れた移行元データを正常な移行先データに直してくれるわけではありません。また、IMAPで正常に移せないものや、まったく移せないものも把握しておきます。TrekMailの移行機能が対象とするのはメールだけなので、カレンダーと連絡先には別の計画が必要です。この範囲はTrekMailのIMAP移行の概要に明記されています。

例: 移行元のメールボックスに14,200件のアイテムがあっても、二通のメッセージが破損し、80 MBの添付ファイル一件が移行先のポリシー上限を超えているとします。ランブックに「容量に問題なし」としかなければ、この異常を見逃します。「アイテム数の照合と失敗アイテムのログ確認」と定めておけば、ユーザーが気づく前に発見できます。

切り替え設計のためのメール移行チェックリスト

週末の切り替え日程を決める前に、メール移行チェックリストで移行方式を選定します。小さなメールボックスなら一括移行にも耐えられますが、実際の企業環境では難しいのが普通です。過去のメールを先行移行し、直近の変更は最後の差分同期に残します。そして、最も時間のかかるメールボックスもほぼ完了してからDNSを切り替えます。

一般的な方式は次の三つです。

ほとんどの場合、先行移行と差分同期の組み合わせが適しています。実用的なメール移行チェックリストのスケジュールは次のようになります。

1. 切り替え14日前: 古いメールから移行し、処理の遅いメールボックスを特定する。
2. 切り替え7日前: エイリアス、転送ルール、移行先メールボックスの対応関係を確認する。
3. 切り替え2日前: DNSのTTLを下げ、認証をテストし、失敗アイテムのログを確認する。
4. 切り替え当日: MXを変更し、SPFとDKIMを更新し、差分同期を実行してからクライアントを修正する。
5. 切り替え1日後: 件数を検証し、受信と送信をテストしてから、旧環境へのアクセスを無効にする。

DNSの設定を誤ると、メール配送が止まります。少なくとも48時間前にTTLを下げ、移行先のレコードをTrekMailの必須DNSレコードと照合してください。

example.com.        300 IN MX  10 mail.trekmail.net.
example.com.        300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

# DKIM value is generated per domain in the TrekMail dashboard.

MX変更後の最初の24から48時間は、DMARCポリシーを一時的にp=noneにすると、キャッシュが落ち着くまでの間、自らの設定が原因となる拒否を減らせます。移行が安定したら、ポリシーを再び厳格な適用モードにします。Gmail宛てに大量送信する場合、この対応は特に重要です。Googleのメール送信者向けガイドラインでは現在、一括送信者にSPF、DKIM、アライメント、TLS、DMARCが求められています。

先行移行と差分同期のメール移行チェックリスト

メール移行チェックリストの中盤で向き合うべきなのは、期待ではなく物理的な制約です。IMAPはフォルダーごとにメッセージをコピーし、大手プロバイダーは帯域幅と処理量を制限します。古いメールを早めに移し、再試行を制御し、最後の差分処理を切り替え時間内に終わる規模まで小さくする必要があります。

多くの移行が破綻するのはこの工程です。IMAPはメッセージ識別子とメールボックスの状態に依存します。UIDとRFC 3501のUIDVALIDITYに関する仕様により、再インデックスされたフォルダーや破損したフォルダーでは、厄介な再同期が起こることがあります。移行ツールに重複スキップやコンテンツ照合の機能があるなら使用してください。TrekMailのダッシュボードにあるインポートウィザードには重複をスキップするオプションがあり、実際の手順はダッシュボードから移行を開始する方法に記載されています。

本番環境に触れる前にコマンドラインツールでテストする運用担当者は、関連ガイドのimapsyncも開いておくと便利です。

imapsync \
  --host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
  --host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
  --ssl1 --ssl2 \
  --syncinternaldates \
  --exclude 'Calendar|Contacts' \
  --skipsize

週末で完了できると約束する前に、必要な帯域幅を計算してください。GoogleはGmailのIMAP帯域幅制限を公開しており、アカウントごとのIMAPダウンロードには一日2,500 MBの上限があります。Microsoftの仕組みは異なりますが、より寛大というわけではありません。Microsoftによれば、移行性能は一定ではなく、サービスのスロットリングに左右されます。巨大なメールボックスを見つけるのが遅れると、一つだけでスケジュール全体が崩れるのはそのためです。

移行先でできることも現実的に捉えましょう。TrekMailはIMAP専用であり、総合オフィススイートではありません。メール移行中は、むしろそれが利点になります。対象範囲が明確になり、メールを移し、メールを検証した後、カレンダーと連絡先を別に処理できるため、異なる障害領域を混在させずに済みます。

DNS切り替え後の検証に使うメール移行チェックリスト

堅牢なメール移行チェックリストでは、検証を独立した工程として扱い、メールボックス容量をざっと見るだけで済ませません。容量は当てになりません。エンコードが変わり、添付ファイルの処理はプラットフォームごとに異なり、サーバー側のストレージ計算も一貫していないからです。アイテム数、抜き取り確認、テスト送信、失敗アイテムの確認によって、メールが本当に移行を完了したかを判断します。

経営層、共有アカウント、一般ユーザー、特大メールボックスのユーザーという各分類に、簡潔な検証表を使用してください。

このメール移行チェックリストには、旧メールボックスへの残存アクセスを止める工程も必要です。差分同期が完了したら、ユーザーが旧プラットフォームにアクセスできないようにします。そうしないと、古い設定が残ったスマートフォンやOutlookプロファイルが移行元で送受信を続け、メッセージが取り残されます。

TrekMailのクライアント設定は明快です。IMAPホストはimap.trekmail.net、ポートは993、ユーザー名には完全なメールアドレスを使用します。POP3には対応していません。正確な値はTrekMailのIMAPとSMTPの設定ガイドにあります。Outlookが旧サーバーへの接続を手放さない場合は、その場しのぎの修正をやめ、新しいプロファイルを作成してください。

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

再試行、ログ、ロールバックのメール移行チェックリスト

メール移行チェックリストの最後の部分では、計画に異常が生じたときの対応を定義します。最初のメールボックスを処理する前に、再試行のルール、ログ項目、エスカレーション担当者、ロールバックのしきい値が必要です。切迫した状況で決めようとすると、判断を誤ります。

ログには、メールボックス、フォルダー、タイムスタンプ、移行元サーバー、移行先サーバー、処理対象のアイテム数、コピー済みアイテム数、コピー済みバイト数、再試行回数、最終ステータス、人が読めるエラー内容を記録します。そのうえで障害を速やかに分類します。

ロールバックとは、「一人のユーザーから苦情があったので、すべてを元に戻す」ことではありません。本格的なメール移行チェックリストでは、ロールバックの条件を事前に定義します。妥当な条件には、MX変更後に広範囲で受信できない、重要なメールボックスのアイテム数に説明不能な大差がある、移行先の認証障害でテナント全体が利用不能になる、といった事象があります。一方、古い設定が残ったモバイル端末が一台ある、またはパスワードを更新していないユーザーが一人いるだけなら、ロールバックの条件としては不適切です。

ロールバックが必要な場合は、対象を限定します。まずメール配送を復旧し、状況報告は一つにまとめ、すべてのログを保存してください。三つのツールを同時に再起動して、元の障害より大きな混乱を起こしてはいけません。

このメール移行チェックリストがTrekMailで効果を発揮する理由

移行先が、ユーザー単位のセット販売を目的とした環境ではなく、メール専用に構築されたプラットフォームなら、このメール移行チェックリストの実行は容易になります。従来は、ほとんど使わないスイートにユーザー単位で料金を払い、移行を付随作業として扱っていました。新しい方法では、予測可能なストレージ、明確なDNS、作業に適したIMAP移行経路を備えるメール中心のプラットフォームへ移ります。

TrekMailはこのモデルによく合います。独自ドメイン、IMAPメールボックス、キャッチオール、メールボックス転送、サーバー側移行、SPF、DKIM、DMARC設定ウィザード、持ち込みSMTPまたは付属SMTP、APIに対応しています。有料プランはStarterの月額$3.50からで、組み込みの移行ツールは有料プランで利用できます。有料機能を試す場合は、クレジットカードが必要な14日間の無料トライアルがあります。カードなしで始めたい場合は、Nanoプランをいつでも無料で利用できます。

運用面での利点は、共有ストレージと定額の複数ドメイン管理です。特大メールボックスが一つあっても、会社全体にユーザー単位のライセンス費用が課されることはありません。これは、多数のドメインで役割アカウントを運用する代理店、MSP、その他の運用担当者にとって重要です。該当する環境なら、次にTrekMailの複数ドメインのメールホスティングをお読みください。料金と最適なプランについては、TrekMailの料金ページで直接確認できます。

実行手順もより明快です。ドメインを追加し、移行先メールボックスを作成し、サーバー側のIMAP移行を実行し、DNSを検証して、クライアントを切り替えます。POP3を経由する必要も、正体不明の独自コネクターもありません。必要なのは、設定が明示された標準のIMAPとSMTPだけです。

まとめ: メール移行チェックリストは退屈なくらいがよい

最良のメール移行チェックリストとは、一か月後には誰の記憶にも残っていないものです。移行元を棚卸しし、古いメールを先行移行し、意図を持ってDNSを切り替え、差分同期を実行し、件数で検証し、残存アクセスを止め、ロールバックの対象を限定します。これを実践すれば、移行は賭けではなく通常の運用になります。本番メールは本来そうあるべきです。