Email-to-Case setup in Salesforce: decisions, steps and tests

Your service team already answers customers from a shared mailbox, often in Microsoft 365, and your accounts and contacts already live in Salesforce. Email-to-Case is the piece that joins the two. Setting up Email-to-Case in Salesforce takes four jobs, done in order. Turn it on in Setup, create a routing address for each support mailbox, forward that mailbox to the long address Salesforce generates for it, and test threading and loops before customers depend on it. The clicks are the quick part. The decisions behind them, and one forwarding setting on your mail server, are where most setups stall.

If you are still deciding whether to leave the shared inbox at all, start with Shared inbox vs ticketing system: when to make the switch. This article assumes the decision is made and Salesforce is the destination.

Decide four things before you open Setup

Which mailboxes become routing addresses. Each support address your customers write to gets its own routing address in Salesforce, with its own settings. Salesforce’s threading guidance says customers should write to one routing address at a time, because a message sent to two of them gives unpredictable results. If billing@ and support@ both exist, decide now whether they stay separate or one of them is retired.

Who owns a new case. A routing address can send its cases to a user or a queue, overriding the default owner in Support Settings. A queue is almost always the better choice, so a case never sits with one person who is out that week.

What each case is stamped with. Every routing address sets the Case Origin, Priority and Record Type of the cases it creates. Agree the values with whoever runs the service reports, because changing them later splits your history in two.

Who hears about failures. When Salesforce cannot create a case, it emails the Automated Case User. Salesforce’s own best practice is to give that user an address a person or internal alias actually reads, and never a routing address, which can start a loop.

While you are deciding, check the Case object itself. An email only fills in certain fields, so a required field or a strict validation rule will quietly block every email case. Salesforce’s troubleshooting article lists this among the first causes to rule out.

Email-to-Case setup in Salesforce, step by step

You need the Customize Application permission for these steps.

Turn it on. In Setup, find Email-to-Case, turn on Email-to-Case and the on-demand service, and save.
Set Support Settings. Choose the default case owner and the Automated Case User, using the monitored address from the decisions above.
Add a routing address. Give it a routing name, the customer facing email address, and the case owner, priority, origin and record type you agreed. Turn on Save Email Headers. When we set this up, it is on from the first day, because when a reply lands on the wrong case, the headers are what you will need to work out why. Accept Email From can restrict which senders or domains are accepted, which suits a dealer or partner only address.
Verify the address. Salesforce sends a verification email to the routing address. Only the person who started the verification can complete it, and an unverified address does not apply its settings to cases.
Copy the Email Services Address. This is the long address Salesforce generates for the routing address. Salesforce has a known article on bounces caused by hidden characters from copy and paste, so check the address character by character wherever you put it.
Forward the mailbox to that address, as described in the next section.
Send a first test from an outside account and look for it in a Cases list view that shows all new cases, not Recently Viewed.

Forwarding support mail from Microsoft 365 or Gmail

Most tutorials show only Gmail. For a company on Microsoft 365, the forwarding rule is the step most likely to fail without anyone in Salesforce noticing. Microsoft’s external forwarding documentation explains that in 2021 automatic forwarding to outside addresses became off by default for new organizations, and for existing ones that were not already using it. The rule saves without complaint, but each forwarded message bounces back to the mailbox with a 5.7.520 “does not allow external forwarding” error, not to Salesforce. Salesforce receives nothing, so it looks like a Salesforce fault.

Ask your Microsoft 365 administrator to allow automatic external forwarding for the support mailbox only, set explicitly in the outbound spam policy rather than left on the system default, and to forward a copy while keeping the original in the mailbox. Salesforce also recommends keeping that copy, so a message that fails processing can be resubmitted.

For Gmail, add the Email Services Address as a forwarding address. Gmail sends a confirmation code, which arrives in Salesforce as a new case; copy the code from the case description back into Gmail to finish.

Whatever sits in between, a relay, a filtering service or a custom mail server, must keep the References and In-Reply-To headers intact. Salesforce says that stripping or changing them causes new cases to be created for replies.

Keep replies on the right case and stop loops

Salesforce now matches replies with Lightning threading, which combines a threading token in the email with the email headers, and falls back to the headers when no token is found. The older Ref ID method is in maintenance only. Replies thread well as long as customers keep the subject line, write to one routing address, and nothing in the mail path rewrites headers. After a sandbox refresh changes the org ID, threading tokens from the old org no longer match, so test in the refreshed sandbox before trusting it.

Loops are the other risk. Salesforce’s article on bounce loops describes how an out of office reply or a bounce sent to a routing address becomes a case, triggers an auto-response, and repeats. Salesforce’s loop detection stops new cases only after more than 15 matching emails within 60 seconds. Prevent it at the source: the Reply To and sender address on auto-response rules must not be a routing address, no queue or user that owns cases may use a routing address as its email, and your mail team can filter “Undeliverable” and out of office subjects before they reach the forwarded mailbox.

The published limits rarely bite, but know them: 250 inbound emails per case in a rolling 24 hours, messages under 25 MB including headers and attachments, and text truncated at 131,072 characters of body and 32,000 of headers. All email services together are capped at 1,000 messages a day per user license, up to 1,000,000.

Seven test emails before the team switches over

Run these on the live forward in a quiet hour, before the team stops working from the inbox, from accounts outside your company, and check each result on the case:

An email from an existing contact, to confirm the contact and account are filled in.
An email from an address Salesforce has never seen, to see what an unmatched case looks like to your team.
A reply to the agent’s first response, which must land on the same case.
A reply with the subject changed, so you know what your setup does when customers do it.
A message with a large attachment, such as a photo set from a job site.
An out of office reply sent to the routing address, which must not start a chain of cases.
An email sent to two of your support addresses at once, to see the result customers will get.

When all seven behave as expected, move the team to working cases in Salesforce, and stop answering from the old shared inbox while keeping it as the archive copy. Then watch the Automated Case User’s mailbox during the first week, because that is where any failed email will show up first.