メールの日付を改ざんできるか？技術的な可否と検出方法

メールの日付改ざんとは何か

システム管理者のフォーラムやMSPのSlackグループで、こんな質問がよく出ます。「送信済みのメールの日付を後から変更することはできるか？」答えは短く言えば「技術的には可能」です。ただし、それを悪用しようと考えている人にとっては、完全な答えはかなり不都合なものになります。

メールは単一のファイルではありません。テキスト形式のヘッダーの集合体に、メッセージ本文が続く構造です。そのヘッダーの中には、日付に関する情報を持つものが複数あります。そして、変更しやすいものとそうでないものがあります。

すべてのメールには、日付に関する3つの層が共存しています：

• Date:ヘッダー（RFC 2822）: 送信時にメールクライアントが書き込む
• Received:ヘッダー: メッセージを中継する各サーバーが追加する
• IMAP INTERNALDATE: サーバー側に保存されるメタデータで、メッセージ本文とは独立している

これらの層はいずれも変更可能です。しかし、痕跡を残さずに変更できるものは一つもありません。

Date:ヘッダーの変更：最もわかりやすい操作

Date:ヘッダーは.emlファイル内のプレーンテキストです。技術的には、16進エディタやPythonスクリプトで数秒あれば書き換えられます。Gmailのメニューから「元のメールを表示」を開いたことがある方なら、誰でも読めることがわかるはずです。

問題はここからです。2004年以降、大多数のメールサーバーは送信メールにDKIM（DomainKeys Identified Mail）の署名を付与しています。この暗号化署名は、Date:、From:、Subject:、そしてメッセージ本文を含む複数のヘッダーを明示的にカバーします。署名はDKIM-Signature:ヘッダーに格納されます。

署名後にDate:を変更すると、DKIMの検証が機械的に無効になります。受信サーバーは、送信元ドメインのDNSから公開鍵を取得して署名を検証できます。署名が一致しなければ、メッセージは改ざんありとしてマークされます。Gmail、Outlook.com、その他の主要なメールサービスはすべてこの検証を自動的に行います。

（ちなみに、DKIMの署名を実際に見てみたい方は、GmailやOffice 365から受信したメールの生ヘッダーを確認してください。DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=...というノイズのような行が見つかりますが、あれは実はメッセージ全体の暗号ハッシュです。）

つまり、DKIMで署名されたメールのDate:を変更することは、封印を破ることと同じです。その変更は、調べ方を知っている管理者なら誰でも確認できます。

Received:ヘッダーの書き換え：偽造が難しいチェーン

Received:ヘッダーは、送信者から受信者へのメールの経路を追跡するものです。メッセージを処理する各SMTPサーバーが、ホスト名、IPアドレス、タイムスタンプとともに1つ追加します。2つや3つのリレーを経由したメールには、それぞれ対応するReceived:ヘッダーが積み重なっています。

変更できるか？自分の手元にあるコピーであれば、技術的には可能です。しかしここに落とし穴があります。受信者側にも同じメールのコピーがあります。そして受信者のサーバーが最後に自分のReceived:ヘッダーを追加しています。このヘッダーは受信者側のコントロール下にあり、送信者側からは絶対に偽造できません。

チェーンの整合性は検証可能です。連続するReceived:のタイムスタンプに矛盾がある場合（たとえば、中間リレーが送信者が送るより前にメッセージを受け取ったことになっているなど）、それはすぐに不審に見えます。MXToolboxのようなフォレンジック分析ツールや、セキュリティチームの内部ツールは、まさにそこをチェックします。

実は、「Received:ヘッダーを完全に偽造することは不可能」というのも正確ではありません。自前のメールインフラを持つ攻撃者なら、自分がコントロールする中継サーバーに対しては信憑性のあるヘッダーを作ることができます。しかし、最後の一つ、つまり受信者側のサーバーは絶対にコントロールできません。

IMAP INTERNALDATE：最も技術的なケース

INTERNALDATEはサーバー側に保存されるIMAPのメタデータです。メッセージ本文内のヘッダーではなく、サーバーが内部データベースでメッセージに関連付ける値です。そしてほとんどのメールクライアントがメッセージの並び替えに使う値でもあります。

IMAPのAPPENDコマンドを使うと、INTERNALDATEを明示的に指定してサーバーにメッセージを保存できます。これはRFC 3501に文書化されたプロトコルの正規機能です。移行ツールは常にこれを使います。imapsync、BitTitan MigrationWiz、CloudM、GSMMO...これらはすべて、INTERNALDATEを指定して移行先サーバーにメールを保存します。

理論上は、自分のメールボックスへのIMAPアクセスがあれば、任意のINTERNALDATEを持つメールを保存することができます。しかし、この操作はメッセージのヘッダーを変更しません。元のDate:はそのまま、Received:もそのまま、DKIMの署名もそのままです。変わるのはサーバー側の並び替えメタデータだけです。

生のメッセージを調べる専門家にとっては、INTERNALDATEとDate:の不一致はすぐに分かります。そしてメッセージがDKIM署名されていれば、元の日付は暗号学的に証明されています。

Message-ID：偽造が難しい指紋

