In-Reply-To vs References: How Email Replies Link Together

Every reply email carries two threading headers that look similar and do different jobs. In-Reply-To names the one message you are replying to. References names every message in the ancestor chain, from the first email in the thread down to the one you are answering. Both are defined in the same paragraph of RFC 5322, and the difference between them is what decides whether your reply lands inside the conversation or starts a new one.

This post explains what each header is, when a client relies on which, why a stripped or malformed References list splits threads into fragments, and what a mail client can actually do about it.

The verdict up front#

If you only remember one thing, remember the shape: In-Reply-To is a pointer to the parent, References is a chain of ancestors. When a reply is composed correctly, In-Reply-To holds one Message-ID (the immediate parent), and References holds the parent's References list plus the parent's Message-ID appended to the end — so the chain grows by one link every reply.

Neither header is optional in practice. In-Reply-To alone is enough for a client to pair a reply with its parent, but only if the client already has the parent. References is the fallback that rebuilds the thread when the parent copy is missing, when a mailing list has re-injected the message, or when a subject line has drifted so far that a subject-based fallback would fail. Robust clients — and the IMAP THREAD REFERENCES algorithm in RFC 5256 — use both, with References doing the heavier structural lifting.

The practical rule for anyone building or debugging mail: preserve References verbatim on every reply. If a client, filter, or list manager strips or truncates it, the thread will split at that message, and no amount of subject-matching will reliably put it back together.

In-Reply-To vs References at a glance#

One header names a parent, the other carries the family tree. This table is the whole distinction in one view — most of what follows is worked examples of these rows.

Where In-Reply-To wins#

In-Reply-To is the direct, unambiguous pointer. It carries exactly one job: identify the parent. RFC 5322 says the field "will contain the contents of the 'Message-ID:' field of the message to which this one is a reply." One reply, one parent, one identifier.

That simplicity is what makes it the right primitive for tight pairings. When a client already holds the parent message locally, In-Reply-To is all it needs to attach the reply to it — no walk through the ancestor chain required. It is also what a lightweight mail agent or a script uses when it wants to say, precisely, "this message answers that one," without pretending to know the wider conversation.

In-Reply-To also handles multi-parent replies. RFC 5322 permits more than one Message-ID in the field, for the unusual but real case where a single reply is directed at multiple earlier messages — say, a summary that answers two open questions at once. References cannot express that relationship because it describes a chain, not a set of parents.

Where References wins#

References is what keeps a conversation coherent when things go wrong. Its job is to carry the whole ancestor chain, so any receiving client can rebuild the thread even if it never saw the intermediate messages.

RFC 5322 spells out how it grows: a reply's References field "will contain the contents of the parent's 'References:' field (if any) followed by the contents of the parent's 'Message-ID:' field." Each reply lengthens the list by exactly one identifier. Read left to right, the References header of the newest reply is the entire history of the conversation.

This is why References is the primary key in the RFC 5256 IMAP THREAD REFERENCES algorithm — the same algorithm most clean threading implementations descend from. The algorithm walks the References list to build a tree; when the References list is missing, it falls back to In-Reply-To; when that is also missing, it falls back to subject-line matching, which is where threading starts to break down in the real world.

The classic failure case is a mailing list that rewrites headers on the way out and strips the ancestor chain in the process. A reader who receives the list copy of a message will get an In-Reply-To pointing at a parent Message-ID the reader has never seen — because the reader is on the list, not on the original To line — and no References list to fall back to. The thread splits at exactly that message.

How mail clients actually implement threading#

Because both headers are defined by the same standard, you might expect every client to behave the same. They mostly do — but the fallbacks differ, and the differences are what split a thread across accounts.

The IMAP THREAD extension in RFC 5256 defines two threading algorithms — ORDEREDSUBJECT and REFERENCES — and it is the REFERENCES algorithm that modern clients target. That algorithm uses References first, then In-Reply-To, then a normalised Subject as a last resort. Some clients hew closely to it; others add heuristics on top, especially Gmail, whose conversation view groups messages by a mix of headers, subject-normalisation, and Message-ID pairing that is not fully documented on the public side.

There is no license to buy and no per-seat cost to any of this — RFC 5322 and RFC 5256 are open standards, freely implementable. The cost, when it appears, is in the software layer: how strictly a client follows the algorithm, how it recovers when a message is orphaned, and whether it exposes the underlying graph or hides it inside a flattened conversation. Verify the exact behaviour of your own client on its help pages before you rely on it — Gmail's help documents, Outlook's threading settings, and Thunderbird's mail preferences all describe their own take on the same headers.

Who should focus on which#

The two headers matter to different audiences in different ways. If you only read mail, threading is invisible — but the moment you send from more than one client, run a mailing list, or write filters, the distinction becomes practical.

• If you write a mail client or an agent that composes replies: set both headers, every time. In-Reply-To = parent's Message-ID. References = parent's References list + parent's Message-ID, appended in that order. Never invent, never truncate from the right.
• If you run a mailing list or a gateway: preserve References verbatim on every message you re-inject. Rewriting headers is what turns a two-hundred-message thread on the mailing list into two-hundred singletons in each subscriber's inbox.
• If you administer mailboxes: an orphaned reply — one whose In-Reply-To points at a Message-ID nobody in the folder has — is normally not a bug in your client. It is usually the sender's client omitting References, or a list stripping it. Check the raw headers before blaming the receiver.
• If you build workflows on top of mail — CRMs, ticketing systems, AI agents that draft replies — treat References as the conversation key, not the subject. Subjects drift; References does not, unless something upstream broke it.
• If you read mail across more than one account in one place: the client that reads References correctly is the one that keeps your cross-account conversations intact. That is the one job for a threading implementation and it is where the differences show.

A third position, honestly: the client that reads both correctly#

This post compares two headers, not two products, so the honest third position is the layer that reads them. Any mail client can, in principle, follow the RFC 5256 REFERENCES algorithm; the differences show up in how it recovers when one of the two headers is missing or malformed, and in whether it can rebuild a conversation that arrived across more than one account.

That is where AI Emaily sits. We read Message-ID, In-Reply-To and References on every message we sync, apply the REFERENCES algorithm across your Gmail, Outlook and IMAP accounts in one unified view, and drop the duplicate copies that a unified inbox is otherwise prone to. When our AI email assistant drafts a reply, it composes both threading headers correctly — parent Message-ID in In-Reply-To, parent's References list plus parent's Message-ID appended in References — so the reply lands in the same thread on the recipient's side, not in a fresh one. We build AI Emaily; the mechanics live at /docs/threading and the product page at /features/ai-email-assistant. Packaging is a 7-day free trial on Pro/Autopilot — card required, $0 if you cancel before day 7 — with the current numbers on /pricing.

The concession worth naming: Thunderbird has implemented the RFC 5256 REFERENCES algorithm more strictly than we have in one specific respect. Its threaded view draws the actual ancestor tree, orphans included, so you can see the graph. Ours collapses siblings into a single conversation, which is the right default for most readers and hides the tree when you do want to see it. If your job is auditing threading structure on a mailing-list archive, Thunderbird is still the better tool for that. For everything else — cross-account threading, AI drafting that respects the chain, and not losing replies when a sender's client forgets References — the client that reads both headers into one conversation is what you want.