A Message ID in email is a header field that gives one specific email message a globally unique identifier, usually written in angle brackets such as <20261021.123456.abc@example.com>. Mail clients and mail servers use it to distinguish messages, connect replies to the original email, detect duplicates, and help senders trace delivery events.

What is a Message ID in email?

The Message-ID header is part of an email's technical metadata, known as its headers. It is not normally visible in the inbox preview, subject line, or message body. Instead, it appears in the raw source of the message alongside headers such as From, To, Date, Subject, Reply-To, and Received.

A Message-ID identifies a particular version of a particular email message. That distinction matters. If you edit and resend a campaign, retry a message by creating a new message, or send a revised order confirmation, each resulting message should receive its own identifier. A Message-ID is intended to be machine-readable rather than meaningful to the recipient.

The Internet Message Format standard defines the field and says the identifier itself must be globally unique. The system that generates it is responsible for ensuring that uniqueness. RFC 5322 also says that, although the field is technically optional in the message format, it should be present in every message. (datatracker.ietf.org)

A typical raw header looks like this:

Message-ID: <20261021.123456.48291.7f3c@example.mail.example>

The value after Message-ID: is not an email address, even though it resembles one. The string to the left of @ is an identifier chosen by the generating system. The string to the right is typically a domain associated with the host or service that generated the identifier.

Message ID versus a provider message ID

Email providers often expose their own API response IDs, event IDs, queue IDs, or webhook IDs. Those are useful operational identifiers, but they are not automatically the same as the RFC email header named Message-ID.

For example, an API may return an ID when it accepts a send request. That ID can identify the API transaction in the provider's application. The Message-ID header identifies the email message as it travels through the broader email ecosystem. When troubleshooting a delivery issue with a recipient mail server, a mailbox provider, or a support team, the raw Message-ID is frequently the more portable identifier.

Do not assume that a database primary key, marketing platform campaign ID, SMTP queue ID, or X- prefixed custom header is a substitute for a valid Message-ID. Those fields may be valuable for your internal reporting, but they do not participate in standard reply threading in the same way.

Message-ID syntax and format

The standard syntax is compact:

Message-ID: <id-left@id-right>

In practical terms, a valid Message-ID has three visible characteristics:

It begins with an opening angle bracket: <.
It contains an identifier, an @ symbol, and a right-hand identifier or domain-like value.
It ends with a closing angle bracket: >.

A simple example is:

Message-ID: <order-847291-20261021@mailer.example.com>

An identifier can include more detail than this example. Sending systems commonly combine components such as a timestamp, a random value, a sequence number, a host name, a process ID, or a cryptographically strong random token. The exact value is implementation-specific. What matters is that the resulting value is syntactically valid and never reused for another message.

RFC 5322 defines the field as msg-id syntax and requires the generator to guarantee uniqueness. It also describes the domain portion as the usual way to help make an ID globally distinct across systems. (datatracker.ietf.org)

Valid and invalid examples

These are examples of conventional, valid-looking Message-ID values:

Message-ID: <e3d5a87b-275b-4ac2-aef8-9100e1d7c0ba@notifications.example>
Message-ID: <20261021.123456.9912.transactional@mailer.example>
Message-ID: <invoice-10482-7d82ce@billing.example.com>

These examples are problematic:

Message-ID: 20261021.123456@example.com
Message-ID: <20261021.123456@example.com
Message-ID: 20261021.123456@example.com>
Message-ID: <same-id@example.com>

The first three fail the expected bracketed form. The last may be syntactically acceptable in isolation, but it becomes a serious defect if that exact value is reused for multiple unrelated messages.

The Message-ID domain does not authenticate a message

The right-hand portion of a Message-ID often looks like a domain name, but it is not an authentication signal in the same sense as SPF, DKIM, or DMARC. A receiving server does not establish sender authorization merely because the domain in Message-ID resembles the visible From domain.

That means these values can legitimately differ:

The visible From address, such as receipts@example.com
The SMTP envelope sender or return path
The DKIM signing domain (d=)
The Message-ID domain, such as mailer.example.net

