When you create/refresh a Sandbox, all (but the refreshing) users email addresses get crippled with a nice "example.com". Using security codes via email, this basically breaks the possibility for other users to login at the fresh sandbox, unless their email addresses get changed...

We have written some Apex fixing the email-addresses back for some or all users, but the extra loop in confirming the email-address change often is ignored or forgotten by the affected users, so that if these users should login usually some time has passed and the email-change-confirmation is expired after 72h. So eventually most of them still can't login and again they are wasting time of others. This really sucks.

For sure this email-mangling is done by Salesforce with a purpose in mind and for sure this is designed as an very powerful security feature to prevent normal users form getting spammed by Sandbox-Emails. Only that it bothers us a lot and has killed already so much of our time, that I would happily turn it OFF once and for all.

Is that possible? If so, how?

Bonus question:

Also the email deliverability is usually reduced on fresh Sandboxes. Also here we would love to have the full-thing without the need of extra clicks. At Setup > Email-Administration > Deliverability is there a way to get the Access Level on "All email" instead something less by default after a refresh?

  • 1
    Just a theoretical question how about running a batch job in sandbox post creation to replace example with your email domain? Nov 1 '18 at 10:34
  • 1
    @codeyinthecloud still ALL those users will need to click on the confirmation-link in a email which Salesforce sends to ALL users, if their email get changed. The new email-address is only updated AFTER each user has clicked on that link. This step is usually forgotten by my users. Even training does not help. They forget. They are humans. So it is bothering over and over and over again, killing time repetitively. I want to get rid of this. Totally.
    – Uwe Heim
    Nov 1 '18 at 11:37

Only that it bothers us a lot and has killed already so much of our time, that I would happily turn it OFF once and for all.

Is that possible? If so, how?

It is not possible to turn off this feature of removing @example.com from the email addresses after a sandbox refresh. And it's not recommended to go that route. As you have rightly figured out that Salesforce does it for purpose. And one of the main reasons to use example.com is because:

This domain is established to be used for illustrative examples in documents. You may use this domain in examples without prior coordination or asking for permission.

So, you don't have a way to accidentally trigger emails from sandbox to end users. (I have seen this causing issues based on my previous experience)

Another perspective to this is that with every sandbox refresh, you don't really need all Users to be back on that sandbox. E.g., if you are refreshing a developer sandbox, you only need the developers out there and say not the QA or Business Users.

If you have a CI/CD process in place, then you will not really require "frequent" sandbox refreshes. However still considering you want to refresh your sandboxes and that you need all Users to be able to login, below is one of the approaches you can try out.

  1. Deactivate all Users after refresh
  2. Load Users again with their valid email addresses. The only caveat here is that you will need to also have unique username for all those users
  3. Set a generic password for all Users using setPassword() SOAP API

With this approach, you communicate the username and password to targeted audience and that whenever they login, they will be forced to reset their password.


I did something similar in the past. Create an apex class, to go over the users (I did it for admins - so all our admins can always log to any sandbox). and modify their email address by removing the '@example.com' Add that class to fire when the sandbox refresh is complete.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.