Message-ID: why every email needs a unique identifier

Message-ID is a header field that contains a globally unique identifier for an email message. It is generated by the originating MTA (or MUA) at the time the message is created, and it stays with the message throughout its entire lifecycle: delivery, storage, forwarding, replies. No two messages should ever share the same Message-ID.

Format

RFC 5322 defines Message-ID as a string enclosed in angle brackets, structured as a local part, an "@" sign, and a domain:

The local part is typically a combination of timestamp, process ID, random string, or internal counter. The domain part is usually the hostname of the server that generated the message. Together they guarantee uniqueness: the timestamp and random component prevent collisions on the same server, and the domain prevents collisions across servers.

Some systems produce Message-IDs that look quite different:

Gmail uses a Base64-encoded string. SendGrid uses a UUID. The format of the local part is not standardized beyond being unique, so each implementation picks its own scheme.

Message deduplication

The primary job of Message-ID on the receiving side is deduplication. If the same message arrives twice, because of a network failure, a retry after a timeout, or delivery over multiple paths, the mail client or server compares the incoming Message-ID against what it already has. A match means a duplicate, which can be discarded.

Gmail deduplicates aggressively. Send the same message (same Message-ID) to a Gmail address twice and the second copy will not appear in the inbox. This protects users, but it can confuse senders during testing: the message "never arrived" when it was actually dropped as a duplicate.

Threading: In-Reply-To and References

When you reply to a message, your mail client takes the Message-ID of the original and puts it in the In-Reply-To header of the new message. The References header carries the full chain of Message-IDs in the thread:

Mail clients use References to group messages into conversations. Without correct Message-IDs this breaks entirely: replies appear as separate messages rather than as part of a thread.

Message-ID in bulk sending

For an ESP, Message-ID also identifies a specific message in the logs. When a recipient reports spam or a bounce comes back with an error, the Message-ID lets you pull up exactly that message in your sending platform and see what went wrong.

A properly configured ESP generates a unique Message-ID for each recipient in a campaign. A broadcast to 50,000 addresses produces 50,000 distinct Message-IDs. If an ESP reuses a single Message-ID across all copies, recipient-side deduplication can silently drop legitimate messages.

Missing or spoofed Message-ID

A message without a Message-ID is an anomaly. RFC 5322 requires the header. If the sending MTA does not generate one, the receiving server typically adds its own, but the absence of a sender-supplied header is itself a signal to spam filters that the source is misconfigured or suspicious.

Reusing someone else's Message-ID can cause a message to be dropped by deduplication. Some spammers copy Message-IDs from legitimate mail hoping to slip past filters, but the result tends to be the opposite: the message is discarded because the recipient already has that ID.

The domain in Message-ID

The part after @ in Message-ID usually matches the sending server's domain. Some spam filters check this. If a message claims to come from company.com but the Message-ID contains @random-vps.net, that mismatch can raise the spam score.

Strict domain checking in Message-ID is not a universal standard, but the rule of thumb is simple: use your mail server's domain. ESPs do this automatically, populating Message-ID with their own domain or your custom sending domain.

Message-ID and Feedback Loop

When a recipient clicks "Spam" in Gmail or Yahoo, the mailbox provider sends an Abuse Report (ARF) to the address registered in your Feedback Loop. That report includes the Message-ID of the original message. The ESP uses it to identify which message triggered the complaint, which campaign it came from, and which sender account was responsible.

Without a unique Message-ID per recipient, tying a complaint back to a specific message is impossible, which makes complaint rate analysis unreliable and harder to act on.

Message-ID in delivery diagnostics

When troubleshooting a delivery problem, Message-ID is the primary key for log searches. An administrator on the receiving server can look up a message by its ID and see whether it was accepted, rejected, quarantined, or delivered. Without it, the search falls back to timestamps and IP addresses, which is slow and imprecise on busy servers.

Postfix, for example, records Message-ID for every processed message. One grep by ID shows the complete path through the system: receipt, processing, handoff to the next hop, and final status.