Alignment between these values may make debugging easier, but Message-ID alignment is not a DMARC requirement. Treat the Message-ID domain principally as a uniqueness and traceability component, not as an authentication control.

Why Message ID matters for email threading

The most familiar use of a Message-ID is conversation threading. When a person receives an email and clicks Reply, the replying mail client generally includes the original email's Message-ID in the reply's In-Reply-To header. It may also include the existing conversation chain in the References header.

Here is a simplified original message:

From: Support <support@example.com>
To: customer@example.net
Subject: Your support request
Message-ID: <ticket-8431-001@support.example.com>

A recipient's reply may include:

From: customer@example.net
To: Support <support@example.com>
Subject: Re: Your support request
In-Reply-To: <ticket-8431-001@support.example.com>
References: <ticket-8431-001@support.example.com>
Message-ID: <reply-9f34a2@mail.example.net>

The reply has a new Message-ID because it is a new message. Its In-Reply-To value points back to the original message. That relationship gives email clients a machine-readable basis for grouping messages into a conversation.

Mailgun documents this same practical relationship: the original message's Message-ID is included in the reply's In-Reply-To header, allowing a sender to determine which specific email was answered. (help.mailgun.com)

Why subject lines are not enough

A subject line is a poor primary key. It can be edited, translated, blank, duplicated across thousands of messages, or prefixed differently by mail clients. For example, all of these could represent the same conversation:

Your support request
Re: Your support request
RE: Your support request
Aw: Your support request

Conversely, two separate conversations can use the exact same subject line, especially for recurring alerts such as “Your weekly report” or “Your invoice is ready.” Threading headers provide a more durable technical relationship than text matching.

Mailbox providers can apply their own proprietary conversation-grouping logic, so correctly set headers do not guarantee a particular inbox display. Still, a valid and unique Message-ID, plus appropriate In-Reply-To and References headers on replies, gives clients the standardized information they need to construct threads predictably.

Threading implications for transactional email

Not every transactional message should join the same thread. A password reset, login alert, payment receipt, and account suspension notice may all concern the same user, but they are separate events and should normally have different Message-IDs with no shared reply-chain headers.

A support workflow is different. A new support case can start with a fresh Message-ID. Subsequent agent responses should be new messages that reference the prior conversation appropriately. This avoids burying unrelated cases in one thread while still keeping a real customer interaction coherent.

Why Message ID matters for deliverability and campaign performance

A Message-ID is not a deliverability metric. There is no Message-ID rate to calculate, and changing its text alone will not improve inbox placement. Inbox placement depends on a broader set of signals, including authentication, sending reputation, complaint behavior, engagement patterns, list quality, content, infrastructure, and recipient-server policy.

However, a valid and unique Message-ID is foundational message hygiene. It helps a message conform to the expected structure of internet email. A missing, malformed, or duplicated identifier can create operational problems that indirectly harm campaign performance and delivery reliability.

Acceptance failures caused by missing or invalid Message-IDs

Some recipient systems reject messages that lack a valid Message-ID. One documented Gmail rejection is 550-5.7.1 Messages missing a valid Message-ID: header are not accepted, which is a message-construction issue rather than evidence that the recipient address is invalid. (suped.com)

That distinction is important for suppression management. If a valid mailbox rejects a malformed message, suppressing the recipient as a permanent hard bounce would be the wrong response. Correct the sending application or message-building library, then retry according to your normal operational policy.

Duplicate detection and unintended message loss

If two different messages share the same Message-ID, a receiving system or mail client may treat one as a duplicate of the other. The recipient may see only one message, an email may be grouped under the wrong conversation, or an internal archive may collapse distinct records.

For a campaign, that can make engagement data misleading. Imagine a sender accidentally assigns the same Message-ID to 50,000 individualized renewal notices. Some systems may still deliver them, but others can deduplicate, thread them incorrectly, or make support investigation far harder. A “missing” message may not be a reputation problem at all; it may be an identifier collision.

Measurement and reporting consequences

