From inbound mail to a threaded reply

The incoming side

A received email carries message identifiers that relate it to earlier mail. DakNode resolves an inbound thread using the sender's In-Reply-To header first, then its References chain from newest to oldest. This is more reliable than treating a reused subject such as ‘Question’ as proof that two messages belong together. When those identifiers do not match a stored message, the service does not invent a relationship.

The resulting message and thread are readable with the same scoped API key that owns the inbox. The raw email is parsed and stored before an application sees the clean message through the API or a webhook. A second inbound message can join the same thread while keeping its own message identity.

The outgoing side

To answer a conversation, the caller supplies the thread identifier on the send request. The server selects the newest received message in that thread and derives the outgoing In-Reply-To and References headers. Callers do not provide those headers themselves. That matters because a wrong or attacker-chosen References chain can merge unrelated conversations in a recipient's mail client.

Accepting a send request and delivering a message are different events. The outbound path uses a required Idempotency-Key so retrying the same request does not create a second send. Authorization is checked before acceptance and again just before dispatch; a later suspension can still prevent a queued message from going out. Delivery and failure feedback are recorded separately from the API's acceptance response.

The client's final say

Correct headers make a reply eligible for threading, but each recipient's mail client chooses how to display a conversation. In a production Gmail test, a DakNode reply appeared inside the original conversation. That is a useful end-to-end check, not a guarantee about every client. For an integration, inspect the stored thread and treat the recipient's display as an external behavior to test where it matters.