Let's Stop Treating Email Forwarding (into Salesforce) Like a Simple Task — It’s Architecture

Email forwarding rules are great. They're simple, fast to configure, and generally just work. For most use cases, that simplicity is a feature. But the moment you (or your users) point those forwarding rules at Salesforce, the game changes.

Emails no longer remain simple communications. Those emails are now pipeline. Pipeline that consumes data storage and triggers automation. Pipeline that requires compliance discussions around retention, archiving and purging. Pipeline that can become a bloated data liability.

In other words, it’s architecture. And when it’s done incorrectly, it becomes one of the fastest ways to bloat your org’s storage without anyone noticing until the bill arrives.

Insert My Standard Statement Here

I drone on (relentlessly, unapologetically) about how EmailMessage is one of the very few objects in Salesforce where storage is calculated based on actual bytes consumed, not record count. It's what makes me fun at parties.

EmailMessage records can quietly eat 30... 50... 80% of your entire data storage allocation without anyone noticing until it's too late. It’s why we built Email Scrubber. Email Scrubber helps reduce this bloat and give admins a fighting chance against the slow, silent creep of email‑generated data.

Storage bloat from normal email activity is predictable. It grows at a pace you can model. It follows patterns you can observe. It’s the kind of problem you can solve with Email Scrubber.

Email Forwarding is a different animal. I’m happy to sell you Email Scrubber to clean up the mess, but let’s be honest: that’s not why we built it. Scrubber exists to handle organic email growth, not to compensate for architectural shortcuts.

Ok, What's the big issue with Email Forwarding?

In a typical forwarding scenario, a user defines a rule to send certain emails to a Salesforce Email Service, an Email‑to‑Case address, or something routed through Outlook integration. Its quick and straightforward setup. When X happens... forward the email to Salesforce. Easy checkbox. Easy mental model.

But we need to understand... For every rule that fires, Salesforce receives a full SMTP delivery... i.e. a full, independent email transaction. Salesforce does not understand the linkage and will not dedupe the records.

Let's Look at an example:

Toe users in Outlook. Both have forwarding rules to push certain emails into Salesforce.

Email Recipient	Forwarding Rule
Recipient 1	If Subject contains X → forward to Salesforce
Recipient 2	If Subject contains X → forward to Salesforce

Now let's sent one email to both recipients and include a small, compressed photo attachment.

The Expectation

Action	Result
Email sent to Outlook to Recipient 1 and Recipient 2
Forwarding rules push a single email to Saleforce	1 Email Message Record created consuming 18KB 1 Attach record is created to store the 800 KB image

This is what most people expect is happening.

The Reality

Action	Result
Email sent to both recipients
Recipient 1's rules fire	1 EmailMessage (18 KB) 1 Attachment (800 KB)
Recipient 2's rules fire	1 EmailMessage (18 KB) 1 Attachment (800 KB)

The reality? Two full deliveries. Two Records. Two attachments.

Ouch.

When forwarding rules are misconfigured, or layered on top of each other, the same email doesn’t just show up twice. It shows up twice in your storage bill.

Our simple example:

• Expected: 18 KB data + 800 KB file

• Reality: 36 KB data + 1,600 KB file

Double the footprint. Zero value added. More clutter. Faster erosion of storage.

The match gets more fun as you add addition recipients with forwarding rules.

Concerned you might have a problem?

If you suspect you have an issue, start at the source.

Look at your forwarding rules on your email server first. That’s where the duplication begins. Rework those rules so you have one centralized system rule instead of multiple personal rules. If that not possible, include a "stop processing more rules" condition within personal rule.

Once the upstream rules are cleaned up, turn to Salesforce and look for evidence of duplication. These examples are usually easy to spot. You’ll typically see the same email (same MessageIdentifier, same subject, same sender) processed within milliseconds or seconds of each other.

If needed, implement auditing to alert admins the moment this situation arises. Cleaning up forwarding‑driven EmailMessage bloat after the fact can get ugly fast. Once those duplicate SMTP deliveries hit Salesforce, you’re not just deleting a few records. You’re untangling automation runs, attachments, case threads, compliance artifacts, and storage footprints that have already multiplied.

If you need any assistance, we’re here to help — whether that’s diagnosing forwarding‑rule duplication, auditing your ingestion pipeline, or designing a cleaner, more intentional architecture that keeps your storage under control.