Campaign reporting systems frequently join events using provider-level identifiers, recipient data, and custom metadata. A Message-ID can add an important cross-system reference when you need to compare:

An application log showing that a notification was created
An email provider event indicating acceptance or delivery
A recipient's raw message source
A reply received by an inbound mailbox
A help-desk ticket or customer support investigation

This does not mean you should make Message-ID your only analytics key. A strong event model stores multiple identifiers: your application event ID, provider send ID, recipient ID, campaign or template version, timestamp, and the generated Message-ID. The Message-ID is especially useful because it can be found in the delivered email itself.

Message ID is not a bounce rate or engagement metric

Because “message ID” can sound like a reporting field, it is worth being explicit: it is an identifier, not a rate, score, percentage, or campaign KPI.

You do not calculate Message-ID as you would calculate a delivery rate or bounce rate. Instead, you verify that each outbound email has exactly one valid value and that no unrelated message reuses it.

For comparison, a bounce rate is calculated as:

bounce rate = bounced messages / sent messages × 100

If a campaign sends 20,000 messages and 120 bounce, the bounce rate is:

120 / 20,000 × 100 = 0.6%

A Message-ID does not work this way. The operational question is not “What is our Message-ID percentage?” It is closer to:

Does every outbound message contain a valid Message-ID?
Is every generated value unique within and beyond the sending system?
Can we retrieve the Message-ID for a delivery, bounce, complaint, or reply investigation?
Are reply headers correctly referencing the parent message?

You can turn these questions into monitoring checks. For example, alert if more than zero messages in a production batch are missing the header, if the same value occurs across distinct message records, or if your parser cannot associate inbound replies with known outbound messages.

Common Message-ID problems and their causes

Message-ID issues often originate before an email reaches your email provider. They are commonly introduced by application code, SMTP libraries, custom MIME builders, templating systems, proxies, or retry logic.

Missing Message-ID header

A missing header usually means the application constructed raw MIME incorrectly or bypassed the component that normally creates standard headers. This can happen when developers send hand-built email source, import a message from another system, or use a low-level SMTP implementation without a complete message-construction library.

It can also happen when a system strips headers during message transformation. For example, an internal service might parse an email, create a new message object, copy only selected headers, and accidentally omit Message-ID before relaying it.

Invalid syntax

Common formatting errors include omitted angle brackets, unbalanced brackets, whitespace inside a malformed identifier, nonconforming characters, or a value that is actually an API ID pasted into the header without the required format.

Another mistake is placing a custom identifier in a header with a similar but different name, such as MessageID, Message_Id, or X-Message-ID, while failing to include the standard Message-ID header. Header field names are not interchangeable.

Reused Message-IDs

Duplicate values typically result from deterministic code that uses insufficiently variable inputs. A poor generator might use only a campaign ID, only a timestamp rounded to seconds, or a static template value.

For example, this is unsafe if thousands of messages can be generated during the same second:

<weekly-digest-20261021@example.com>

A better design includes a unique send-level value:

<weekly-digest-20261021-7d82ce9a-8aef-4e4a-a55f@example.com>

The goal is not to expose customer data in the header. In fact, avoid embedding a recipient email address, account number, or other sensitive data in a Message-ID because headers can be forwarded, stored, and inspected. Use opaque identifiers instead.

Reusing an ID after a retry

Retry behavior needs a deliberate policy. If the original message was accepted by a provider but you did not receive a response because of a network timeout, blindly creating a brand-new message with a new Message-ID can produce a duplicate visible email. Reusing the original Message-ID can instead trigger duplicate handling in some systems.

There is no universal one-line answer because the right retry behavior depends on where the failure occurred and whether the earlier submission was accepted. The important practice is idempotency: store the send attempt state, provider response where available, and Message-ID before performing a retry. Avoid treating every network error as proof that no message was accepted.

Incorrect reply-chain headers

A new outbound support reply needs its own Message-ID. Its In-Reply-To header should reference the message it is replying to, and its References header should preserve the conversation chain where appropriate. A common error is to set the outgoing reply's Message-ID equal to the original message's ID. That makes two distinct messages appear identical.