すべてのメールには一意の識別子であるMessage-ID:ヘッダーが生成されます。この識別子は、送信元のSMTPサーバーが送信時に、タイムスタンプ、ランダムな識別子、サーバーのドメイン名を組み合わせて構築します。

典型的なMessage-IDはこのような形です：<CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>。タイムスタンプが識別子の中に直接エンコードされていることが多いです。メッセージの日付を変更しながら、互換性のないタイムスタンプを持つMessage-IDを残すと、すぐに目立つ矛盾が生まれます。

さらに、Message-IDは大手メッセージングシステムによってインデックス化されています。Google、Microsoft、その他の主要プレーヤーは、メッセージが実際にそのインフラを通過した時刻を追跡できるログを維持しています。法的・フォレンジックなコンテキストでは、司法手続きを通じてこれらのログにアクセスできます。

実際に誰が改ざんの試みを検出できるのか

具体的に考えてみましょう。日付が変更されたのではないかと疑うメールを受け取ったとします。最低限の技術的知識を持つIT管理者や弁護士には何ができるでしょうか？

• DKIMの確認：Gmailでは「元のメールを表示」メニューを開くと、ページ上部にDKIM検証の結果が直接表示されます。「PASS」はメール送信からの整合性を確認するものです。「FAIL」または「SOFTFAIL」は改ざんを示します。
• ヘッダーの分析：MXToolbox Header AnalyzerやGoogle Admin ToolboxなどのツールがReceived:チェーンを自動的に解析し、時系列の矛盾を指摘します。
• Message-ID / Dateの整合性：アナリストは、Message-IDにエンコードされたタイムスタンプと、申告されたDate:の値を比較できます。
• サーバーログ：メールが管理しているサーバーを経由している場合、SMTPログには、いかなるヘッダーとも独立した実際のメッセージ受信日時が含まれています。

つまり、検出ツールは利用しやすく、無料で、高度なフォレンジックの専門知識を必要としません。少し好奇心のあるIT管理者なら、2分もあればメールの整合性を確認できます。

大規模な日付変更が正当なケース：IMAP移行

悪意なく何十万通ものメールが誤った日付を持つことになるシナリオが一つあります。IMAP移行です。

150個のExchangeメールボックスをGoogle Workspaceに移行したとします。月曜の朝、チケットが届き始めます。ユーザーから「古いメールが全部同じ日付で表示される。移行した週末の日付になっている」という報告です。受信トレイが使い物にならない状態になっています。

何が起きたかは、文書化されており予測可能なことです。移行ツール（BitTitan、CloudM、imapsyncなど）がIMAP APPENDでGoogle WorkspaceにメールをIMAPで保存する際、元のメールの日付ではなく移行日のINTERNALDATEを指定したのです。デフォルトでINTERNALDATEを基準に並び替えるOutlookでは、すべてのメッセージに移行日が表示されます。このメカニズムの詳細はIMAP移行後にメールの日付が変わる原因と対処法で説明しています。

各メッセージの元のDate:ヘッダーはそのままです。DKIM署名もそのままです。コンテンツも変わっていません。誤っているのは、サーバー側のINTERNALDATEだけです。

この問題はBitTitan MigrationWiz、CloudM Migrate、imapsync、GSMMO、そしてINTERNALDATEを正しく保持せずにIMAP APPENDを使用するすべてのツールに影響します。BitTitanの詳細についてはBitTitan MigrationWiz: メール日付の修正方法をご覧ください。移行前後に確認すべき点についてはメール移行チェックリスト：日付トラブルを防ぐ方法をご参照ください。

修正と改ざんの違い

リデイト（Redate.io）が行う修正は、改ざんの試みとは正反対のものです。専有の修正エンジンが各メッセージのヘッダーチェーンを分析し、Date:ヘッダー（RFC 2822）にエンコードされた元の日付を特定します。この日付は一度も変更されたことがないものです。そして、メッセージにすでに存在する真正な情報に合わせて日付メタデータを修正します。

Date:ヘッダーが信実の源泉です。送信者のメールクライアントが送信時に書き込んだものであり、DKIM署名でカバーされています。Redate.ioはこれを変更しません。修正されるのは、移行ツールが引き起こした不一致であり、元の日付ではありません。

移行の失敗後に47,000通のメールを一通も失わずに修正し、スレッドを壊さず、添付ファイルを破損させず、Google APIで深夜3時に429エラーを引き起こさないようにするには、マルチステージ分析パイプラインとエッジケースの処理（S/MIME、PGP、RFC 2047の非ASCIIエンコーディング、複雑なマルチパート構造）が必要です。5行のPythonスクリプトでは、最初の本番環境のメールボックスで行き詰まります。なぜDIYが実際の規模では危険なのかについては移行後のメール日付は修正できるのか？で詳しく説明しています。

Redate.ioはメールボックスを無料でスキャンし、誤った日付のメールを特定して、各メッセージを個別に検証するパイプラインで修正を行います。元のメッセージは30日間、見えるバックアップフォルダに保存されます。何か問題が起きた場合は、ロールバックが可能です。

移行後にメールの日付がずれてしまいましたか？ Redate.ioの無料スキャンを開始して、対処方法を決める前に問題の規模を把握しましょう。