Outlook：IMAP移行後の受信日付と送信日付の違い

誰もが経験するあの症状

Microsoft 365またはGoogle WorkspaceへのIMAP移行が完了した直後の月曜日の朝。チケットが次々と届きます。「全部のメールが同じ日付になっている」「過去のメール履歴が崩れた」「受信トレイで何も見つからない」。Outlookを開いてみると、確かに何千通ものメールが先週末の日付で表示されています。送信された日付ではなく、移行が実行された日付です。

これはOutlookのバグではありません。IMAPプロトコルと移行ツールの動作仕様から生じる直接的な結果です。ただ、なぜそうなるかを理解するには、少し内側を覗いてみる必要があります。

1通のメールに存在する3つの日付

メールは一見シンプルに見えますが、実際には想像以上に複雑な構造を持っています。ヘッダー、本文、添付ファイル...そして複数のタイムスタンプが共存しています。（生のメールヘッダーを読もうとしたことがある方なら、それがどれほど読みにくいものかご存じでしょう。）

Date:ヘッダー（RFC 2822）

これは送信者がメールを送った瞬間にメッセージへ書き込まれた日付です。RFC 2822で定義されており、次のような形式になります：

Date: Tue, 14 Mar 2023 09:42:17 +0100

このヘッダーはメッセージの本体に刻み込まれており、誰かがメッセージの生データを直接書き換えない限り変更されません。これが厳密な意味での「送信日」です。

Received:ヘッダー（各ネットワーク経由点で追加）

メールが経由するサーバーはそれぞれ、受け取ったタイミングで独自の Received: ヘッダーをメッセージの先頭に追加します。3つのサーバーを経由したメールには3つの Received: ヘッダーが積み重なります。一番新しいものが常に先頭です。例えばこのような形になります：

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

結果として、BitTitan MigrationWiz、CloudM、imapsync、GSMMOといった移行ツールが送信元サーバーから宛先サーバーへメールを移動させる際、これらのツール自身も「ネットワーク経由点」として振る舞います。移行の日時が記録された新しい Received: ヘッダーをスタックの一番上に挿入するのです。

IMAP INTERNALDATE

これが3つ目の日付であり、問題の根源です。INTERNALDATEはメールの内容とは独立して、IMAPサーバー側に保存されるメタデータです。メールボックスにメールが配信（または挿入）された日時を表します。移行ツールがIMAP APPENDコマンドでメールを挿入する際、このINTERNALDATEにどの値を設定するかはツール自身が決めます。多くの場合、ツールは元の日付ではなく移行実行時の日付をそのまま使います。

ここがすべての問題の起点です。

OutlookがなぜINTERNALDATEを表示するのか

Outlookは「受信日時」列の表示にINTERNALDATEを使います。これはデフォルトの動作であり、IMAPの仕様と一致しています。INTERNALDATEはメールボックスへの受信日時を表すものとして定義されているからです。通常のメール（実際に新着したメール）では、INTERNALDATEと Date: ヘッダーの値はほぼ一致しているため、問題は生じません。

ところが移行に失敗した後、インポートされた全メールのINTERNALDATEが2024年6月14日から15日の夜（または移行が実行された日付）を指してしまいます。Outlookはその値を読み込んで「受信日時」列に表示するため、45,000通のメールが同じ夜に受信されたように見えるという壊滅的な状態になります。

正確に言うと、 Received: ヘッダーの先頭（最新のもの）も、IMAP同期モードの一部の設定では表示に影響することがあります。ただし、Outlookの「受信日時」列を決定する主要な要素はやはりINTERNALDATEです。

Outlookで「送信日」列を追加する回避策

ほとんどのIT管理者がこの問題を発見した最初にやることは、クライアント側での回避策を探すことです。実際に1つ存在します。

Outlookではフォルダーの列表示をカスタマイズして、「受信日時」列を「日付」または「送信日時」列に置き換える（または追加する）ことができます。「日付」列は Date: ヘッダーを直接読み込むため、INTERNALDATEは参照しません。移行によって Date: ヘッダーは変更されていないので、元の日付が表示されるようになります。

Outlook（デスクトップ版、Microsoft 365）での手順：メッセージ一覧の列ヘッダーを右クリックし、「表示設定」から列をカスタマイズして「受信日時」を削除し「日付」を追加します。大規模展開ならGPOでの一括設定も可能です。

理論上はこれで見た目の問題は解決します。しかし実際には、これは動脈に貼った絆創膏にすぎません。

この回避策の現実的な限界

モバイルクライアントとWebクライアント

iOS版・Android版のOutlookとOutlook Web App（OWA）には、同じカスタマイズオプションがありません。Windowsデスクトップで設定した表示変更は他の環境には反映されません。スマートフォンでメールを確認しているユーザーは引き続き移行日付を見ることになります。中規模企業であれば、それはおそらくユーザー全体の半分です。

検索機能

