送信日ソートは解決策ではない

どのフォーラムでも見かける定番アドバイス

「移行後にメールの日付がおかしい」と検索すると、最初の回答はほぼ決まっています。「受信日ではなく送信日でソートしてみてください。」Microsoftのフォーラム、Google Workspaceのサポートスレッド、Reddit、Spiceworksの議論、どこでも同じアドバイスが繰り返されています。本来はサーバー側のデータ問題であるにもかかわらず、これがデフォルトの回答になってしまっています。

悪意のあるアドバイスではありません。Outlookでソート列を「受信日」から「送信日」に変えると、確かにメールの表示順は変わります。移行日と同じ日付が並んでいたメールが、突然本来の時系列に並び直されます。一見すると、問題が解決したように見えます。

でも、解決していません。

なぜ解決したように見えるのか

見た目の改善

ユーザーがOutlookのビューを「送信日」ソートに変えると、受信トレイはすぐに正しく見えます。2020年のメールが2023年のメールより前に並ぶ。同じ日付が1万件並んでいた状態からすれば、劇的な改善です。

1つのビュー、1台のデバイスでだけ機能する

送信日ソートの回避策が有効なのは、ちょうど1か所だけです。変更を加えた、そのデバイスの、その特定フォルダのビューだけ。別のフォルダに移動するとビューが元に戻る場合があります。別のデバイスでメールを確認すれば、設定は引き継がれません。

機能しない理由、すべて

検索結果は依然として間違った日付を返す

Outlook、Gmail、Apple Mail、Thunderbirdのメール検索は、送信日ではなくINTERNALDATE（受信日）を使ってインデックスを作成しています。「2022年3月に受信したメール」を検索すると、検索エンジンはINTERNALDATEを参照します。そのINTERNALDATEには移行日が記録されたままなので、2022年3月の検索結果はゼロ件になり、移行日のメールが大量にヒットします。

日付範囲で頻繁に検索するユーザー、例えば特定の四半期の請求書を探す経理担当者や、案件の特定期間のメールをまとめる弁護士にとっては、メールボックスが実質的に使えない状態です。ソート列を変えても、検索エンジンが参照するデータには何も触れていません。

コンプライアンスとeDiscoveryへの影響

Microsoft Purview、Google Vault、サードパーティのコンプライアンスプラットフォームは、サーバー側のメタデータ（INTERNALDATEを含む）を照会します。Outlookで送信日ソートに変えても、これらのツールが取得するデータには一切影響しません。「2023年1月から3月の間に受信したすべてのメール」という法的保全要求に対して、誤った結果が返されます。

金融、医療、法務、公共セクターの組織にとって、eDiscoveryの結果が不正確であれば、制裁、罰則、または不利な司法判断につながる可能性があります。APPIや各業界の文書保管規制に基づくコンプライアンス要件を満たせないリスクがあります。

すべてのデバイスとフォルダで設定が必要

Outlookはビュー設定をグローバルに適用しません。受信トレイでソート列を変えても、送信済みアイテム、下書き、アーカイブ、カスタムフォルダには反映されません。各フォルダを個別に調整する必要があります。設定はローカルに保存されるため、デバイスごとに同じ作業を繰り返す必要があります。100ユーザー、1人あたり4台のデバイス、10個のフォルダという組織なら、4,000件の個別変更が必要になります。誰がやるのでしょうか。

INTERNALDATEは依然として間違っている

サーバー上のIMAP INTERNALDATEは間違ったままです。バックアップツール、将来の移行ツール（間違ったINTERNALDATEがそのまま引き継がれます）、API連携、メールアーカイブシステムに影響します。INTERNALDATEの問題は、サーバーレベルで修正されない限り、永続します。

メールルールとフィルターは受信日を参照する

受信日を基準にしたOutlookのルール、Gmailのフィルター、Exchangeのトランスポートルールは正しく機能しません。「90日以上前に受信したメールをアーカイブに移動する」というルールが、メールボックス全体を移動するか、何も移動しないかのどちらかになります。受信日を基準に処理するPower AutomateのフローやGoogle Apps Scriptも、誤った結果を生み出します。

そもそも対応していないメールクライアントもある

iOS版Apple Mailには「送信日でソート」というオプション自体がありません。Thunderbirdは日付列の扱いがOutlookとは異なります。Roundcube、Hordeなどのウェブメールインターフェースは、列のカスタマイズに制限があります。

スレッド表示が崩れる

スレッドビューに対応したメールクライアントは、ヘッダーと日付を元に関連メッセージをグループ化します。受信日が間違っていると、スレッド内のメッセージの順序がおかしくなったり、スレッドの日付として移行日が表示されたりします。

本当の解決策：サーバー側のデータを修正する

「送信日でソート」が機能しない理由は、原因（サーバー側の日付メタデータの誤り）を修正せずに症状（表示順の乱れ）に対処しているからです。本当の解決策は、影響を受けたすべてのメールについて、サーバー上の日付メタデータを修正することです。

サーバー側のデータが修正されれば、すべてのメールクライアントで正しい日付が表示されます。検索結果は正確な日付範囲を返します。コンプライアンスツールは正しいタイムスタンプを照会します。ルールとフィルターは本来の受信日で動作します。デバイスごと、フォルダごとの設定は不要です。修正は永続的で、すべての環境に反映されます。

Redate.ioがサーバーレベルで修正を行う方法

リデイト（Redate.io）の専有補正エンジンは、メールボックス（Google Workspace、Microsoft 365、またはIMAPサーバー）に接続し、移行ツールの「Received:」ヘッダーを持つメールを特定するためにスキャンします。スキャンは無料です。

影響を受けた各メールに対して、マルチステージ分析パイプラインが数百種類の既知の移行ツールのシグネチャとのパターンマッチングで移行シグネチャを特定します。S/MIME署名、マルチパート構造、インライン添付ファイル、非ASCII ヘッダーなど数十のエッジケースを保持しながら、ターゲットを絞ったメタデータ補正を適用します。そして修正された各メールに対して完全性検証を実行します。元のメールは30日間、目に見えるバックアップフォルダに保存されます。プロセス全体については移行後のメール日付修正方法の記事で詳しく解説しています。

修正後は、Outlookで何かを設定する必要も、デバイスごとに設定を変える必要も、回避策を覚えておく必要もありません。日付はただ、正しいのです。どこでも、ずっと。

半分しか機能しない回避策に頼り続けるのをやめましょう。 無料スキャンを開始すると、日付が誤っているメールの件数を確認でき、10件まで無料で修正して結果を検証できます。