Let's Exploit Salesforce Auto-Responses

Okay — yes, this is a bit of baiting. I’m not suggesting this article walks readers through how to exploit auto‑responses. Instead, it highlights a very real and increasingly common tactics: attackers abusing Salesforce auto‑response mechanisms to gather intelligence and ultimately target your organization or your customers.

Processes like Web‑to‑Case and Web‑to‑Lead are designed to be simple, low‑friction features that quietly aid customer support and sales operations. With Email‑to‑Case, for example, a customer sends an email to a support address, Salesforce creates a case, and an automatic acknowledgment is sent back. It’s convenient, predictable, and usually harmless.

But like any automated workflow, it can be abused.

In this post, we’ll explore how scammers can weaponize Email‑to‑Case auto‑responses, what information in those responses can be used against your organization, and what adjustments you can make to reduce exposure. You can’t eliminate all abuse, but understanding the risks helps you make smarter decisions and adjust your processes.

First up, let's review how an attacker gains key information from an auto-response.

Let's Attack

A scammer begins by identifying a support email address — something most companies publish publicly.

A scammer sends a fictious email to the companies support email address. If the email address is supported by Email-to-Case, Salesforce automatically creates a case, and an automatic acknowledgment is sent back providing a case number, company branding, email signatures, and email headers.

Those headers are the real prize. They reveal technical details that can later be used for spoofing, phishing, and infrastructure mapping. This includes mail servers and services, routing paths, anti-abuse tools in place, standardized internal email addresses, and authentication mechanisms (i.e. SPF, DKIM, DMARC).

Armed with this information, the scammer can craft highly convincing attacks.

They may target your company with phishing emails that reference real case numbers or internal terminology. Or they may target your customers, using social engineering and spoofed messages that look indistinguishable from legitimate support communications.

Why It Matters

Scammers don’t need to breach your Salesforce instance to start exploiting it. They just need basic information. And much of that information is readily available in an auto‑response.

Let's Prevent these attacks

Unfortunately, there’s no way to completely prevent determined attackers from gathering this type of metadata. Auto‑responses are just one of many reconnaissance tools they use.

But you can make their job harder.

One effective approach is to strengthen the logic behind your auto‑responses. Instead of replying to every inbound message, consider adding rules that limit recipients of an automatic acknowledgment. For example, you might choose to auto‑reply only to known domains, or verified customers, or senders who pass SPF/DKIM/DMARC or contacts already present in your CRM.

If the sender doesn’t meet your criteria, you can suppress the auto‑response entirely or route the message for manual review. This simple change dramatically reduces the amount of metadata you expose to unknown or suspicious senders.

Additional safeguards can protect your organization and your customers.

Protecting Your Organization

• Evaluate the legitimacy of inbound emails before sending auto‑responses

• Educate internal teams about spoofing and phishing risks

• Consider routing auto‑responses through a controlled mail system (such as Outlook or a secure relay) instead of sending them directly from Salesforce

• Minimize the amount of metadata included in automated messages

Protecting Your Customers

• Use distinct branding for automated emails so they can’t be easily replicated

• Keep auto‑responses minimal and generic

• Avoid exposing internal terminology, routing addresses, or unnecessary details