Outlookの検索はWindows Searchのインデックス（またはサーバー側のExchange/Microsoft 365インデックス）を使用します。このインデックスは Date: ヘッダーではなく、INTERNALDATEをベースに構築されます。ユーザーが「2022年1月のメール」を検索すると、INTERNALDATEが2022年1月のメールが返ってきます。 Date: ヘッダーが2022年1月のメールではありません。つまり古いメールが日付フィルターから消えてしまいます。列の表示を変えても、これは何も解決しません。

メールのルール設定

Outlookのルール（「○日より前に受信したメール」「○日以降に受信したメール」など）も同様にINTERNALDATEを参照します。日付範囲に基づいた仕分けやアーカイブのルールは、INTERNALDATEが修正されていなければ移行後に正常に動作しなくなります。

コンプライアンスとeDiscovery

おそらくこれが最も深刻な問題です。法的アーカイブやeDiscoveryのツール（例：Microsoft Purview）は、法的要請に対応する際の日付参照としてINTERNALDATEを使います。APPIや各種情報保持義務への対応が必要な企業にとって、INTERNALDATEが破損していると重大な法的問題につながる可能性があります。「ある期間内のメールをすべて提出せよ」という監査要請に対して、正しい結果が返せなくなります。

サードパーティツール

CRM、チケット管理ツール、アーカイバーなど、IMAPやMicrosoft 365/Google WorkspaceのAPIを通じてメールサーバーに接続するものはすべてINTERNALDATEを読み込みます。Outlookの表示を変えても、これらのシステムには何の修正も加わりません。

唯一の本質的な解決策：サーバーレベルでの修正

Outlookでの「送信日」ソートは解決策ではありません。応急処置です。本当の修正はクライアントの表示層ではなく、サーバーのメタデータレベルで行う必要があります。

具体的には、各メールのINTERNALDATEを Date: ヘッダーの元の日付に合わせて修正することを意味します。元の Date: ヘッダーは移行によって削除されておらず、メッセージ内に常に残っています。本来の日付情報はそこに存在しているのです。

Google WorkspaceではGmail APIが internalDate パラメーターを公開しており、このメタデータに直接アクセスできます。Microsoft 365では仕組みが異なりますが、期待される結果は同じです。標準的なIMAPサーバーでも、メッセージ挿入時に日付を指定する方法が仕様として存在します。

ただし、本番環境の数万通のメールに対してこの処理を、データ損失なし、重複なし、スレッドやラベルを壊さずに実行するのは別の話です。S/MIME署名付きメール、複雑なMIME構造、RFC 2047準拠の非ASCII文字エンコーディング、大容量添付ファイル...といったエッジケースを考えると、手作業のスクリプトではとても対応できません。テスト環境の50通で動いたスクリプトが、40,000通の本番メールボックスで通用するとは限りません。APIクォータ超過による429エラー、深夜のネットワークタイムアウト、移行後にMIME構造がすでに一部破損しているメッセージへの対処...これらすべてが本格的なエンジニアリングを要します。

それがまさにリデイト（Redate.io）が行っていることです。独自の修正エンジンが各メールのヘッダーチェーンを解析し、信頼性の高い元の日付を特定して、メッセージ内容には一切触れずにメタデータのみを精密に修正します。修正された各メールは個別に検証されます。また、元のメールはバックアップフォルダーに30日間保存されるため、いつでもロールバックできます。自作スクリプトにはまず存在しない仕組みです。

原因となった移行ツールの特定

この問題はどの移行ツールを使っても同様の症状として現れますが、詳細はツールによって異なります。BitTitan MigrationWiz、CloudM、imapsync、GSMMOはそれぞれ独自のシグネチャを Received: ヘッダーに残します。Redate.ioの解析パイプラインは数百種類の既知の移行ツールシグネチャのデータベースを保持しており、移行によって挿入されたヘッダーと正規の中継チェーンを区別することができます。

どのツールが移行に使われたかわからない場合（別のMSPから引き継いだ環境ではよくあることです）、Redate.ioの無料スキャンが影響を受けているメールボックスを特定し、修正が必要なメール数を見積もってくれます。コミットメントは一切不要です。

ツール別の詳細ガイドもあります：OutlookでのimapsyncによるIMAP日付修正、OutlookでのBitTitan移行による日付修正、OutlookでのCloudM移行による日付修正。

今すぐできること

移行後にこの記事を読んでいるなら、朗報があります。元の Date: ヘッダーは各メールの中にそのまま残っています。本来の日付情報はすべてのメッセージに存在しています。問題はコンテンツではなくメタデータにあります。そしてメタデータは修正できます。

問題の仕組みをさらに深く理解したい場合は、IMAP INTERNALDATE解説 - 日付が壊れる理由もあわせてご覧ください。また、移行後のOutlookの誤った日付を修正する方法では、様々なケースの全体像を把握できます。

メールボックスの日付を修正する準備はできていますか？ Redate.ioで無料スキャンを開始すると、影響を受けているメールを特定し、修正前に対象のボリュームを確認できます。