Every sandbox refresh in Salesforce quietly resets a setting most admins forget exists: System Email Deflection. When that toggle reverts to off, any workflow, Flow, or Apex trigger that fires an email in your sandbox sends it to the real address on the record. A test order confirmation, a case closure notice, a password reset link. It goes out exactly as if the record lived in production, because as far as the email engine is concerned, it does.
This is not a theoretical edge case. It is one of the most common support tickets we see from mid-size Salesforce orgs running full or partial copy sandboxes for QA and UAT. The fix is not complicated once you know where to look, but most teams only find out after a customer calls asking why they got three identical invoices overnight.
Why Salesforce sandbox email deflection resets on refresh
Deflection is an org-level setting, not a sandbox-level one that survives a copy. Salesforce treats a sandbox refresh as a near-complete rebuild of the environment from a production snapshot. Most configuration carries over. Email deflection does not always stick, particularly after a full copy refresh where Salesforce rebuilds the org shell from scratch rather than patching an existing sandbox.
The result is a gap between the moment your refresh completes and the moment someone remembers to check Email Deflection under Deployment Settings. In a team running weekly or biweekly refreshes, that gap can open up repeatedly, and each time it does, it is pure luck whether anyone notices before an email goes out.
We have watched teams assume that because deflection was set correctly last sprint, it is still set correctly now. It is not a one-time configuration. It is a setting that needs to be verified on every single refresh, which is exactly the kind of repetitive, easy-to-skip step that gets dropped under deadline pressure.
What a leaked sandbox email actually costs you
The immediate damage is reputational. A customer who gets a stray renewal notice or a support ticket update from your sandbox starts wondering what else is broken in your systems. For a regulated business, in financial services or healthcare, a leaked email that includes account numbers or treatment details is not just embarrassing. It can trigger a breach disclosure obligation depending on what data the template pulled in.
There is a quieter cost too. QA teams lose trust in their own test environment once they know live sends are possible. Testers start hesitating before running end-to-end flows, which slows down the exact UAT cycle the sandbox was built to support. We have seen release calendars slip by a sprint because nobody wanted to be the person who triggered the next accidental blast.
And the fix, after the fact, is never just flipping the toggle back on. It usually means an email to the affected customers, a review of what template fired, and a conversation with legal about whether disclosure is required. All of that for a setting that takes ten seconds to check.
Where teams get this wrong beyond the deflection toggle
Deflection is the headline fix, but it is not the only control that matters. A few other gaps show up often enough to be worth naming directly.
- Org-wide email addresses carry over unmasked. If your production org sends from billing@yourcompany.com, that same address is live in the sandbox unless you deliberately swap it for a dummy sender.
- Active users keep real email addresses. Deflection stops external sends, but internal automated digests, approval notifications, and chatter mentions still route to whatever address sits on the user record, which is often someone's actual work inbox.
- Email services and inbound email handlers stay active. If your org uses Email-to-Case or an inbound parser, that integration can keep processing live inbound mail in a sandbox that was never meant to touch production traffic.
- Scheduled jobs survive the refresh. A nightly Apex scheduled job that sends summary emails will keep running in the sandbox on its original schedule unless someone disables it post-refresh.
Each of these is manageable on its own. The problem is that they all need checking at the same time, right after a refresh, by whoever owns the environment that week. That is a lot to hold in one person's head during a release crunch.
A sandbox refresh checklist that actually prevents leaks
The teams that stop having this problem build a short, mandatory checklist into the refresh process itself, not as a suggestion but as a gate the sandbox cannot pass to QA without clearing.
| Step | Why it matters |
|---|---|
| Verify Email Deflection is on | Blocks all outbound system email to external addresses |
| Mask or swap org-wide email addresses | Prevents real company addresses from appearing as senders |
| Anonymize user email fields for non-admins | Stops internal digests and approvals reaching real inboxes |
| Disable or repoint Email-to-Case routing | Keeps live inbound support mail out of the test environment |
| Pause scheduled Apex jobs that send mail | Avoids automated sends on the original production schedule |
None of this is difficult engineering. It is discipline, applied consistently, every single refresh cycle. That consistency is exactly what breaks down when the process relies on a person remembering a step rather than a script enforcing it.
Why masking and deflection need to happen together
Deflection stops the email from leaving your org. It does not stop the data from sitting there, readable, inside a sandbox that twenty people have access to. A test user with a real customer's email address visible on screen is still a data exposure risk, even if no message ever gets sent.
This is where masking earns its place in the same workflow. MaskEzee, our own masking tool, replaces real email addresses, phone numbers, and other PII across a full copy sandbox the moment it is created, before any QA user logs in. Combine that with deflection turned on by default and you have two independent layers: one that stops sends, one that removes the sensitive data entirely. If either layer fails, the other still holds.
Relying on deflection alone is a single point of failure. We would argue it is the weaker of the two controls anyway, since it is a setting someone can accidentally toggle off, while masked data simply is not there to send in the first place.
Building the fix into your DevOps pipeline, not your memory
The real solution is automation that runs the moment a sandbox refresh finishes, before any human logs in to start testing. A post-refresh script, triggered through your deployment pipeline, can flip deflection on, swap org-wide addresses, mask PII, and disable scheduled email jobs in one pass, consistently, every time.
This is the gap DeployEzee is built to close for teams running frequent refreshes alongside active release cycles. Instead of a checklist sitting in a wiki page that someone forgets to open, the controls run as part of the deployment process itself, with the same reliability as any other automated step in your pipeline.
If your org still treats email deflection as a manual post-refresh task, it is only a matter of time before a real customer gets a test email. The fix costs less than the cleanup, and it only needs to be built once.
Frequently Asked Questions
Does Salesforce automatically turn off email deflection after a sandbox refresh?
Deflection does not reliably carry over from production, especially after a full copy refresh that rebuilds the org shell. You need to check and re-enable it manually or through automation after every refresh, since Salesforce does not guarantee the setting persists.
What is System Email Deflection in Salesforce?
It is an org-level setting under Deployment Settings that blocks system-generated emails from leaving a sandbox and reaching real external addresses. When enabled, emails are logged instead of sent, which prevents test automation from contacting live customers.
Can masking tools like MaskEzee prevent sandbox email leaks on their own?
Masking removes real email addresses from the sandbox so there is nothing sensitive to send, but it does not stop a misconfigured email service or scheduled job from firing. It works best paired with deflection and disabled scheduled jobs, not as a standalone fix.
Why do scheduled Apex jobs keep sending emails after a sandbox refresh?
Scheduled jobs and their cron schedules typically survive a sandbox refresh along with the rest of the metadata. Unless someone manually pauses or deletes them post-refresh, they continue running on their original schedule, including any email sends they trigger.
How often should we verify email settings after a Salesforce sandbox refresh?
Every single refresh, without exception, since deflection and related settings do not reliably carry over each time. The safest approach is automating the check as part of your deployment pipeline rather than relying on a manual step someone might skip.