Message-ID
The Message-ID is a globally unique identifier a sending system puts on every message, written as a local part and a domain inside angle brackets. Replies quote it in their In-Reply-To and References headers, which is how mail clients build a thread. It is also the handle support teams use to trace one specific message through logs on both sides.
At a glance
- Category
- Message format
- Shape
- <unique-part@domain>, in angle brackets
- Set by
- The first system to handle the message
- Used for
- Threading, deduplication and tracing
- Referenced by
- The In-Reply-To and References headers on replies
- Specified in
- RFC 5322, section 3.6.4
How it works
A sending system generates an identifier that no other message will share, conventionally a random or time-based local part followed by a domain it controls, and writes it in a Message-ID header. When somebody replies, their client copies that value into In-Reply-To and appends it to References, which accumulates the chain back to the first message. A client displaying a mailbox groups messages by walking those references, which is why threading works across different clients and providers.
Why it matters
Two very different jobs depend on it. For readers it is threading: a reply that omits the references headers appears as a new conversation, which is the usual cause of a support thread splitting into six. For operators it is tracing: the identifier appears in your own records and in the receiving server's logs, so it is the one token that lets two organisations talk about the same message without ambiguity. A support conversation that starts with an identifier is answerable; one that starts with an approximate time and a subject line rarely is.
Example
An application sends a notification, and the message carries an identifier ending in the sending domain. The customer replies from their own client, which copies that value into In-Reply-To. The reply arrives at the receiving endpoint, the application looks up the referenced identifier, finds the original notification and appends the reply to the right ticket. A later message in the same thread carries both identifiers in References.
Common mistakes
- 01Generating a new identifier when resending the same message, which breaks deduplication at the receiving end.
- 02Replying without the In-Reply-To and References headers, so every answer starts a fresh thread in the customer's client.
- 03Using a domain you do not control in the identifier, which some filters treat as a sign of forged headers.
- 04Truncating the identifier when storing it, so the value in your records no longer matches the one the receiving server logged.
Related terms
Frequently asked questions
Can I set the Message-ID myself?
Often yes, and some systems need to so that the identifier matches their own records. If you do, make it genuinely unique and use a domain you control.
Why did my reply start a new thread?
Almost always because the reply did not carry In-Reply-To or References pointing at the original identifier. Subject matching is a fallback that different clients apply inconsistently.
Is the Message-ID the same as a tracking identifier?
No. The Message-ID belongs to the message format and travels with the mail, while a tracking identifier belongs to the sending service's own records. Many services expose both.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.