Reply Threading: How Email Conversations Stay Linked

Email threading depends on three message headers: Message-ID, In-Reply-To, and References. Provider identifiers such as Gmail's threadId or Microsoft Graph's conversationId can help inside one provider, but the reply headers carry the relationship in an ordinary Internet message.

When a reply starts a new conversation, inspect its raw source. Check that the parent has a Message-ID, the reply points to it, and the References chain comes from the parent rather than the subject.

Email threading signals at a glance

How do Message-ID, In-Reply-To, and References work?

RFC 5322 says every message should have one Message-ID. A reply should carry In-Reply-To and References when the relevant parent identifiers exist. The identifier is enclosed in angle brackets, as in <abc123@sender.example.com>.

In-Reply-To contains the parent message's Message-ID. References copies the parent's existing chain, then adds the parent's Message-ID.

If the parent has no References field but has one In-Reply-To identifier, carry that identifier forward before the parent's Message-ID.

An original message might contain:

Message-ID: <abc123@sender.example.com>

Its reply can contain:

Message-ID: <def456@reply.example.net>
In-Reply-To: <abc123@sender.example.com>
References: <abc123@sender.example.com>

A reply to that second message appends the immediate parent:

Message-ID: <ghi789@sender.example.com>
In-Reply-To: <def456@reply.example.net>
References: <abc123@sender.example.com> <def456@reply.example.net>

The generator must make a Message-ID globally unique. Whether a later copy should keep that identifier depends on whether it is still the same message. A forwarded message or newly authored copy can be a new message, so a claim that the identifier never changes across every forward or copy is too broad.

How do provider thread IDs fit in?

Provider IDs make mailbox operations easier. Gmail groups messages under threadId, while Microsoft Graph includes conversationId and conversationIndex on each message. These values are specific to the provider's data model.

Gmail requires more than a requested threadId when an application adds a draft or message to a thread. The References and In-Reply-To headers must comply with the message standard, and the Subject headers must match. A provider thread identifier therefore does not let an application force unrelated mail into a conversation.

Use the provider identifier when reading or updating that provider's mailbox. Preserve correct Internet message headers when sending across providers, gateways, and mail clients.

How are threads reconstructed from raw messages?

A mailbox may receive replies out of order or miss an ancestor. A threading algorithm therefore builds relationships from all available identifiers and can create a placeholder for a referenced parent that is not present locally.

The commonly cited JWZ threading algorithm starts with the ordered identifiers in References. It uses In-Reply-To when a usable References chain is absent, then applies subject grouping later for messages that still have no parent relationship. Subject matching is a fallback display heuristic, not a replacement for reply headers.

Do not invent a universal limit of ten identifiers. RFC 5322 does not set that rule. If your implementation needs a cap, make it an explicit product boundary and keep the most relevant parent context.

How do you build reply headers correctly?

Use the parent message as the source of truth:

1. Look at the exact Message-ID from the parent, which can be found in the stored raw message or in the selected headers.

2. Put that identifier in the reply's In-Reply-To field.

3. Copy the parent's References field and append the parent Message-ID.

4. If the parent has no References field but has one In-Reply-To identifier, put that identifier before the parent's Message-ID.

5. Generate a unique Message-ID for the new reply.

6. Keep the subject consistent when a provider, such as Gmail, requires it for API thread membership.

Do not infer ancestry from the visible subject when valid identifiers exist.

Subjects can change, be translated, or show up in unrelated messages.

Use subject matching only as a final display fallback because it is weak evidence of a parent-child link.

Gateways can alter a message after submission. Compare the submitted message with the raw message received at the destination to find any header that a relay or security product removed or rewrote.

Why do email replies stop threading?

Start with evidence from one broken reply and its intended parent:

1. Check that the parent has a valid Message-ID and the reply has its own unique identifier.

2. Compare In-Reply-To to the parent identifier, taking into account the angle brackets in the wire representation.

3. Verify that References has the current parent sequence, immediately followed by its direct parent.

4. Compare sent and received raw headers to find gateway changes.

5. For Gmail API sends, confirm the requested threadId, reply headers, and subject all agree.

6. Test out-of-order delivery and a missing ancestor rather than only a clean two-message exchange.

Reply-To solves a different problem. It tells a reply composer which address should receive the response. A changed destination may alter who receives the reply, but it does not define the reply's parent chain and does not replace In-Reply-To or References.

How does Sendmux represent email threads?

The documented Sendmux Mailbox API exposes thread metadata, paginated message summaries, and cleaned thread content. Message content can include selected message_id, in_reply_to, and references header values, which gives an agent or application the evidence needed to inspect a conversation.

The public POST /mailbox/messages/send request accepts recipients, reply-to addresses, subject, text or HTML, approved custom X- headers, and attachments.

It does not accept in_reply_to or references as public input fields. Use the published API schema when building a send request.

What should you test before shipping email threading?

Run the same conversation through at least two receiving systems. Keep the raw source for each message and assert both the provider view and the Internet message headers.

Include these cases:

• one original message and one direct reply;

• a reply to a reply with an existing References chain;

• messages delivered out of order;

• a missing ancestor that is referenced by a child;

• a gateway between the sender and recipient;

• a subject change where valid parent headers remain;

• a provider API send with its native thread identifier.

The pass condition is not merely that two messages look grouped in one client. The headers must express the intended parent relationship, and each provider-specific request must satisfy that provider's documented thread rules.

Sources

• RFC 5322: Internet Message Format

• Gmail API guide: Manage threads

• Microsoft Graph message resource

• JWZ message threading algorithm

• Sendmux Mailbox API introduction

• Sendmux thread operations