Zoho→Microsoft 365移行後のメール日付が狂う原因と修正方法

移行後のメールボックスで何が起きているのか

Zoho MailからMicrosoft 365へのドメイン移行が完了しました。Exchange Onlineのインフラが整い、メールボックスはプロビジョニング済み、MXレコードも更新済みです。ところが月曜の朝、あるユーザーがOutlookを開くと、2021年のメールがすべて今日の日付で表示されている。別のユーザーは、去年のメッセージが受信トレイの一番上に並んでいて、まるで今届いたかのようになっている。チケットが続々と入ってきます。

これはOutlookのバグではありません。Zoho固有の問題でもありません。Exchange OnlineへのIMAPマイグレーション全般に起こる、ドキュメント化が不十分な既知の挙動です。なぜ起きるのかを正確に理解することが、適切な修正への第一歩になります。

技術的な根本原因：INTERNALDATEとReceivedヘッダー

IMAPサーバーに保存されたメールは、大きく2つの要素から成ります。メッセージの生コンテンツ（RFC 2822ヘッダー、本文、添付ファイル）と、IMAPサーバーが管理するストレージメタデータ（その中にINTERNALDATEが含まれます）です。メールクライアントがメッセージを表示・並び替えるために使うのは、このINTERNALDATEです。

メッセージ本体に含まれるDate:ヘッダー（RFC 2822）は、送信者がメッセージを作成または送信した日時を表します。一方のINTERNALDATEは、IMAPサーバーがメッセージを受信または保存した日時です。通常、正常なサーバーではこの2つの値は近い値になります。移行後は、話が別です。

IMAPマイグレーションが日付を壊すしくみ

マイグレーションツール（Zoho Migration Wizard、imapsync、BitTitanなど）がZoho MailからExchange Onlineにメッセージを転送するとき、IMAPプロトコルを使います。ツールはZohoに接続してメッセージを取得し、IMAP APPENDコマンドでExchange Onlineに挿入します。ここで問題が発生します。

Exchange Onlineは受信した各メッセージに対して、新しいReceived:ヘッダーをメッセージ先頭に付加します。このヘッダーには挿入時刻、つまり移行日時が記録されます。一部のマイグレーションツールは元のINTERNALDATEをAPPENDコマンドのパラメーターとして渡そうとします。しかし渡さないツールや、渡し方が不正確なツールもあり、その場合Exchange Onlineは受信日時を自動的にINTERNALDATEとして設定します。

結果として、2019年のメールも2022年のメールも、INTERNALDATEが移行週の日付を指すようになります。Outlookはこの値を優先的に読みます。並び替えが崩壊します。

Zoho Migration Wizardの固有の挙動

Zohoは自社プラットフォームから移行するための専用ツール「Zoho Migration Wizard」を提供しています。シンプルな移行には便利なツールですが、管理者向けフォーラムで報告されている挙動があります。移行先サーバーへの挿入時に、元のINTERNALDATEを常に正しく渡せるわけではないのです。

正確に言うと、この問題が顕在化するのは主に、受信メッセージに対してReceived:ヘッダーを必ず付加するサーバーへの移行時です。Exchange Onlineはまさにそういう挙動をします。Zoho Migration WizardがAPPENDパラメーター経由で元の日付を渡せていたとしても、Exchange Onlineが生成したReceived:ヘッダーがヘッダーチェーンの先頭に来てしまい、Outlookはこれを「メールが届いた日時」として使います。

Zohoから移行するためにimapsyncのような汎用IMAPツールを使う管理者も、まったく同じ問題に直面します。場合によってはより深刻です。imapsyncのデフォルト設定はExchange Online向けに最適化されていないからです。（そういえば、同期エラーを探して午前2時にimapsyncのログを一行ずつ読んだことがある人なら分かると思いますが、強力なツールであることは確かでも、エッジケースには手厳しいですよね。）

Outlookが間違った日付を表示する理由

Outlookはメールの日付表示にDate:ヘッダーだけを使うわけではありません。受信トレイの並び替えを含む多くの表示では、IMAP/Exchangeサーバーが提供するINTERNALDATEが使われます。元のDate:ヘッダーはメッセージ内に無傷で存在していますが、INTERNALDATEに優先権を譲っています。

だから「送信日時で並び替え」オプションは、この問題を本当には解決しません。確かに別の日付が表示されますが、並び替えの挙動はOutlookのバージョンや表示モード（スレッドまとめの有無など）によって不安定なままです。送信日ソートは解決策ではありません。最初のクライアント更新で剥がれ落ちる絆創膏です。

問題の実際の規模

中規模のZohoからMicrosoft 365への移行では、組織の規模とメールボックスの使用歴によって、容易に5万から50万件のメッセージが影響を受けます。移行ウィンドウ中に転送されたメールはすべて同じ壊れた日付を持つため、ユーザーが初めてOutlookを開いた瞬間に問題が顕在化します。

