Service Cloud · Email to Case
One email, two cases.
Five places Email to Case duplicates come from.
Duplicate cases in Salesforce Email to Case come from five places: a loop between Salesforce and your own mail, out of office and bounce replies, replies that lose their thread, one email sent to two service addresses, and replies to closed cases. Each leaves a different trace in the data, and each has a different fix.
I built Email to Case for a US trucking insurance agency that went from one Salesforce user to 35 in a year. Its org still holds two answers to the last of the five: an inactive rule that reopens the closed case, and the active one that opens a new case in the service queue and links it to the case before.
Salesforce Help read on 29 October 2026. Reviewed 29 October 2026.
The short answer
Why is Email to Case creating duplicate cases?
Because Email to Case opens a new case whenever it cannot match an incoming email to an existing one, and it never decides that two emails are the same request. A reply that lost its threading token, a message sent to two routing addresses, or your own notification coming back all look like new requests.
The matching order is in Salesforce Help, Email to Case Threading, read on 29 October 2026: a token in the subject or body first, then email headers, and a new case only when both fail. The table below maps what you see to where it comes from.
| What you see | Likely cause | First check |
|---|---|---|
| Dozens of cases with one subject within minutes | 01 A loop with your own mail | Sender and reply to of auto responses, queue and user emails, email alerts |
| Cases titled Automatic reply or Undeliverable | 02 Out of office and bounce mail | A rule in the mailbox before mail reaches Salesforce |
| A new case with RE: in the subject from someone whose case is still open | 03 A reply that lost its thread | Threading method in Setup, mail gateway, edited subjects |
| Two cases created in the same minute from one message | 04 One email to two service addresses | To and CC of both email messages |
| A new case right after a case was closed, often a thank you | 05 A reply to a closed case | What your org does with mail on closed cases |
Measure before fixing
How do you find which duplicates you have?
Group the email cases of the last 30 days by sender and subject, then open two cases from the biggest group and compare their email messages. The same Message ID on both means one email reached Salesforce twice. Different Message IDs mean two emails that Salesforce could not tie to one thread.
Then, with the Ids of two cases from the top row:
If the sender is one of your own addresses or a mail server, read causes 01 and 02. If
the later email starts with RE: and has its own Message ID, read 03. If both cases hold the
same Message ID, read 04. If the first case was closed before the second one opened, read
05. Both queries were run on 29 October 2026 in a Developer Edition org;
MessageIdentifier cannot be grouped, which is why the second query names the
cases.
Five causes
What causes each kind of duplicate, and what fixes it?
Two of the five are loops your own setup creates, two are mail that reaches Salesforce in a shape it cannot match, and one is a decision nobody made.
A loop with your own mail
Salesforce names four triggers in Email to Case Bounce Back Loop Creates Thousands of Cases: out of office replies to a routing address, an auto response rule whose Reply To or Sender’s Email is the routing address, a queue or user whose email is a routing address, and email alerts that send back to a routing address. Its loop detection acts only after more than 15 emails with the same subject, sender and body within 60 seconds, so a loop of one email every few minutes runs until someone notices. The fix is one routing address used nowhere else: not on a queue, not on a user, not as the sender of anything. With Notify Case Owners on New Emails switched on, an owner email equal to the routing address is enough on its own, according to Prevent Multiple or Duplicate Case Email Notifications. Both read on 29 October 2026.
Out of office and bounce mail
A client’s out of office reply to your answer, or a bounce from a mailbox that no longer exists, arrives at the service address like any other email. The fix Salesforce gives in the same bounce back article is upstream: a rule in the mailbox that moves messages such as Undeliverable or out of office notices into a folder before they are forwarded to Email to Case. It also suggests a validation rule on Case that blocks a subject keyword. Prefer the mailbox rule, because a keyword rule also blocks the client who happens to write that word. In the agency build, spam was closed with one click and never deleted, so anything a filter caught by mistake stayed one search away.
A reply that lost its thread
Lightning threading looks for a 23 character token in the subject or body, then for a stored Message-ID in the In-Reply-To header, then in References, then in the Outlook Thread-Index header, and only then opens a new case. The older Ref ID threading is in maintenance only mode; under it, a reply missing its Ref ID, often because the client edited the subject, opens a new case, and replies to case email alerts are not added at all. A mail relay that rewrites the Message-ID has to move the original into References, and any gateway or client that strips In-Reply-To or References makes new cases. Source: Email to Case Threading Limitations and Considerations, read on 29 October 2026. The fix: enable the release update Disable Ref ID and Switch to Lightning Threading, select both token settings and Use email headers for threading, and ask whoever runs your mail gateway whether it rewrites headers.
One email to two service addresses
Salesforce is blunt about it in the same limitations article: an email sent to several Email to Case routing addresses “causes unexpected results, and this use case isn’t supported.” Agencies run into it when a client writes to the certificates address and copies the service address. In the agency build, the rules that set the request type were chosen by the service address an email went to, read from To, CC and BCC alike, so a message copied to two service addresses picked up the rules of both. The fix is one routing address in Salesforce, every other public address forwarded to it by the mail server, and the request type read from the wording of the email rather than from the address.
A reply to a closed case
With threading working, a reply to a closed case is matched to that case like any other reply. Closed cases are outside every queue view, so unless a rule acts on the email, nobody sees it, and the client writes again later in a new thread, which is a duplicate by another route. What the rule should do is the one design decision in this list, and it has its own section below.
Closed cases
Should a reply to a closed case reopen it or open a new one?
Open a new case when closed cases feed reports or service clocks, and reopen only when they do not. Reopening moves the closing date and the handling time of work that was already counted as done. A new case leaves the old one as it was, provided it carries the link, the email, the contact and the account.
What the agency org does
The active rule runs on every incoming email to a closed case that was sent to the main service address. It opens a new case owned by the service queue, fills a Previous Case field with the closed one, and copies the email onto the new case so the history is there. The inactive rule next to it simply set the old case to Reopened. One detail decides more than it looks: the active rule checks for the main service address in To, CC and BCC, so a reply to a closed case sent only to another address stays on the closed case, unseen. Whichever rule you choose, it has to cover every address that can receive a reply.
What it missed
The new case gets the subject, the text, the email and the link, but not the contact or the account. The client is one click away on the previous case, yet a report by client does not see the new one. Two more fields in the same rule close the gap, and that is what I would set from the first day.
The pair of rules to test in your own org
In the agency org, closing a certificate or endorsement case sends the client a request for feedback through an email alert. Salesforce documents that in orgs created in Winter ’23 or later, with Lightning threading on, replies to email alerts are added to the case: see Threading Automated Case Emails, read on 29 October 2026. A client who answers “thank you” is therefore writing to a closed case, which is exactly what a new case rule acts on, if the reply reaches the service address. Each rule is right on its own. To test the pair, send the closing email to yourself, reply, and look at the queue.
Check your own org
Six checks before you merge the duplicates.
Merging cleans up cases that already exist. These six stop the next ones.
Which threading method runs
On the Email to Case page in Setup, settings named Insert thread ID in the email subject and Insert thread ID in the email body mean Ref ID threading. If they are not there, Lightning threading is on or available, and its settings contain the word token.
Both halves of Lightning threading
At least one token setting and Use email headers for threading are selected. Header matching alone misses clients whose mail software drops headers; tokens alone miss clients who edit the subject.
Every routing address used once
No queue email, user email, organization wide sender, auto response sender or reply to address equals a routing address.
No email alert sends to a routing address
Open every case email alert and flow that sends email, and read its recipients and its sender.
Out of office and bounces stopped in the mailbox
The service mailbox has a rule for automatic replies and undeliverable notices that runs before forwarding to Salesforce.
A reply to a closed case, tested
Close a test case, reply to its last email, and see what happens: nothing, a reopened case, or a new case. If it is a new case, it should carry the contact, the account and a link to the closed one.
Asked often enough to answer here
Questions
Can Salesforce merge duplicate cases?
Yes. A service rep can merge cases and chooses which one becomes the parent. After a merge, every new incoming email goes to the parent case, even one that belongs to the merged child. Merging cleans up the past; the five causes above decide whether duplicates keep coming.
Does Salesforce stop an infinite email loop on its own?
Partly. Salesforce documents loop detection that acts after more than 15 emails with the same subject, sender and body within 60 seconds, and notes that a few more cases can be created first. A slower loop is not caught, so the routing address has to stay out of every sender and owner field.
Does changing the subject line break threading?
It can. Salesforce asks that customers not edit the subject when replying, because depending on the email client a changed subject can remove the threading token. Lightning threading then falls back to email headers and opens a new case only if those fail too.
For an insurance agency, email to cases with the spam filter is the first stage on the insurance agency page: 80 to 110 hours, €5,200 to €7,150. How that build went is in the insurance agency case study, and the Service Cloud build for any service team is on the Service Cloud page.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 29 October 2026.
Read next
The question that usually comes after this one.
Case: Insurance agency, United States
Client service moved from shared inboxes to queues: every email a case with one owner, the request type read from the message, policy changes that cannot skip a step, Applied Epic kept.
Service Cloud Implementation Roadmap
Seven phases of a Service Cloud build in the order that keeps the cost down, and what each phase has to produce before the next one starts.
What Service Cloud Actually Costs a Year
Salesforce lists Service Cloud from €25 to €550 per user a month. Six things the list does not show decide what a year costs, and four of them can be changed.