Most clients describe Email-to-Case as a checkbox. "Customers email us, we want it to become a case, can you turn that on by Friday." And technically they are right, you can enable the feature, register a routing address, and watch a test email land in a queue inside half an hour. The trouble is that the half-hour version is also the version that, three weeks after go-live, produces a 200-case spam pile every morning, splits one customer's reply thread across four separate cases, and silently drops the email where someone attached a 100MB product video.
I have built this for a telco and for an online retailer, and the pattern is always the same. The intake mechanism is trivial. What separates a working support channel from a clogged one is the routing design, the threading behaviour, the spam strategy, and on the reply side, a template library that agents actually want to use. Those four things never come up in the "just turn it on" conversation, which is exactly why I bring them up first.
So this is the version I wish more teams scoped before signing off: how Email-to-Case actually behaves once real customers start sending real email, and how to build the reply side so handle time goes down instead of up.
On-Demand is the only real choice now, so design around its limits
There used to be a genuine decision here. On-Premise Email-to-Case ran a Salesforce-managed agent on the customer's own mail server, polled the mailbox, and pushed messages in over the API. Its one real selling point was bypassing the inbound size cap, lifting attachments from 25MB up to around 1.5GB while keeping the mailbox internal.
That decision is gone. Salesforce deprecated the On-Premise agent in 2024, and you cannot stand up a new install. Any greenfield org runs On-Demand, where Salesforce generates a managed email service address and your customer's mailbox simply forwards inbound mail to it. No server to maintain, Salesforce owns the infrastructure, and the whole thing is genuinely a thirty-minute setup. The certification exam still asks "when would you use On-Premise," and the honest 2026 answer is that you would not.
What matters in practice is that On-Demand carries a hard 25MB ceiling across subject, body, and attachments combined, and Salesforce throttles inbound rate. When a customer emails a large video or a stack of high-resolution receipts, Salesforce rejects the message and the customer hears nothing back. The clean answer is not to chase a bigger limit, it is to set the expectation: an auto-response that tells the sender to upload large files through a portal, plus an Experience Cloud upload flow that links the files back to the case. Decide this during discovery, not after the first angry "I emailed you and you ignored me."
Routing addresses are where the real design lives
A routing address is simply the mailbox a customer writes to, but each one carries its own configuration, and that is the leverage point most teams underuse. Per address you set the case origin, the owner (typically a queue), and optionally the priority and record type. You can also tick "Save Email Headers," which I always do early in a project because raw headers are what you need when threading or sender matching misbehaves.
The reason this matters is that one org usually has several mailboxes, and they should not all feed the same generic bucket. For the retailer I worked with, returns, general support, and VIP each had a distinct routing address. The returns mailbox set an origin of "Email - Returns," dropped cases into a dedicated Returns Team queue, and stamped a "Return Request" record type. General support went to a different queue. The VIP mailbox routed to a named senior agent with its own record type. Three addresses, three routing behaviours, and the work was sorted by line of business from the very first second a case existed, with no assignment rules straining to undo a bad default.
One operational detail that bites people: after you create a routing address, Salesforce emails a verification link to that mailbox and you have seven days to click it. Miss the window and the address goes inactive, inbound mail stops creating cases, and nobody notices until the queue is suspiciously quiet. Get IT to forward that verification email to whoever is doing the admin work, and confirm the click. There is a "Verify" button on the routing detail page to resend it.
For anything beyond standard subject and body capture, the standard routing config runs out of road. The retailer wanted the order number pulled out of subjects like "Return request order 1234567" and linked to the actual order record. That is a record-triggered flow on case create, scoped to the returns origin, that regex-extracts the number, queries the order, and stamps the lookup plus the account. It hit about 95% of cases cleanly, with the malformed-subject remainder escalated for manual handling. When the logic gets genuinely complex, you drop to an Apex class implementing Messaging.InboundEmailHandler, which gives you full control over parsing, sender filtering, and case creation.
Threading and spam are the two failures that quietly ruin the queue
Two problems do more damage than any other, and both are predictable.
The first is reply threading. Salesforce matches a customer's reply back to the original case using a Thread-ID header it injects into outbound mail. The problem is that some email clients strip custom headers, so the reply arrives with no thread marker and Salesforce, doing exactly what it is told, creates a brand new case. Now one conversation is scattered across multiple cases. The fix is to enable "Use Thread ID in Email Subject," which puts a visible [ ref:_xxxx ] token into the subject line that survives header stripping. It is not bulletproom, a customer who hand-edits the subject can still break it, so train agents to use Merge Cases when they spot the duplicate.
The second is spam. A public support mailbox attracts newsletters, phishing, and junk signups, and Email-to-Case will happily turn every one into a case. The returns mailbox at the retailer was generating around 200 spam cases a day until we dealt with it. There is no built-in spam filter on the routing address, so the strategy is layered: enable email authenticity verification with DKIM and SPF checks so failing mail can be rejected, filter at the mail server before anything forwards into Salesforce, and add a custom Apex handler for domain blacklisting when needed. Combining upstream Gmail filtering with a custom handler cut spam cases by about 95%.
A close cousin of the spam problem is the auto-response loop. Your auto-response rule confirms "case received," the customer's out-of-office replies, that reply creates a new case, which fires another confirmation, and around it goes. Salesforce has loop detection that skips known auto-responder patterns, and you should restrict auto-responses to new email threads, but I still add a handler check for "Out of Office" and "Auto Reply" subject prefixes for the cases the built-in detection misses.
The reply side: templates, letterheads, and macros that cut handle time
Intake is only half the job. The other half is how fast and how consistently agents reply, and that is a template story.
Use Lightning Email Templates for any new build. Classic templates still function in Lightning Experience, but the HTML editor feels like 2012 and there is no automatic migration tool, so re-create rather than carry the legacy forward. The one case where Classic earns its place is when you genuinely need looping or conditional logic in the body, such as rendering a list of order line items, because Lightning templates cannot do that natively the way a Visualforce template can. Outside that edge case, Lightning wins.
Pair templates with an Enhanced Letterhead. The letterhead holds the logo, the compliance footer, the hotline, and the privacy and unsubscribe links, and crucially Salesforce renders it at send time rather than baking a snapshot into each template. That means you update the legal footer once and every template using that letterhead picks it up on the next send, which is exactly the behaviour compliance teams expect but rarely believe until you demonstrate it.
Merge fields are how the body personalises itself, with {!Case.Contact.FirstName} and cross-object paths like {!Case.Order__r.Order_Number__c}. Two limits to respect. Cross-object references stop at five levels deep, so when a path needs to climb a six-level account hierarchy you build a formula field to shorten it. And empty merge fields render as blank, not an error, so "Dear ," looks careless. Guard the greeting with a fallback. The other quiet trap is folder sharing: a template the author can see but the agent cannot is almost always a folder shared to the wrong public group, so share to a group that spans every tier that needs it.
Where this genuinely pays off is in stacking the pieces. The Lightning Email Composer has an Insert Article button that drops Knowledge content straight into the body and links the article to the case, which both saves retyping and gives you reporting on which articles actually resolve which cases. Layer a macro on top, select template, insert article, send, set status to Closed, save, and an agent completes a routine return approval in one action instead of several minutes of manual composing. Because the macro contains a send, it is irreversible and prompts for confirmation first, which is the right amount of friction.
One last gotcha that generates support tickets of its own: do not send transactional mail from a no-reply address. Customers reply to it, the reply bounces, and they complain they cannot reach you. Either forward the no-reply mailbox into your support address so replies become cases through Email-to-Case, or send from a verified Organization-Wide Address like support@ so the reply path actually works.
The throughline across all of this is that Email-to-Case rewards the team that treats it as a designed channel rather than a toggle. The feature will create cases on day one regardless. Whether it deflects work or generates it depends entirely on the routing, threading, spam, and template decisions you make before the first real customer ever hits send.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