「送信済み」フォルダーが最も厄介なことが多いです。2022年3月に送った見積書を探している営業担当が、すべて移行日の日付が付いた何百通ものメールを掘り返す羽目になります。業務上のインパクトは、見た目だけの問題ではありません。

そして誤解されやすい点ですが、この問題は時間が経っても自然には解決しません。INTERNALDATEは挿入時点で固定されます。勝手に修正されることはありません。積極的な対処なしには、メールは壊れた日付のまま永続します。

自力で修正するとなぜ思った以上にリスクが高いのか

気持ちは分かります。元のDate:ヘッダーがメッセージ内に残っているなら、メタデータを修正すればいい。理屈の上では筋が通っています。実際に本番環境の8万通のメールボックスでやろうとすると、壊滅的な結果を招く可能性があります。

自作スクリプトがおそらくうまく扱えないエッジケースをいくつか挙げます：

• S/MIME署名付きメール。署名はヘッダー全体を対象としているため、メッセージ構造を少しでも変更すると暗号署名が無効になります。
• PGP暗号化メッセージ。コンテンツは不透明で、MIMEエンベロープを操作するだけでメッセージが壊れる可能性があります。
• RFC 2047でエンコードされた非ASCIIヘッダー（特殊文字を含む送信者名など）。エンコーディングを正しく処理しないスクリプトでは破損します。
• base64エンコードの添付ファイルで行末が不正なもの、非標準のMIME境界、ネストされたマルチパート構造。
• 有効なDate:ヘッダーを持たないメール（実際に存在します。古いZohoエクスポートに特に多い）。スクリプトがどう処理するか決める必要があります。

50通のテストメールで動いたスクリプトは、何年分の履歴を持つZohoの本番メールボックスでは動きません。しかも、各メッセージの修正が正しく完了していて添付ファイルが欠けていないかを、一通一通確認するにはどうすればいいでしょうか？検証作業は、修正作業と同じくらい複雑です。

クォータの問題もあります。Microsoft Graph経由のExchange Online APIは厳格なレート制限を課しています（あの429 Too Many Requestsエラーです）。10万件のメッセージへのスロットリングなしのバッチ処理は、一時的なブロックや後から診断しにくいサイレントエラーを引き起こす可能性があります。再試行の仕組みがなければ、最初からやり直しです。

Redate.ioがZoho移行後の日付を修正するしくみ

Redate.io（リデイト）は、グローバル管理者権限なしで、標準のAzure ADアクセス許可を通じてMicrosoft 365テナントに接続します。初期スキャンは無料です。Redate.ioは影響を受けるメールボックスを特定し、メッセージのヘッダーチェーンに含まれる値とINTERNALDATEを比較して、日付が誤っているメールの件数を見積もります。

修正には独自のエンジンを使用します。各メッセージのヘッダーチェーン全体を解析し、Zohoのマイグレーションツール（Zoho Migration WizardとZoho移行用に設定されたimapsyncの両方）に固有のシグネチャを特定し、多段階の検証パイプラインを通じて日付メタデータを再構築します。修正された各メールは個別に検証されます。コンテンツの整合性、添付ファイルの保全、RFC準拠が確認されます。元のメッセージは30日間アクセス可能なバックアップフォルダーに保持されます。

再移行は不要です。ダウンタイムもありません。修正がバックグラウンドで実行されている間も、ユーザーは普通にOutlookを使い続けられます。

料金は使い捨てのボリュームベースの一括払いで、サブスクリプションはありません。詳細はサイトで直接確認できます。

知っておくべき関連シナリオ

複数の移行を並行して管理している場合、またはZohoからの移行をサポートするMSPの立場であれば、同じ問題は他のプラットフォームからExchange Onlineへの移行でも発生することを覚えておいてください。メカニズムは同じです。Exchangeが生成するReceived:ヘッダーは、ソースにかかわらずINTERNALDATEを上書きします。

Google WorkspaceからExchange On-premisesからの移行、またはBitTitan MigrationWizやCloudM経由の移行については、Exchange Online移行後のメール日付破損の修正でそれぞれのツール固有の挙動を詳しく解説しています。このテナントで起きるすべてのシナリオを俯瞰するのに役立ちます。

移行に共有メールボックスやExchangeリソース（会議室、設備）が含まれていても、問題は同じです。同じ修正ツールが使えます。OutlookでのExchange IMAP移行による日付修正ガイドでは、テナントへの接続手順を詳しく説明しています。

Zohoからの移行に特にimapsyncを使っているチームは、imapsyncで日付が保持されない場合の修正方法を参照してください。imapsyncの設定オプションと、それでもExchange Online上での問題を避けられない理由を解説しています。

Zoho移行後の日付がOutlookにまだ誤表示されていますか？ Redate.ioで無料スキャンを実行して、対処を決める前に問題の正確な規模を把握してください。