> ## Documentation Index > Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt > Use this file to discover all available pages before exploring further. # Threading and reply behavior > How replies thread, who gets CC-ed, and when the agent will not reply. When an email agent answers, it threads the reply into the right conversation, decides which addresses to CC, and decides whether to reply at all. This page explains those three behaviors and the configuration that controls them. For the settings themselves, see [Configuring an email agent](/email/configuring-an-email-agent). ## How replies thread Threading uses standard RFC message headers, not subject matching. * Every outbound email carries a `Message-ID` header. When a recipient replies, their mail client echoes that ID in `In-Reply-To` and `References`. * On each inbound email, Anyreach collects the IDs from `In-Reply-To` and `References` and looks for an existing conversation whose stored message IDs match. * If a match is found, the inbound email threads onto that existing `EMAIL` conversation. If there is no match, a new `EMAIL` conversation is created and seeded from the inbound message. ``` First email (no In-Reply-To/References match) └── new EMAIL conversation created Follow-up email (In-Reply-To matches a stored Message-ID) └── threaded onto the same conversation ``` The conversation tracks the latest inbound `Message-ID` and a growing `References` chain so that the agent's next reply sets `In-Reply-To` and `References` correctly and the recipient's mail client keeps everything in one thread. Threading is keyed on message IDs, so a reply with a changed subject line still threads correctly, and two unrelated emails that happen to share a subject do not get merged. ## Reply-all CC audience When the agent replies, it replies to the sender and CCs the rest of the thread, mirroring a reply-all. The CC list is computed from the latest inbound message's `To` and `Cc` recipients, then filtered: | Removed from CC | Why | | ------------------------------------------ | ------------------------------------------------------------- | | The agent's own addresses | Avoid replying to itself | | The sender (`From`) | They already receive the reply directly | | Duplicate addresses | Deduplicated case-insensitively; first-seen display form kept | | `no-reply` / bounce / postmaster addresses | Never a human you can reply to | The dropped automated mailboxes are matched on their local-part, including `no-reply`, `noreply`, `do-not-reply`, `donotreply`, `mailer-daemon`, `postmaster`, `bounce`, and `bounces` (with common spelling variants). ## When the agent will not reply Several checks can suppress a reply. The conversation and inbound message are always recorded either way; only the outbound reply is skipped. Each skip records a reason that is surfaced in the [conversation detail](/conversations/conversation-detail) view. | Condition | Behavior | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Auto-generated, bulk, or list mail | Skipped. Detected from `Auto-Submitted` (any value other than `no`), `Precedence: bulk`/`list`/`junk`, `List-Id`, `List-Unsubscribe`, or `X-Auto-Response-Suppress` headers. | | Mail from another platform agent | Skipped. The sender's `From` address resolves to another Anyreach agent, preventing agent-to-agent loops. | | Suppressed sender | Skipped. The sender is on the org's suppression list for the channel. | | DMARC failure | Skipped when `require_dmarc_pass` is on and the inbound did not pass DMARC. | | CC-only under `never` | Skipped when the agent was only CC'd (not a `To` recipient) and `cc_reply_policy` is `never`. | | Conversation judged complete | Skipped when the reply gate judges no reply is needed, for example a bare acknowledgment of a wrap-up the agent already sent. | The sender-identity check looks only at the `From` header, not `Reply-To`. A human whose mail carries a `Reply-To` pointing at a platform agent (common with mailing lists and help-desk forwarders) still receives a reply. ### CC-only handling When the agent is only CC'd on a message, `cc_reply_policy` decides what happens: | `cc_reply_policy` | Behavior when CC-only | | ----------------------- | -------------------------------------------------------------------------------------------------- | | `never` | Never reply | | `always` | Always reply | | `conditional` (default) | Defer to the reply gate, which can recognize the agent being addressed by name even when only CC'd | When the agent is a direct `To` recipient, the CC policy does not apply and the reply gate still runs. ### Closing the conversation The reply gate also reports whether the conversation is complete. When `auto_close_on_conclusion` is on (the default), a complete conversation is closed proactively instead of waiting for the idle timeout. The system is conservative: any uncertainty defaults to replying and not closing. ## Quoted history Inbound email bodies are trimmed before the agent reads them. Anyreach splits off quoted reply history and signatures, keeping only the new top-post content. Quote markers it recognizes include `On ... wrote:` attribution lines, `----- Original Message -----`, leading `From:` headers, and any line beginning with `>`. On the outbound side, `quote_history` controls whether prior history is quoted back beneath the reply: | Field | Type | Default | Description | | --------------- | ------- | ------- | --------------------------------------------------------------------------------------------------------------------------- | | `quote_history` | boolean | `false` | When on, append the prior inbound message as a quoted block beneath the reply, attributed to its sender, mail-client style. | With `quote_history` off (the default), the reply contains only the agent's response and is not padded with the prior thread. ## Related Set `cc_reply_policy`, `require_dmarc_pass`, `quote_history`, and the rest of the email channel properties. See the recorded reply decision and reason for each inbound turn.