The Message-ID header

Message-ID is a unique identifier that the software creating an email stamps on it, in the form <something@domain>. Mail clients use it to thread conversations and to spot duplicates, and administrators use it to find a message in logs. Its right-hand side usually reveals which system generated the message (Gmail, Outlook, a newsletter platform, a PHP script), which can be a useful clue. But nothing checks it: a sender can write any Message-ID they like, so it proves nothing on its own.

Message-ID: <20261026131405.3Kd9Zr@out.example.net>

What the standard says

RFC 5322 §3.6.4 defines Message-ID together with its two companions, In-Reply-To and References. The key points:

• Every message should have one. It's technically optional (RFC 5322 §3.6, where the field table lists it as "SHOULD be present"), and a message may carry at most one.
• The ID must be globally unique, and the system that generates it is responsible for that uniqueness.
• The syntax looks like an email address inside angle brackets, but it isn't one. You can't send mail to it. The angle brackets aren't part of the ID itself.
• The RFC recommends putting a domain on the right of the @ and something locally unique on the left, such as a timestamp plus a counter or random string.
• The ID belongs to one version of one message. Adding trace headers in transit doesn't change it, but editing and re-sending creates a new message with a new ID.

Since RFC 6532, the ID may technically contain UTF-8, but §3.3 of that RFC notes generators may prefer to stay in ASCII so threading keeps working with older software. Almost all IDs you'll see are ASCII.

Who generates it

Usually the first piece of software that builds the message:

• A mail app or webmail generates it when you hit send.
• A sending platform or app framework generates it for newsletters and notifications.
• The submission server adds one if the client didn't. Many servers do this, though it's not required by SMTP.
• Some sending services replace it. Certain platforms overwrite the ID on outgoing mail with one of their own, so the ID reflects the service rather than your app.

What each system generates differs, which is why the format is a fingerprint. Typical shapes (illustrative; exact formats change over time):

Message-ID: <CAJx3b+Rk2fQe9mTz0pXw@mail.gmail.com>
Message-ID: <AM0PR02MB1234ABCD5678@AM0PR02MB1234.eurprd02.prod.outlook.com>
Message-ID: <0100019a2b3c4d5e-6f7a8b9c-1234-5678-9abc-def012345678-000000@email.amazonses.com>
Message-ID: <5f3e2a1c9b8d7@www.example.com>

The last one, a short hex string at a website's host name, is typical of a script on a web server calling a mail function.

What its domain tells you, and what it doesn't

The domain after @ is a hint about which system built the message. It is useful in two ways:

• Consistency. A message claiming to be from a large bank's systems, with a Message-ID at a shared web host or a random residential host name, is inconsistent. A newsletter whose ID is at the newsletter platform's domain is consistent even though the From address is the brand's own domain.
• Origin hints. IDs sometimes include the internal host name of the machine that created them, revealing the real platform behind a message.

What it doesn't tell you:

• It's not authenticated. No part of SPF, DKIM or DMARC checks the Message-ID domain. An attacker can copy a real ID format exactly.
• A mismatch with From is normal. Third-party senders, help desks and mailing platforms routinely generate IDs at their own domain. Don't treat a Message-ID domain different from the From domain as a red flag on its own.
• It's not a sign of DKIM coverage unless the signature's h= list includes message-id (most do). Even then, the signature only proves the ID wasn't changed after signing. See the DKIM-Signature guide.

Tip: A missing Message-ID is more interesting than an odd one. Most legitimate software always sets it, and some receiving systems penalize mail without one. A missing ID, combined with other problems, points to hand-rolled sending code.

Duplicates

Because the ID is supposed to be unique, some mail systems and clients use it to detect duplicates and may show only one copy. Exactly how each provider de-duplicates varies and is mostly undocumented. Legitimate duplicates happen when:

• A message reaches you twice by different routes, such as directly and through a mailing list, or via a forwarding rule. The ID stays the same.
• A sending system retries after a timeout and the first attempt actually succeeded.

Two different messages sharing an ID is a bug in the generating software, or a sign that someone copied a real message's headers into a forgery. If you're investigating a suspected fake and have a known-good message from the same sender, comparing IDs is a quick check: identical IDs on different content means one was built from the other.

Don't confuse the Message-ID with the queue IDs in Received headers. The id clause in a Received: line is a per-server tracking number that changes at every hop (RFC 5321 §4.4). The Message-ID stays the same from start to finish.

In-Reply-To and References: threading

When you reply, your mail client copies IDs from the message you're answering (RFC 5322 §3.6.4):

• In-Reply-To holds the Message-ID of the message you replied to (the parent).
• References holds the parent's References list followed by the parent's Message-ID. Over a long conversation, it becomes the chain of IDs back to the first message.

Message-ID: <reply-2@mail.example.org>
In-Reply-To: <reply-1@mail.example.net>
References: <original@mail.example.org> <reply-1@mail.example.net>

Clients build conversation threads from these, though many also fall back to grouping by subject line.

These fields matter for safety. In "thread hijacking," an attacker who has stolen a mailbox, or a copy of old messages, replies inside a real conversation. The In-Reply-To and References will point to genuine earlier messages, so the email lands in the right thread and looks familiar. Correct threading proves only that the sender knew the IDs. It doesn't prove the sender is who they were last time. Check the authentication results and the Reply-To address, and look out for a new look-alike domain.

Checking it yourself

In the analyser, the Message-ID appears with the other identity fields. When judging a message, read it as a supporting clue: does the generating system make sense for the claimed sender? Then base the real verdict on the DKIM and DMARC results recorded by your own provider.