メールのMessage-IDとは？役割や推奨される形式、注意点を解説

メールヘッダの項目の一つである「Message-ID」は、メールを一意に特定するための識別子です。普段メールを送る際に意識することはないと思いますが、実はMessage-IDの形式が正しくなかったり、記載されていなかったりする場合、メールが届かなくなる要因にもなり得ます。この記事では、Message-IDの役割や形式などについてわかりやすく解説します。

Message-IDとは？

Message-IDとは、メールヘッダの項目の一つで、電子メールを一意に特定するために付与される識別子です。

Message-IDはメールが作成される際に、その環境の設定に従って自動的に生成されます。メールサーバーやメールクライアントは、メールが重複していないか、適切に配信されているか確認するためにMessage-IDを使用します。なお、CCやBCCなどで送られる、複製されたメールは同じMessage-IDになります。

メールのメッセージ形式を定義しているRFC 5322では、Message-IDに関して「SHOULD be present」とされており、MUST（必須）とはなっていないものの、メール送信を行う上では事実上必須となっています。

膨大なメールの中から1通のメールを特定できるようにするため、Message-IDはグローバルに一意となるような形式の使用が推奨されています。Message-IDの形式について詳しくは後述します。

Message-IDの役割

Message-IDには、主に次のような役割があります。

メールの重複の検出

Message-IDは、メールサーバーがメールの重複を検出するのに役立ち、同じメールが複数回受信されてしまうことを防ぎます。ネットワークやサーバーの障害や、リトライ機能の誤設定などにより同じメールが複数回送信されてしまっても、Message-IDが同一であれば重複として処理しないという対応が可能になります。

メールの追跡

Message-IDによってメールが一意に特定できるため、トラブルシューティングの際などにメールを追跡することにも役立ちます。例えばメール配信に問題が生じた際に、Message-IDでメールログを検索することで、原因を迅速に特定することが可能です。同様にバウンスメールの特定や、過去のメールアーカイブでの検索などにも役立ちます。

メールの関連づけ

メールクライアントは、Message-IDを使用してメールスレッドを管理します。
具体的には、メールヘッダの「In-Reply-To」および「References」のフィールドに参照するMessage-IDを記載します。2つのヘッダの使い分けについては以下の通りです。

In-Reply-Toフィールド

In-Reply-Toフィールドには、そのメールの直接の返信先となるメールのMessage-IDが記さされます。

Referencesフィールド

Referencesフィールドには、同じスレッドに連なるメールのMessage-IDが順番に全てリストアップされます。In-Reply-Toは返信先のメールのMessage-IDが1つのみ記載されるのに対し、こちらには会話の完全な履歴が保持されます。

これらのヘッダフィールドで関連するメールのMessage-IDを引用することで、メールがスレッドとしてまとめられ、一連のやり取りの流れが理解しやすくなります。

Message-IDが正しくない場合の影響

前述した通り、RFC 5322ではMessage-IDがマストとはされていないものの、強く推奨されているため事実上必須であると認識すべきです。ここでは、Message-IDが正しく設定されてない場合の影響と注意点について解説します。

メールの到達率が下がる可能性がある

Message-IDが正しく記載されていない、重複している、または記載されていないなどの問題がある場合、RFC 5322に準拠していないと判断され、メールサーバー／メールサービスプロバイダのポリシーによっては迷惑メールとして扱われてしまう恐れがあります。

例えばGmailでは特定のメールヘッダが重複している場合、メールの受信を拒否し、エラーとしてバウンスメールを返すと明言しています。

Gmail では、重複したヘッダーを確認するときに次のヘッダーを確認します。

To:、Cc:、Subject:、Date:、From:、Sender:、Reply-To:、Bcc:、Message-ID:、In-Reply-To:、References:

Gmailのデフォルトでは、メールに重複したヘッダーがあると特定すると、メールは受信者に配信されず、このメッセージは RFC 5322 に準拠していませんというエラー（バウンス）メールが送信者に返されます。

引用元：Google Workspace 管理者ヘルプ「RFC 5322（重複したヘッダー）バウンスメールのトラブルシューティング」https://support.google.com/a/answer/13567860?hl=ja#zippy=%2Cduplicate-headers-gmail-checks-for

メールが重複する

正しいMessage-IDが設定されていない場合、同じメールが複数回受信されるリスクがあります。メールサーバーやメールクライアントはMessage-IDをもとに重複を防ぐため、これが機能しなくなると受信者は同じメールを何度も受け取ることになりかねません。

メールの追跡が困難になる

Message-IDが正しく記載されていないとメールの特定・追跡が困難になり、正確な情報を得るのが難しくなるため、バウンスや不達の調査などトラブルシューティングが遅くなってしまいます。

メールのスレッド管理の失敗

メールクライアント上でのスレッド表示もMessage-IDを元に行われるため、Message-IDに不備があるとスレッドがうまく構成されなくなります。例えば、転送を行うMTA（メールサーバー）がMessage-IDを改変したことで、参照関係が崩れスレッド表示が壊れてしまったというトラブルの報告もあります。

Message-IDの形式

