共有ホスティングからMicrosoft 365移行後の日付破損

誰も教えてくれなかった問題

OVH、Infomaniak、Ionos、o2switchからMicrosoft 365へのメール移行を完了したとします。EAC（Exchange管理センター）の移行ウィザードが一晩中動き、すべてグリーンで、メールボックスも埋まっています。月曜の朝、最初のチケットが届きます。「古いメールが全部今日の日付になっている。」次に2件目。そして10件目。

これはMicrosoft 365のバグではありません。偶然でもありません。IMAP移行の機械的な結果です。そして共有ホスティングからの移行の場合、問題は通常の移行より二倍深刻になることが多いです。その理由を説明します。

IMAPが日付を管理する仕組み（そしてどこでずれるか）

IMAPサーバーに保存された各メールには、2種類の日付情報があります。一方はメッセージ本体に含まれるDate:ヘッダー（RFC 2822で定義）で、メッセージが送受信された日時を示します。もう一方はINTERNALDATEと呼ばれるサーバーレベルのメタデータで、そのメッセージがメールボックスに格納された日時を表します。Outlookなどのメールクライアントはこの値をデフォルトで使ってメールの並び替えや表示を行います。

（ところで、EACでメールの生ヘッダーを読もうとしたことがあれば、それが決して楽な作業ではないことはご存知でしょう。コンテンツにたどり着く前に、20〜30行ものヘッダーが並んでいます。）

IMAP移行ツールがあるメールボックスから別のメールボックスへメッセージを転送する際、移行先でこのINTERNALDATEを再作成しなければなりません。正しく処理するツールもあれば、そうでないツールや制限のあるツールも多くあります。受信側のサーバーは、渡されたものをそのまま保持します。コピーが元の日付を持っていれば、Exchange Onlineはその日付を保持します。つまり日付がおかしくなる場合、見るべきはツールであって、Microsoft 365ではありません。

結果として、移行された各メールは移行日に「受信」されたように見えます。そのメールが2019年のものであっても関係ありません。

二段階の破損：共有ホスティングがなぜ問題を悪化させるか

ここが、OVH、Infomaniak、Gandi、Ionos、o2switchなどの共有ホスティングからの移行で特に深刻になる点です。

これらのホスティング事業者は通常、標準的なIMAP設定のPostfix、Dovecot、またはcPanelを使用した共有サーバーを使っています。多くの中小企業が2010年や2012年頃からメールを蓄積しています。Microsoft 365への移行を決断した時、多くの場合この移行は二段階で発生します。

ステップ1：最初の破損（Microsoft 365に到達する前）

多くのケースで、メールはすでに一度移行を経験しています。会社が数年かけて共有ホスティングを乗り換えてきた場合、例えば2018年にGandiからOVH、2022年にOVHからInfomaniakへといった具合です。各IMAP転送によって、ツールが元の日付を渡さなかった場合、元のINTERNALDATEが転送日にリセットされた可能性があり、一部のツールはさらに、その日付を持つ独自のReceived:ヘッダーを残すこともあります。

Microsoft 365に届く時点で、メールはすでに傷を負っています。元のDate:ヘッダーは無傷です（メッセージ本体の一部で、誰も手を触れません）が、日付メタデータはすでに一度乱されています。

ステップ2：Exchange Onlineへの移行時の二度目の破損

EACのIMAP移行ツール、またはIMAPモードで設定されたBitTitan MigrationWizなどのサードパーティツールが、すでに傷ついたこれらのメールを取り込みます。そのツールも各メールの元の日付を渡さない場合、Exchange Onlineはそのメールを転送日付の下に登録し、それがOutlookで最終的に表示される「受信日付」になります。

2017年3月に送信されたメールは、2層の間違った日付を持つことになります。2022年の移行時に残された移行用ヘッダーと、2024年のMicrosoft 365への移行による受信日付です。Outlookには2024年と表示されます。ユーザーには2024年が見えます。二つの意味で間違っています。

実は、正確に言うと、OutlookはExchange Onlineが記録したINTERNALDATEと存在するヘッダーの組み合わせから表示日付を決定します。ただし、移行ツールが元の日付を渡さない場合、Exchange Onlineへの移行は古い誤りの上に新たな誤りの層を作り出します。

移行ツールとホスティング：リスクの高い組み合わせ

共有ホスティングからの移行でよく見られる組み合わせがいくつかあります。

