受信メールの日付を変更できるか？本当のことを話す

誰もが尋ねる問いと、その裏に潜む二つのまったく異なる状況

「受信メールの日付を変更する方法」とGoogleで検索すると、MicrosoftのQ&Aフォーラム、Redditのスレッド、Quoraの質問が何十件も見つかります。求めていることは同じでも、その理由はまるで違います。

一方には、なんらかの目的のために日付を遡って書き換えようとしている人がいます。もう一方には、IMAP移行後に全メールが同じ日付（移行日）で表示されてしまい、本来の日付を取り戻したいITシステム管理者がいます。この二つはまったく別の問題ですが、検索キーワードは同じになります。

この記事では、両方に答えます。先に言っておくと、前者の場合は検知されずに変更することは事実上できません。後者の場合は、正当な操作であり、それがまさにリデイト（Redate.io）が行っていることです。

まずメールの「日付」とは何か

メールには日付が一つだけあるわけではありません。複数の場所に、複数の主体によって管理された形で保存されています。

Date: ヘッダー（RFC 2822）

送信時に送信者のメールクライアントがメッセージに書き込む日付です。生のヘッダーには次のような形で記録されています：

Date: Mon, 14 Oct 2024 09:32:11 +0200

このヘッダーはメッセージ本文の一部です。生のファイルにアクセスすれば技術的には変更できます。ただし「技術的には」という言葉が重要です。

Received: ヘッダー

メールが通過する各メールサーバーは、タイムスタンプ付きの Received: ヘッダーを追加します。これらのヘッダーは送信元サーバーから受信ボックスまでの時系列チェーンを形成します。（生のメールヘッダーを読もうとしたことがある方はご存じの通り、海辺でのんびり読む類のものではありません。数十行の技術的なメタデータが、新しいものから古いものの順に並んでいます。）

IMAPのINTERNALDATE

なぜ一部の変更が見た目に何の効果ももたらさないのかを理解するうえで、最も重要なメタデータです。INTERNALDATEはIMAPサーバー側に保存された属性で、メッセージの内容とは独立しています。ほとんどのメールクライアントがフォルダー内のメールを並び替える際に使用するのがこれです。OutlookもGmailも、Apple Mailも、多くの場合これを使います。

INTERNALDATEはメッセージの中にはありません。サーバーのデータベースにあります。ディスク上の.emlファイルを編集しても変更することはできません。

ローカルで変更した場合に実際に起きること

.emlファイルを編集する

.emlファイルはテキストファイルです。エディターで開いて Date: の行を書き換えて保存することはできます。そのファイルをローカルのメールクライアントに再インポートすると、クライアントによっては表示される日付が変わることもあります。

しかし、変わらないものがあります：

• IMAPサーバー上のINTERNALDATE（そのまま残ります）
• 中継サーバーが追加した Received: ヘッダー
• Google、Microsoft、またはプロバイダー側の配信ログ
• メッセージにDKIM署名があった場合、その署名

結果として、ローカル環境では別の日付が表示されるかもしれません。でも Exchange Online に接続した Outlook やブラウザーの Gmail では、何も変わっていません。

システムクロックを変更する

一部のフォーラムでは、メールクライアントを「だます」ためにPCの時計を変更することを提案しています。これは機能しません。OutlookもGmailも、受信メールの日付を表示するためにシステム時刻を読みません。サーバーからINTERNALDATEを、またはメッセージのヘッダーを参照します。ローカルの時計はこのプロセスに一切関係しません。

Thunderbirdを使った操作

Thunderbirdは多くのクライアントよりも柔軟です。拡張機能を使ったり、プロファイル（mboxファイル、.msf ファイル）を直接操作したりすることで、日付の表示を変えようとする試みがあります。POP3モードでローカルに保存されているメールであれば、Thunderbird内で動作することもあります。ただしThunderbirdをIMAP接続で使っている場合、サーバーと再同期されます。次の同期時に「修正」は消えます。

DKIM：誰も言及しない見えないバリア

2018年以降に送信されたほとんどのメールはDKIM（DomainKeys Identified Mail）で署名されています。DKIM署名はヘッダーにこのような形で含まれています：

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

h= フィールドは署名でカバーされているヘッダーを列挙しています。上の例では Date が署名対象です。メッセージの Date: ヘッダーを変更すると、DKIM検証は失敗します。任意のメールサーバーや任意のフォレンジック解析ツールが、署名を再計算することで改ざんを検知できます。