ここではMessage-IDの形式について、推奨されるルールや、望ましくないバッドプラクティスについて解説します。

RFC5322におけるMessage-IDの定義

RFC5322ではMessage-IDフィールドは以下のように定義されています。

message-id = “Message-ID:” msg-id CRLF
msg-id = [CFWS] “<” id-left “@” id-right “>” [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right

引用元：RFC5322 ＞ 3.6.4. Identification Fields https://tex2e.github.io/rfc-translater/html/rfc5322.html#3-6-4–Identification-Fields

ここで定義されている内容を詳しく見ていくと、以下のようになります。

CFWS：

CFWSとは “Commented Foldable White Space” の略称であり、コメント付きの空白部分を意味します。空白やコメントを入れることができるということですが、必須ではありません。

id-left：

Message-IDの“@”の左側にあたる部分で、以下2つの形式が指定されています

dot-atom-text：ドットで区切られた文字列
obs-id-left：以前のバージョンで使用されていた古い形式で、現在は推奨されませんが互換性のために許容されています。

id-right：

Message-IDの“@”の右側にあたる部分で、以下3つの形式が指定されています

dot-atom-text：ドットで区切られた文字列
no-fold-literal：“no-fold”とは折り返し不可を意味しており、一行のリテラル値＝IPアドレスを示しています
obs-id-right：以前のバージョンで使用されていた古い形式で、現在は推奨されませんが互換性のために許容されています。

以上のRFCの定義を簡単に整理すると、以下の形式になります。

<“ドットで区切られた文字列”@“ドットで区切られた文字列“ or “IPアドレス”>

推奨されるMessage-IDの採番方法

このように、RFCの定義自体は「ドットで区切られた文字列」程度のものであって、それほど厳格なものではありません。ただし、グローバルに一意の識別子となるような実装方法としてRFCでは以下のように推奨しています。

“@”の右側にメッセージ識別子が作成されたホストのドメイン名（またはドメインリテラルIPアドレス）を配置し、左側には現在の正確な日付と時刻に加えて、システム上で利用可能な他のユニークな識別子（例えばプロセスID番号）を組み合わせて配置するのが良い方法です。

引用元：RFC5322 ＞ 3.6.4. Identification Fields　 https://tex2e.github.io/rfc-translater/html/rfc5322.html#3-6-4–Identification-Fields

一般的には上記の推奨事項にならって、「日時＋α＋ユーザー名」とすることが多いです。ドメイン名の部分はメール送信サーバーのドメイン名とするほか、IPアドレスやコンピュータ名が使われることもあります。

左側の例	右側の例
タイムスタンプ	ドメイン名
タイムスタンプ＋ランダムな文字列	IPアドレス
タイムスタンプ＋プロセスID	ホスト名

Message-IDのサンプル

Message-IDの推奨されるフォーマットを踏まえた例は、以下のようのものになります。

例：Gmailから送信されたメールのMessage-ID

Message-ID: <AAAAAXXXXX=123456789+abcdefghijklmn@mail.gmail.com>

例：企業ドメインから送信されたメールのMessage-ID

Message-ID: <20240526103045.12345.user123@example.com>

例：IPアドレスを使用したMessage-ID

Message-ID: <20240526103045.12345@203.10.xxx.xxx>

例：ホスト名を使用したMessage-ID

Message-ID: <20240526103045.12345@host001.example.jp>

Message-IDの悪い例

一方で、以下のようなパターンはメッセージIDがユニークにならないため避けましょう。

例：@以降にプライベートIPアドレスを使っている

Message-ID:<20240526103045.12345@192.168.10.30>

例：@以降がドメイン名になっていない

Message-ID:<20240526103045.12345@example

Message-IDはどこで生成されるのか

Message-IDは、通常はメールを作成するアプリケーションやMUA（メールユーザーエージェント＝メールクライアントのこと）によって自動的に生成され、メールヘッダに挿入されます。

Message-IDはMUAとMTA（メール転送エージェント＝SMTPサーバーのこと）のどちらが付与すべきなのかという議論が昔からあるようですが、Message-IDの一意性を確保するためにも、メールを作成するアプリケーション側で発行・管理すべきというのが基本的な考え方となっています。
Message-IDは前述の通りRFC5322で規定されており、メールを作成するアプリケーション／MUAはRFC5322に準拠したメールを生成する必要があるためです。

Message-IDが欠けているメッセージを受け取った際に、MTA側で付与することも技術的には可能です。PostfixやSendmailといったMTAでは、Message-IDが欠けていた場合に自動的に付与する設定を行うことができます。

またメールリレーサービスなどにおいても、Message-IDが欠けていた場合にサービス側で自動的に付与することもありますが、Message-IDによるメールの追跡を行うためにはユーザ側で発行・管理を行うことが望ましいでしょう。

まとめ

メールのMessage-IDとは、メールを一意に特定するための識別子です。Message-IDによって、トラブルが発生した際の原因の特定、重複の検出、スレッドの生成などが可能になります。Message-IDに問題があると迷惑メールとして扱われてしまう恐れもあるため、正しい形式でMessage-IDを発行・管理することが重要です。