Salesforce appends .invalid to every user's email address when a sandbox is created or refreshed — on purpose, so test environments can't email real addresses. The side effect: verification links, welcome emails, and password resets for those users are sent to an address that doesn't exist, so users click a link, land on the login page, and can't get in. The per-user fix takes under a minute: in Setup > Users, edit the user, remove .invalid from the email address, check "Generate new password and notify user immediately," and save — that sends the verification and the password setup in one pass. For users who already clicked a verification link and got stuck, use Reset Password from the user list after the address is clean. This matters for any admin who has refreshed a sandbox, created users in one, or heard "I never got the email" right after a refresh.
user@domain.com.invalid so the test org can't email real people..invalid address, so users can never set a password.Because sandboxes copy production data — including every user's email address — and a test environment that can email real people is a genuine risk. Workflow alerts, approval requests, scheduled reports, and password resets firing from a sandbox look legitimate to recipients and create confusion at best and phishing-shaped incidents at worst. Salesforce's answer is blunt and effective: on refresh, every user email in the new sandbox is rewritten with an .invalid suffix. The address alex@yourcompany.com becomes alex@yourcompany.com.invalid, which resolves nowhere. Salesforce documents this behavior directly — it is intentional, not a bug or a sync error.
Two details matter for planning. First, this happens on every refresh, not just the first — a monthly refresh cadence means a monthly cleanup task. Second, the same trap appears outside refreshes: when an admin creates or edits a user in a sandbox and mistypes or pastes an address carrying the suffix, the same failure follows. The pattern to recognize is always "the address on the user record is not a deliverable address."
The failure mode is confusing because half of it works. The user exists. They appear in the user list. They may even receive a verification email — once. Here's the chain that produces the classic stuck state:
.invalid, no one receives it — or worse, the user received it earlier, clicked it, and now sits at a login page with no password..invalid, the reset email is undeliverable, so self-service recovery is impossible.Recent releases have tightened email-address verification further, which makes a clean, deliverable address more load-bearing than it used to be. Treat the user email field as part of the login mechanism, not a profile detail.
This is the fix that resolves the majority of "I can't get into the sandbox" tickets:
.invalid from the Email field so the address is the user's real, deliverable address.If the user already clicked a verification link earlier and is stuck at the login page, the order matters: fix the address first, then use Reset Password from the user list. Resetting before the address is clean just sends another email into the void. Once the address is deliverable, the reset arrives normally.
After a full refresh, fixing users one at a time doesn't scale. The bulk path:
.invalid against the Email column handles it. Keep usernames untouched; sandbox usernames carry their own .sandboxname suffix and must stay as-is.One scoping decision saves real time: not every production user needs sandbox access. Many teams fix emails only for the testers and admins who actually work in the sandbox, and leave the rest .invalid — which is arguably the safer state, since those users can't be emailed by accident.
Put it in the refresh runbook. A sandbox refresh checklist that ends at "refresh complete" is missing its last mile:
.invalid problem and any deliverability misconfiguration in one step.If users are locked out of a sandbox today, start with the per-user fix for the people who are blocked — it genuinely takes under a minute each — and schedule the bulk cleanup for the full user list right after. If refreshes are a regular event, write the user-email step into the runbook so it stops being a surprise. And if sandbox management generally keeps generating tickets — access, data, deliverability, stale copies — that's a sign the refresh process wants an owner and a checklist, not more heroics.
Vantage Point's Salesforce consultants build sandbox strategy into every implementation: refresh runbooks that include user-email remediation, tester lists, and post-refresh verification, so test environments are usable the same day they're created. For teams that want this handled continuously, managed services cover sandbox hygiene alongside day-to-day admin — including the access tickets that follow every refresh when the process is informal.
Vantage Point is a Salesforce and HubSpot Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Salesforce appends .invalid to every user email during sandbox creation and refresh so the test environment cannot send mail to real addresses. It is an intentional safety feature, and it repeats on every refresh — which is why the fix belongs in the refresh runbook.
First correct the email address on the user record (remove .invalid), then use Reset Password from the user list. Resetting before the address is fixed sends the email to an undeliverable address; resetting after delivers normally and lets the user set a password.
It sends the user a fresh password-setup email as part of the save — combining address verification and password creation in one pass. When you correct a sandbox email, ticking this box prevents the common "verified but has no password" stuck state.
Yes. Export the User object with ID and Email, strip the .invalid suffix from the Email column (leave usernames alone), and update with Data Loader. Then trigger password resets or have users self-serve with "Forgot password," which works once addresses are deliverable.
Not necessarily. Many teams correct emails only for admins and testers who actually use the sandbox, leaving other users' addresses invalid. That is both less work and safer — users without sandbox duties can't receive confusing test email.
SSO authentication doesn't depend on the Salesforce password, so SSO users may log in fine with an .invalid address — but they still won't receive any email the sandbox sends. If those users test approval or alert emails, their addresses still need correcting.