これは完璧な防護ではありません（悪意ある送信者は自分のDKIM鍵を管理していて、送信時に好きな内容に署名できます）。しかしすでに受信して署名されているメールの Date: ヘッダーを変更すると、検知可能な痕跡が残ります。

サーバーログ：真実の源泉

仮にメールのすべての可視メタデータ（ヘッダー、INTERNALDATE、すべて）を変更できたとしても、プロバイダーは独自のログを保持しています。

Google WorkspaceはAdmin Consoleの監査ログにすべてのメッセージを記録しています。Microsoft 365も同様に、コンプライアンスセンター（Purview）でこれを行っています。これらのログにはクライアントで表示されるものとは独立した配信タイムスタンプが含まれます。弁護士、法務部門、またはセキュリティチームはこのデータを取得できます。Outlookで見える日付は、裁判所やセキュリティ監査の場では証拠として通用しません。

正確に言うと、ドメイン委任でメールボックスへのアクセス権を持つ管理者でも、これらのログを遡って書き換えることはできません。特権ユーザーを含め、ユーザーの手の届く範囲の外にあります。

正当なケース：移行後の日付修正

オンプレミスのExchangeからMicrosoft 365へ、150のメールボックスの移行を終えたとします。翌週月曜日、チケットが届き始めます。「古いメールが全部、先週の金曜日付けになっています」と。移行した日付が表示されているのです。

これは十分に記録されている問題であり、先ほど説明したこととはまったく異なります。ここでは誰も日付を偽造しようとしていません。本来の日付は各メッセージの Date: ヘッダーに、今も完全な状態で残っています。問題は別のところにあります。移行ツール（BitTitan MigrationWiz、CloudM、imapsync、その他）がチェーンの先頭に移行日付を持つ Received: ヘッダーを挿入しました。Outlookは特定の状況でINTERNALDATEよりも最新の Received: ヘッダーを参照するため、その日付を表示してしまいます。

この場合の「修正」とは、メッセージが示していること（元の Date: ヘッダー、今も存在しています）とサーバーが認識していること（移行時に設定されたINTERNALDATE）の間の整合性を回復することです。これは改ざんではありません。復元です。

これはIMAP移行後にメールの日付が変わる原因と対処法で詳しく解説している問題です。そして、Redate.ioが解決するものです。

自前でやろうとすると大規模では失敗する理由

問題を理解することと、150のメールボックスに散らばった40,000通のメールを一通も失わずに修正することは、まったく別の話です。

GitHubやStack Overflowにあるスクリプトは20通のテストメールでは動作します。本番環境では、スクリプトの作者が想定していなかった理由で問題が起きます：

• S/MIME署名済みメールやPGP暗号化メールは、普通のメッセージとは異なる構造を持ち、同じように操作できません
• 非標準のMIMEバウンダリを持つマルチパートメッセージは、パースエラーを引き起こします
• RFC 2047でエンコードされたヘッダー（From: や Subject: フィールドの非ASCII文字）はナイーブなパーサーを壊します
• GoogleとMicrosoftのAPIにはレート制限があります。30,000通のバッチ処理中に深夜3時に429 Too Many Requestsエラーが発生しても処理されず、スクリプトは止まります。どこで止まったか誰にも分かりません
• ロールバック機構がありません。処理中にメッセージが壊れた場合、元に戻す手段がありません

Redate.ioは、元のメールの コピーを30日間、見えるバックアップフォルダーに保持します。各修正は個別に検証されます。分析パイプラインは何百もの既知の移行ツールのシグネチャと、自作スクリプトでは処理できないすべてのエッジケースを扱います。

使用したツール別の詳細については、BitTitan MigrationWizとメールの日付やCloudM Migrate：メール日付の誤りを修正する方法をご覧ください。

変わるものと変わらないものの整理

区別は明確です。表の最初の3行は、表面的な変更か、または検知可能な変更を表しています。最後の行は、メッセージの元の内容と整合したメタデータの正当な修正であり、移行によって生じた不整合を解消するものです。

imapsync、BitTitan、CloudM、またはその他のツールで移行した後に表の最後の行に該当する状況にある場合、Redate.ioはそのために作られています。

移行日がメールの日付として表示されてしまっていますか？ Redate.ioで無料スキャンを実行して、実際に何通のメールが影響を受けているかを確認してから判断してください。