Keep replies tied to the intended exchange: distinguish message identifiers, follow Gmail and Microsoft Graph workflows, and test both sides of the conversation.
A prospect replies to an introduction, a teammate takes over, and the next answer arrives as a separate conversation. The message may contain the right words, yet the recipient has to reconstruct the exchange.
For agency teams, email threading is a handover detail worth testing. It concerns how messages relate to one another, rather than how you classify a reply or decide what to say next. This guide covers everyday email-client habits and provider API workflows.
1. Start from the message you are answering
Open the actual exchange before replying. Check the sending mailbox, the latest relevant message, the recipients, and any commitments already made. Use the email client's Reply action for a response to that message; choose Reply All only when the other participants should receive it.
Searching by subject can help locate an exchange, but a subject is a poor routing key on its own. Two unrelated prospects might both receive a message called “Next steps.” A teammate should have a reference to the intended conversation, not just those words.
Illustrative example: an account manager hands a prospect's conversation to a colleague. The handover includes the mailbox, a link to the exchange in the approved workspace, the current owner, and the next agreed action. The colleague opens that exchange and checks the recipient before drafting.
2. Keep message identifiers separate
Email headers describe relationships between messages. RFC 5322 describes Message-ID as an identifier for a particular message version. In-Reply-To identifies the parent being answered; for an ordinary single-parent reply, References carries the parent's references followed by its message identifier, when available. Subject describes the topic. The standard does not prescribe every mail client's interface. RFC 5322, sections 3.6.4–3.6.5
An integration also encounters identifiers defined by the provider. These are different fields, with different jobs.
| Field | What to use it for |
|---|---|
Internet Message-ID | Reference a particular email message |
In-Reply-To | Identify the message being answered |
References | Preserve the available message ancestry |
Gmail threadId | Identify the target Gmail thread in the documented API workflow |
Graph message id | Address a Microsoft Graph message resource |
Graph conversationId | Identify the conversation associated with a Graph message |
Microsoft separately exposes internetMessageId for the Internet-format identifier. Its default resource id can change when a message moves between containers; the documentation describes an immutable-ID option for applications that need it. Use clearly named storage fields instead of putting every identifier into one generic “message ID” column. Microsoft Graph message resource
Do not put a provider resource ID or conversation ID into an Internet reply header simply because it came from the same message record.
3. Follow Gmail's complete threading workflow
For applications adding a draft or message to an existing Gmail thread, Google documents three requirements: supply the target threadId, set compliant References and In-Reply-To headers, and match the Subject headers. Setting only the thread identifier does not satisfy that documented workflow. Gmail API: Manage threads
Treat those as Gmail API requirements. Do not assume another provider uses the same request fields. Google's guide does not spell out every subject-normalization detail, so test the subjects your integration actually produces rather than inventing rules for prefixes or capitalization.
If a bot receives a reply event, retain enough provider context to retrieve the parent in the correct mailbox. Build the response from that retrieved message, rather than locating a parent by subject alone.
4. Use a real reply operation where the provider offers one
Microsoft Graph exposes a reply action tied to an existing message, including POST /me/messages/{id}/reply. The documented action replies to the sender and saves the outgoing message in Sent Items; it is not the Reply All operation. For JSON replies, Microsoft says to respect the original message's replyTo recipients when present instead of assuming from is the destination. Microsoft Graph: Reply to a message
A successful Graph reply call returns 202 Accepted without a response body. That response alone does not establish delivery or show how the recipient's inbox grouped the message.
Prefer the provider's documented reply workflow over constructing a fresh message that merely begins with Re:. Confirm which mailbox the application is authorized to use, and inspect the intended recipients before sending. Keep production credentials and real customer messages out of test fixtures.
5. Test the sender and recipient experiences separately
Use mailboxes controlled by your team for a small QA exercise. Do not use a live prospect as the first test of a changed integration. Compare provider records with what appears in the recipient's inbox: a grouped sender view alone is not recipient-side evidence.
The following cases are illustrative test scenarios, not measured customer results.
| Test case | What to inspect |
|---|---|
| Reply to an existing message | The correct parent, mailbox, recipients, and provider conversation record |
| Start an unrelated message with the same subject | Your routing logic keeps the unrelated exchange separate |
| Hand the conversation to a colleague | The colleague can locate the intended parent and sees enough context to continue |
| Use a configured reply address | The draft targets the intended reply recipient rather than assuming the visible sender |
Record the test mailbox, case, expected relationship, observed provider result, and recipient-side result. Avoid a single “sent successfully” checkbox that hides those separate observations. Correct relationship data does not promise identical visual grouping in every email client.
6. Diagnose a split before sending again
If a reply appears separately, inspect the parent message, identifiers, headers, subject, mailbox, and provider operation. Capture the smallest controlled example that reproduces the problem. Do not repeatedly send the same follow-up to see whether one copy lands in the desired thread.
For the team, keep the approved conversation reference and current owner in the handover record. For the integration, keep provider identifiers distinct and use the documented reply path. Those habits make it easier to continue the intended exchange and to explain a mismatch when the sender's and recipient's views differ.