Another error is putting an entire header line into a value field, for example passing Message-ID: <abc@example.com> as the value when the library expects only <abc@example.com>. Use the conventions of your email library or provider SDK rather than assembling headers from guesswork.

How to generate a reliable Message-ID

The safest option is usually to let a reputable email library or email service generate the Message-ID. Mature tools understand message formatting, use a suitable uniqueness strategy, and reduce the chance that a developer accidentally creates invalid raw headers.

Mailgun states that it automatically creates a unique Message-ID when sending a message, while also allowing senders to set their own custom Message-ID when their workflow requires it. (documentation.mailgun.com)

If you generate the header yourself, design for four properties: validity, uniqueness, stability in your logs, and privacy.

A practical generation pattern

A robust custom Message-ID can combine:

A high-entropy random UUID or comparable random token.
A timestamp for debugging and chronological context.
An optional internal send-attempt or shard indicator that does not expose personal information.
A domain controlled by your sending infrastructure.

For example:

Message-ID: <20261021T184501Z.5f1b9bb6-70d0-4a3e-b14e-8a5e57930f5a@msg.example.com>

The UUID supplies practical uniqueness; the timestamp helps engineers investigate logs; and the domain indicates the generating system. The exact composition is less important than the guarantee that two independently created messages cannot receive the same value.

Generate before sending and persist it

Create the Message-ID before the handoff to the sending provider, then persist it with the application event. This gives your team one stable identifier to use across logs, support tickets, inbound processing, and post-send analysis.

A simplified data record could contain:

notification_id: ntf_01JABC...
recipient_id: usr_8a72...
message_id: <20261021T184501Z.5f1b9bb6-70d0-4a3e-b14e-8a5e57930f5a@msg.example.com>
provider_send_id: provider_42e...
template_version: receipt-v4

Keep your internal notification ID separate from Message-ID. Your internal ID can follow any format and access-control policy you need. The Message-ID must remain valid email-header syntax and may be exposed outside your application.

Use a real message-building layer

Avoid manually concatenating header strings unless you have a compelling reason and thorough tests. A message-building library should handle header encoding, MIME boundaries, line endings, address formatting, and standard field construction.

If you use an email API, consult the provider's email API setup guides to understand whether the platform generates Message-IDs automatically, whether custom headers are supported, and how returned send identifiers relate to the headers in the delivered message.

How to inspect and troubleshoot a Message-ID

When diagnosing a delivery, threading, or reply-tracking issue, inspect the raw source of both the original message and any reply. Do not rely only on the inbox conversation view, because that view may hide relevant headers or apply client-specific grouping logic.

A practical troubleshooting workflow

Locate the exact outbound message. Search your application records using the recipient, send time, notification type, or provider event ID.
Retrieve the Message-ID. Pull it from your outbound logs, provider event details, or the raw source of the delivered message.
Check structure. Confirm that it has one valid Message-ID header with a bracketed value containing @.
Check uniqueness. Search your logs and data store for the same value. It should map to one message instance, not many unrelated sends.
Compare the delivered source. Confirm that the Message-ID in the recipient's copy matches the value you expected. Some systems may add headers, but they should not need to replace a valid one.
Inspect reply headers. For a reply, compare In-Reply-To and References against the outbound Message-ID.
Classify any rejection correctly. A “missing valid Message-ID” rejection is a construction failure, not necessarily a bad mailbox or a list-quality problem.

Mailgun's event interface exposes the Message-ID in the message headers within additional event data, and its support guidance recommends supplying related Message-IDs when opening a ticket about a particular message. (help.mailgun.com)

Worked troubleshooting example

Suppose a customer says they replied to an account-verification email, but your system did not associate the response with their case.

Your outbound log shows:

message_id = <verify-1128-4b18@notify.example.com>

The inbound email source shows:

Message-ID: <CAK9wO8b1f9d@mail.recipient.example>
In-Reply-To: <verify-1128-4b18@notify.example.com>
References: <verify-1128-4b18@notify.example.com>

