A client groups a reply with earlier messages by inspecting its headers. The message IDs in `In-Reply-To` and `References` let it show one conversation.

## Which headers keep replies in one thread?

The replying message puts the parent message's `Message-ID` in `In-Reply-To`. It also carries the chain of related message IDs in `References`. A client can rebuild the conversation when several replies branch from one message.

[RFC 5322 section 3.6.4](https://www.rfc-editor.org/rfc/rfc5322#section-3.6.4) says `In-Reply-To` may identify the message or messages to which the new message is a reply. `References` may identify the related messages in the thread.

## What does a threaded reply look like?

A message with `Message-ID: <m1@example.com>` can receive a reply with these headers:

```text
In-Reply-To: <m1@example.com>
References: <m1@example.com>
```

A reply to that reply appends the new parent to `References`:

```text
In-Reply-To: <m2@example.com>
References: <m1@example.com> <m2@example.com>
```

Keep each ID exactly as the sender supplied it. Do not invent a new ID for the parent or copy a subject line as a substitute.

| Header        | Illustrative value       | Job                              |
| ------------- | ------------------------ | -------------------------------- |
| `Message-ID`  | `<reply@example.com>`    | Identifies this message          |
| `In-Reply-To` | `<original@example.com>` | Names the message being answered |
| `References`  | `<original@example.com>` | Carries the ancestry chain       |

These values are synthetic examples. A `Re:` subject alone does not identify the parent message.

## Why can a reply leave the thread?

A client may start a new conversation when `In-Reply-To` and `References` are missing or point at a different message. Changing the subject can also affect grouping because clients combine headers with their own subject rules.

A forwarded message is usually a new conversation. It contains the old content for context. It does not automatically identify the original message as its parent.

Reply sends to the author or `Reply-To` address. Reply-all also keeps the original `To` and `Cc` recipients, subject to the sender's mailbox rules. A client can still group or split messages differently, because rendering and grouping are client behavior.

## How do I preserve a thread with Bird?

When you reply through a Bird mailbox, call `replyEmailThreadMessage` for the received message at `POST /v1/email/threads/{thread_id}/messages/{message_id}/reply`. The operation uses the `mailbox` write scope. Bird derives the subject and reply headers. The outbound message stays in that thread. Use compose for a new thread. The [mailboxes guide](/docs/guides/email/mailboxes) shows the reply flow and webhook events for incoming mail.

If your integration sends raw mail, preserve the parent `Message-ID` in `In-Reply-To` and the full chain in `References`. Store those headers with the message record so retries use the same relationship.

## In short

- `In-Reply-To` names the message being answered.
- `References` carries the related message chain.
- A missing or unrelated header can start a new conversation.
- Bird mailbox replies stay in the received message's thread.

## Related resources

- [Email](/products/email) (product)
- [Send your first email](/docs/get-started/send-your-first-email) (docs)
- [Getting started with email](/learn/email/getting-started-with-email) (video)
- [Build your first integration](/learn/paths/integration) (course)

[Get an implementation brief](/learn/workspace?topic=email)