What threading technically requires

Email threading depends on message headers, not just subject-line matching: the original Message-ID, carried forward in the follow-up's In-Reply-To and References headers. Mail clients use these to group messages into a conversation. Without them set correctly, a message that merely repeats 'Re:' in the subject line won't reliably thread in most modern clients.

When staying in-thread genuinely helps

If the first message already established context, a properly threaded follow-up appears to the recipient as a continuation of one conversation rather than a second cold contact. That framing can lower the activation energy to respond, since replying feels like finishing an exchange rather than starting a new one.

When it backfires

If the first message got no visible engagement, a same-thread bump can read as a nagging continuation of something the recipient already decided not to engage with. A fresh thread with a genuinely different angle sometimes performs better in that situation than reviving the original, since it isn't visually anchored to a message that was already ignored.

The fallback when your provider can't preserve headers

Some sending APIs or ESPs don't expose reliable control over Message-ID and reference headers, especially across different sending accounts or providers. Attempting to fake threading without those headers set correctly produces broken or inconsistent client behavior — some clients thread it, others don't, and the result looks worse than a clean new message. If proper header control isn't available, starting a clearly new, standalone message is the more predictable choice.

Working the scenario

The first message has a stable Message-ID, and the reply system stores references, so the second touch can carry the original Message-ID in its In-Reply-To and References headers. That's the condition under which staying in-thread is technically reliable — the header data actually exists and is being preserved, not assumed.

Preserving the evidence trail

Whichever approach is used, storing the Message-ID and reference chain for every message sent — not just the first one — is what makes later touches able to thread correctly at all. This is worth keeping as structured data per message, not reconstructed from subject-line pattern matching after the fact.

Threading behaves differently across mail clients

Gmail's conversation view is fairly aggressive about grouping messages with matching subject lines even when headers are imperfect, while Outlook tends to rely more strictly on the actual header chain. A follow-up that threads cleanly in one client can appear as a separate message in another, which is worth testing directly in both rather than assuming one client's behavior generalizes.

What recipients actually notice

Most recipients don't consciously register whether a message threaded correctly — but a visibly broken attempt, like a 'Re:' subject with no visible original message included or quoted, can look careless in a way that a cleanly separate new message wouldn't. If proper threading can't be guaranteed, a clean standalone message is a safer default than a half-broken thread.

Deciding case by case rather than picking one rule for everything

Some teams standardize on always threading, or always sending fresh messages, to keep the system simple — but the two scenarios described above (context already established versus a message that got no engagement at all) genuinely call for different choices. A system flexible enough to support both, with a clear default and an explicit override, tends to perform better than a single hardcoded rule applied uniformly across every sequence.

Where the choice isn't obvious, defaulting to threading when the technical prerequisites (stable Message-ID, preserved headers) are met, and falling back to a new message when they aren't, is a reasonable rule that avoids the worst outcome — a broken half-threaded message — in either case.

The practical bottom line

Neither approach is universally correct — the right choice depends on whether the header data genuinely supports threading and whether the first message already earned some engagement. When those conditions aren't clearly met, defaulting to a clean, honest new message avoids the specific failure mode of a broken or misleading thread, which tends to look worse than simply starting fresh.

This is also a case where a small manual test — sending a real follow-up to a personal test account and checking how it actually renders — is worth more than reasoning about header behavior in the abstract, since client-specific rendering quirks are easy to get wrong without checking.

Where budget or engineering time is limited, defaulting to clean new messages and skipping threading complexity entirely is a defensible simplification — the downside is smaller than shipping a threading implementation that behaves inconsistently across the clients your recipients actually use.

Whichever approach is chosen, consistency across a given campaign matters more than the specific choice — mixing threaded and non-threaded follow-ups within the same sequence tends to look more inconsistent than either approach applied uniformly.

Field checklist

  • Set In-Reply-To and References headers to the original Message-ID to thread reliably, not just a 'Re:' subject.
  • Prefer in-thread follow-ups when the first message already got some engagement.
  • Consider a fresh thread with a different angle when the first message got no visible response at all.
  • Don't fake threading when your provider can't reliably control message headers — send a clean new message instead.
  • Store the Message-ID and reference chain for every sent message as structured data, not reconstructed later.
  • Verify actual thread behavior in a real mail client before assuming header support works end to end.

Primary sources

Standards and provider policies can change. These links are the reference points used for this field note.

  1. RFC 9051 — IMAP4rev2IETF / RFC EditorMailbox flags, UIDs, BODY.PEEK and IMAP4rev2 behavior.