Email-to-Case Replies Appearing on the Account, Not the Case

The situation

Your Email-to-Case routing address is configured and inbound emails create cases correctly. But when an agent replies from a case, replies to that reply behave unexpectedly:

• The reply does not appear under the Case’s Emails related list or activity timeline
• The reply appears on the contact’s Account record activity timeline, often under a banner reading “Emails are not shared with you”
• A SOQL query against EmailMessage for the affected case shows the agent’s outbound message is present but the inbound reply is missing entirely
• The body of the missing reply, if retrieved from the agent’s mailbox, still contains a Salesforce thread token like thread::<id>:: — confirmation that Lightning threading would have worked if the message had reached the correct inbox

To the contact it appears that Salesforce lost their reply. To the agent it appears that no reply was ever sent. Both are incorrect. The email exists — it landed somewhere Salesforce never monitors for case threading.

---

Root cause

This is almost never a platform bug. It is almost always a misconfigured From address on outbound case emails combined with Einstein Activity Capture doing exactly what it is designed to do.

The chain of events:

1. Outbound bypasses the routing address. When an agent clicks Email on a case and sends a reply, the Email Publisher’s From dropdown defaults to the agent’s own user email (for example [email protected]) instead of the verified Email-to-Case routing address (for example [email protected]). This happens when the routing address has not been added as an Organization-Wide Email Address (OWEA), or when it has been added but the Email Publisher layout does not expose or default to it.

2. The contact’s mail client replies to whoever sent the original message. The agent’s mailbox is now in the From or Reply-To chain. When the contact hits Reply, the response goes to the agent’s Outlook or Gmail inbox — not to the Email-to-Case routing address.

3. Salesforce only threads inbound email that arrives at the routing address. Email-to-Case threading — both legacy Ref-ID and modern Lightning header-based threading — keys off messages landing on the dedicated routing inbox such as support@<random>.<cell>.case.salesforce.com. The contact’s reply never reaches that address, so the platform has nothing to associate with the Case. EmailMessage.ParentId is never set.

4. Einstein Activity Capture finds the email anyway. EAC is connected to the agent’s mailbox and indexes their sent and received mail. It sees a message from the contact’s email address, finds a Contact record whose email matches, and binds the activity to that Contact’s parent Account. Result: the reply renders on the Account timeline with no link back to the Case it logically belongs to.

The reply is not missing. It is in the agent’s Outlook, surfaced by EAC on the Account. The case threading pipeline never saw it.

Secondary aggravator worth fixing at the same time: routing addresses with Save Email Headers = No lose the Internet headers that Lightning threading uses as a fallback when the Ref-ID or thread token is stripped by an intermediate mail server. Even when a reply does reach the routing inbox, headerless storage makes threading more fragile.

---

Diagnostic SOQL

Run this query to confirm you are hitting this exact root cause. Replace 500XXXXXXXXXXXX with the Case ID in question:

SELECT Id, Incoming, FromAddress, ToAddress, ParentId,
       ClientThreadIdentifier, MessageIdentifier,
       ReplyToEmailMessageId, CreatedDate
FROM EmailMessage
WHERE ParentId = '500XXXXXXXXXXXX'
ORDER BY CreatedDate

You are looking for outbound rows where Incoming = false and FromAddress contains an agent’s personal address rather than the routing address. If ClientThreadIdentifier is blank across all rows, Lightning threading is not engaged — Fix 5 below covers that.

To find all cases affected across the last 60 days:

SELECT ParentId, COUNT(Id)
FROM EmailMessage
WHERE Incoming = false
  AND FromAddress != '[email protected]'
  AND CreatedDate = LAST_N_DAYS:60
GROUP BY ParentId

Each ParentId returned is a case where at least one outbound email went from an agent’s personal address — and therefore likely has unrecorded inbound replies sitting in agents’ mailboxes.

---

Resolution

The fix is a configuration bundle, not a single toggle. Apply in order. Steps 1 through 3 are the load-bearing fixes.

Fix 1 — Add the routing address as an Organization-Wide Email Address

Setup → Email → Organization-Wide Addresses → Add

Use the same address as the Email-to-Case routing inbox (for example [email protected]). Verify ownership when Salesforce sends the confirmation email. Grant access to every profile or permission set that handles cases.

Fix 2 — Default the Email Publisher From dropdown to the OWEA

Setup → Object Manager → Case → Lightning Record Pages → Email Quick Action / Email Publisher

Confirm the From field is exposed and set its default to the OWEA created in Fix 1. If agents still see their personal address as the default, check the Email Publisher’s Predefined Field Values and any custom Lightning component that may be overriding it.

Fix 3 — Audit existing cases and establish process

Even with the default in place, agents can still select their personal address manually. Add the correct From address requirement to your case-handling process: all emails sent from a Case must use the OWEA.

Use the SOQL from the diagnostic section above to identify historical cases that were affected. For each returned ParentId, check whether any inbound replies are sitting unrecorded in the original agent’s mailbox.

Fix 4 — Enable Save Email Headers on the routing address

Setup → Service → Email-to-Case → Routing Addresses → edit the affected row → check Save Email Headers

This preserves the Internet headers that Lightning threading uses as a fallback when the thread token is stripped by an intermediate mail server or mail security gateway.

Fix 5 — Enable the Lightning Email-to-Case Threading release update

Setup → Release Updates → Enable Lightning Email Threading

This switches threading from the fragile legacy Ref-ID-in-subject scheme to header and token-based matching. Test in a sandbox first if your org has heavy email customisations or Apex triggers on the EmailMessage object.

Fix 6 — Recover specific replies that are already lost

For a case where an inbound reply is sitting in an agent’s mailbox and never reached Salesforce: have the agent forward the message — preserving the body so the thread::<id>:: token survives — to the long-form routing address (for example support@<random>.<cell>.case.salesforce.com). Lightning threading will pick it up and attach it to the original case. If the token has been stripped by the agent’s mail client, paste the content into a new EmailMessage on the case manually.

Fix 7 — Scope down Einstein Activity Capture (last resort only)

EAC is the proximate reason replies render on the Account at all. If enforcing From address discipline is not feasible — for example in a federated mailbox environment or with a third-party mail client — excluding the support team’s profiles from EAC stops the Account-side rendering. This does not fix the Case-side gap. The reply still will not appear on the Case. Treat this as suppressing a symptom rather than resolving the cause. Get sign-off from relevant stakeholders before changing EAC scope as it has broader implications for the sales and service teams using activity capture.

---

Verification

After applying Fixes 1 through 3, send a test reply from a case using the OWEA From address. Have the contact reply. Then re-run the diagnostic SOQL:

SELECT Id, Incoming, FromAddress, ToAddress, ParentId,
       ClientThreadIdentifier, MessageIdentifier, CreatedDate
FROM EmailMessage
WHERE ParentId = '500XXXXXXXXXXXX'
ORDER BY CreatedDate

A successful round trip looks like this:

Field	Expected value
Incoming	true on the inbound row
ParentId	Set to the Case ID
FromAddress	The contact’s email address
ClientThreadIdentifier	Populated (not blank)

If all four conditions are met, the configuration bundle is working correctly. The reply now threads to the Case rather than the Account.