The headers prove that the recipient replied to the expected outbound message. If your application still did not attach the reply to the correct record, the problem is likely in your inbound parser or lookup logic, not in recipient behavior or email threading itself.

Now consider a different inbound message:

In-Reply-To: <verify-1128-4b18@notify.example.com>

If your database returns 500 separate outbound records for that same Message-ID, your issue is identifier reuse. The repair is not to change the parser. It is to fix the outbound generator and ensure every send instance gets a unique ID.

Message-ID best practices for transactional and campaign email

Use these practices whether you send password resets, receipts, onboarding sequences, product alerts, newsletters, or support communications:

Include a valid Message-ID on every outbound message.
Generate a new Message-ID for every new message instance.
Let your email provider or established library generate the field unless you have a clear reason to control it.
Persist the final Message-ID with application and provider identifiers.
Keep the value opaque; do not put recipient addresses, names, payment details, or sensitive account data in it.
Use In-Reply-To and References for genuine reply chains, not as a way to group unrelated campaigns.
Test raw headers, not just rendered inbox appearance.
Treat Message-ID rejection bounces as technical construction failures and fix the sender before classifying recipients as undeliverable.
Build retry logic that records prior submission state instead of blindly resending after ambiguous network failures.

For bulk sends, think carefully about recipient granularity. A single identical message sent to multiple recipients may be represented differently depending on the sending workflow and provider. If you need per-recipient reply tracking, event correlation, or message-level personalization, create individual recipient-specific message instances rather than relying on a shared send artifact. Mailgun specifically recommends recipient variables when one API call contains multiple recipients and a unique Message-ID is needed for each recipient. (mailgun.com)

What Message-ID cannot solve

A correct Message-ID is necessary email hygiene, but it is not a cure for every sending problem.

It does not authenticate your domain. Configure SPF, DKIM, and DMARC separately. It does not prove consent, remove spam traps, repair an outdated list, or prevent complaint spikes. It does not guarantee inbox placement, and it does not make unrelated messages belong in one inbox conversation.

It also cannot compensate for an invalid From address, malformed MIME content, broken links, oversized attachments, recipient-server throttling, or a poor sending reputation. Treat Message-ID as one precise piece of a reliable email system: small in appearance, but important because so many systems depend on a message having a stable identity.

Conclusion

A Message ID in email is the standardized identifier that gives every message a distinct technical identity. Its most visible role is enabling replies and threads through In-Reply-To and References, but its operational value goes further: it supports troubleshooting, provider support cases, duplicate detection, event correlation, and reliable inbound reply handling.

The implementation rule is straightforward: every outbound email should have one valid, globally unique Message-ID, and every new message should get a new value. Let established infrastructure generate it when possible; when you need custom control, use an opaque, high-entropy identifier, persist it before sending, and test the raw result.

FAQ

Is Message-ID the same as an email address?

No. A Message-ID resembles an address because it usually contains an @ symbol and a domain-like value, but it identifies a message, not a mailbox. Recipients cannot reply to a Message-ID.

Does every email need a Message-ID?

RFC 5322 treats the field as optional in the formal header set but says it should be present in every message. In practice, send one on every outbound message because some receiving systems reject mail with a missing or invalid value. (datatracker.ietf.org)

Should every recipient receive a different Message-ID?

Every distinct message instance should have a unique Message-ID. For individualized sends, per-recipient tracking, or personalized campaign content, unique recipient-level message instances are the safer design. The right behavior for one message addressed to multiple recipients can depend on your sending provider and workflow.

Can I use the same Message-ID when resending an email?

Generally, no. A new send is a new message instance and should receive a new Message-ID. The exception is an ambiguous transport retry, where you should first determine whether the original submission was accepted; otherwise, changing or reusing IDs without an idempotency strategy can create visible duplicates or confusing correlation.

Does Message-ID affect inbox placement?

It is not an inbox-placement score or authentication mechanism. But a missing, malformed, or duplicated Message-ID can cause rejections, broken threading, duplicate handling, and harder diagnostics, all of which can damage the practical performance of your email program.

Message ID in Email: Syntax, Threading, and Deliverability