• OVH / Infomaniak / Ionos + EACのIMAPツール：MicrosoftのネイティブツールはIMAPの大量移行で日付を正しく保持しないことで知られています。
• cPanel（o2switch、LWSなど）+ BitTitan MigrationWizのIMAPモード：IMAPモードのMigrationWizは独自の移行ヘッダーを追加します。結果はMicrosoft 365でのBitTitan移行による日付破損の修正で詳しく解説しています。
• Gandi / Mailcow + imapsync：imapsyncは強力なツールですが、INTERNALDATEの処理は設定に依存します。適切なオプションなしでは日付が保持されません。imapsyncで日付が保持されない場合の修正方法もあわせてご覧ください。
• Outlookでのドラッグ＆ドロップによる手動移行：Outlookで2つのアカウント間でフォルダーをドラッグ＆ドロップした場合、各メールのINTERNALDATEはコピーした日付に書き換えられます。例外なく。

共通点は一つです。これらの方法はすべて、Outlookに表示される日付が実際の日付と一致しないメールをExchange Onlineに届けます。

大規模な自力修正がなぜ危険なのか

問題を理解することと、複雑なフォルダー構造・S/MIME署名付きメール・大容量添付ファイル・ネストされたスレッドを持つ40のExchange Onlineメールボックスに散らばった8,000件のメールを修正することは、全く別の話です。

10件のテストメールでうまく動いているように見えるPowerShellスクリプトが、壊れたMIME境界やRFC 2047エンコードされたヘッダー（送信者名の非ASCII文字に使われる=?UTF-8?B?...?=形式）のせいで、4,237件目のメッセージで静かに失敗することがあります。個別検証の仕組みがなければ、それを知る方法はありません。ただメールが一件消えるだけです。

このタイプの移行でDIYを行う具体的なリスク：

• 挿入ロジックが途中で失敗した場合のメッセージ重複
• マルチパート構造の再構築が失敗した場合の添付ファイル消失
• Outlookでの会話スレッド崩壊（スレッドはReferences:とIn-Reply-To:ヘッダーに依存しており、これが変更される可能性があります）
• 午前3時にMicrosoft Graph APIが429エラー（Too Many Requests）を返し、ロールバックなしで処理が中断される
• 8,000件の修正がすべて正しく適用されたかを確認する簡単な方法がない

そして共有ホスティングからの移行という特殊なケースでは、さらなる難しさがあります。メールには複数層の余分なReceived:ヘッダーが含まれており、一層だけではありません。「最後のReceived:を削除する」だけのシンプルなスクリプトでは不十分です。どのヘッダーがどの移行に対応するかを特定し、どれが本当の元の受信日付を表すかを判断するために、完全なヘッダーチェーンを分析する必要があります。

リデイト（Redate.io）が異なるアプローチをとる理由

Redate.ioでは、各ユーザーが自分のMicrosoftアカウントでサインインするだけで、そのサインインが許可する権限の範囲でメールボックスが開かれます。ポータルでの登録やPowerShellの操作は必要ありません。初回スキャンは無料です。Redate.ioは表示日付が実際の日付と一致しないすべてのメールを特定し、メールボックスごとに正確な見積もりを提供します。

修正は独自の補正エンジンに基づいています。各メッセージの完全なヘッダーチェーンを分析し、使用された移行ツールが何であっても、複数の破損層が重なっている場合でも日付メタデータを正確に再構築します。修正された各メールは個別に検証されます。元のメールは削除されることはありません。ご自身のメールボックス内にある表示可能なフォルダーに、ご自身で削除するまで保存されます。

共有ホスティングからの移行では、Redate.ioの多段階分析パイプラインが二重破損のシナリオを明示的に処理します。最後のReceived:ヘッダーを見るだけでなく、完全な履歴を遡って実際の受信日付を復元します。一般的なMicrosoft 365移行後の日付修正についてはMicrosoft 365移行後のメール日付を修正する方法を、根本的なメカニズムを理解するにはIMAP INTERNALDATE解説 - 日付がずれる理由もご参照ください。

移行前と移行後：対処できる二つのタイミング

状況は二つ、取るべき姿勢も二つです。

まだ移行していない場合。良いニュースがあります。被害を最小限に抑えることは可能です。一部の移行ツール（ExchangeモードのMigrationWizや適切なオプションを設定したCloudM）は他より日付をよく保持します。ただし、最善のケースでも、クリーンな履歴を持たない共有ホスティングからの移行は何らかの痕跡を残す可能性が高いです。移行後、ユーザーにメールボックスを渡す前にRedate.ioを通すことを計画に入れておいてください。

すでに移行済みでチケットが届いている場合。Redate.ioは移行の時期に関係なく、Microsoft 365の既存のメールボックスを修正します。スキャンにより、何かを実行する前に各メールボックスの実際の状態の正確な全体像が得られます。今後同じ問題を避けるために、メール移行チェックリスト：日付トラブルを防ぐ方法もあわせてご確認ください。

OVH、Infomaniak、Ionos、またはo2switchからMicrosoft 365に移行して日付がおかしくなっていますか？ Redate.ioのアカウントを作成して、メールボックスを無料でスキャンし、何を決める前に被害の実際の範囲を正確に確認してください。