TL;DR
- Salesforce is making email address the default first step on
login.salesforce.comandtest.salesforce.com. Sandboxes started in August 2026 and production orgs in October 2026. - Usernames are not retired. A "Log In with Username" option stays on the page, and
login.salesforce.com/?login=1goes straight to it. - My Domain login pages do not get the email change, and Experience Cloud login pages get neither change. API logins are untouched.
- The users who will call the help desk are the ones who share an email address, have accounts in several orgs, or have an email address they cannot receive mail at.
- Automated UI tests and RPA bots that type a username into the first box will break. Salesforce documents the fix.
What You'll Learn
- Exactly what Salesforce changed, where, and when, from the release note itself
- Which of your users will notice, and why
- Three SOQL queries that find the accounts that will struggle
- How to fix automation, and what to tell users before the page changes under them
The Problem
Every Salesforce user has two identifiers that look alike. The username is formatted like an email address and must be unique across all of Salesforce, so plenty of people end up with something like jane.doe@acme.com.prod or jane@acme.com.uat. The email is where Salesforce sends mail. People remember their email. Almost nobody remembers which suffix their admin chose for their username.
Salesforce's answer is to let people log in with the address they already know. That has been an option on the login page since 2025. What changed this year is that it became the default: the box on login.salesforce.com now asks for an email address first.
For most users this is an improvement. For a predictable minority it is a confusing morning, and the gap between those two groups is something an admin can close in an afternoon if they do it before the rollout reaches their org.
Common Questions This Article Answers:
- Is Salesforce getting rid of usernames?
- Why can't some users log in with their email address?
- How do I keep automated tests working after the login page changes?
Quick Answer
Nothing about authentication changes: passwords, MFA, passkeys and SSO work as before. What changes is the first question on the standard login page. Do four things:
- Find users who share an email address or whose email is a placeholder, and fix the data or tell them to use their username.
- Point automation at
?login=1, or better, at your My Domain login URL. - Encourage everyone to bookmark your My Domain URL (
https://yourcompany.my.salesforce.com), which the email change does not touch. - Tell users before it happens, in two sentences, with a screenshot.
What Salesforce actually changed
Salesforce's release note, Prepare for Login Changes, describes two changes rolled out one after the other. They are easy to confuse, so it helps to keep them apart.
Change 1: username-first login. The login page asks for the username alone, then shows the password field or prompts for a passkey on a second screen. Salesforce's stated reason is passkeys: once it knows who you are, it can offer the passkey instead of a password. Sandboxes finished by 2 July 2026, and production orgs and mobile apps started on 20 July 2026. This one does apply to My Domain login pages.
Change 2: email as the default. The first box asks for an email address instead of a username. Sandboxes started in August 2026, production orgs in October 2026, and mobile apps are tentatively planned for late 2026. Salesforce notes it moved the start forward from a previously announced September. This one applies to login.salesforce.com, test.salesforce.com and the mobile apps, and not to My Domain login pages.
Neither change affects Experience Cloud login pages. Salesforce's Log In with Your Email Address page adds the rest of the boundaries: email login is only for human users logging in through the UI, integration and service users cannot use it, and it "doesn't affect API logins or My Domain."
What your users will see
A user types their email address. Salesforce looks up which accounts use that address and works out how each one authenticates.
- One account, password or passkey: they continue to the password or passkey step as usual.
- One account, SSO: they are sent to the identity provider, as before.
- Several accounts under one email: Salesforce emails a verification code. After entering it, the user sees an Environment Switcher with a tile per account, which they can filter, search, rename and star, then they pick one and log in normally. The release note says an email linked to several usernames needs this verification every 30 days.
That code step is deliberate. It means only someone who can read the mailbox gets to see which Salesforce accounts belong to it. It is also exactly why some of your users will get stuck.
Who will get stuck
People who share an email address. Help-desk teams, shared service accounts, and every test user an admin created with their own address. Salesforce is plain about it: "If you use a shared email address or you can't receive messages sent to your email address, continue to log in by using your username." To see how common this is, I ran the queries below against a Developer Edition org of mine: two email addresses were shared between active human users, and all seven internal users had a username that differed from their email. That is a small org built by one person. Yours will have more.
People with accounts in several orgs. Consultants, admins with production and sandbox access, anyone in a multi-org estate. They get the code and the Environment Switcher. That is workable, but only if they can reach the mailbox, and only if someone told them it was coming.
Sandbox users. When a sandbox is created or refreshed, Salesforce appends .invalid to users' email addresses so the sandbox cannot email real people. A user who types their real address at test.salesforce.com will not match a sandbox account whose email still ends in .invalid. Until the address is corrected in that sandbox, they need their username. Check this in one of your own sandboxes before you write the user guidance, because it is the case most likely to generate tickets.
Users who cannot use email login at all. If the Email field is protected by Shield Platform Encryption, or the org has the Prevent login with login.salesforce.com and welcome.salesforce.com setting turned on, email login is not available. Those users continue with the username or with My Domain.
Find the accounts that will struggle
All three queries are read-only. Run them in Developer Console, Workbench or the sf CLI.
Email addresses shared by more than one active human user:
SELECT Email, COUNT(Id) users
FROM User
WHERE IsActive = true
AND UserType IN ('Standard', 'PowerPartner', 'PowerCustomerSuccess', 'CustomerSuccess', 'CspLitePortal')
GROUP BY Email
HAVING COUNT(Id) > 1
The UserType filter leaves out the Automated Process, Guest and integration users, which share addresses by design and never log in through the page.
Placeholder addresses nobody can receive mail at:
SELECT Username, Email, Profile.Name
FROM User
WHERE IsActive = true
AND (Email LIKE '%.invalid' OR Email LIKE '%@example.com')
Usernames that differ from the email, which is everyone who will be told something new. SOQL cannot compare two fields, so export and compare, for example with the sf CLI:
sf data query --target-org prod --json \
--query "SELECT Username, Email FROM User WHERE IsActive = true AND UserType = 'Standard'" \
| jq -r '.result.records[] | select((.Username|ascii_downcase) != (.Email|ascii_downcase)) | [.Username, .Email] | @csv'
For each shared address, decide: give the person a mailbox of their own, or accept that they log in with their username and tell them so. Do not start bulk-editing Email fields without reading up on email change verification first. Changing a user's email sends a verification message, and Salesforce is retiring the old way of exempting domains from it on 1 December 2026.
Fix automation before it fails
Anything that logs in by filling the login page breaks: Selenium and Provar tests, RPA bots, synthetic monitoring, and the occasional scheduled script someone built years ago. Salesforce gives two URL parameters in the release note:
https://login.salesforce.com/?login=1(ortest.salesforce.com/?login=1) goes straight to the username login page, skipping the email prompt.https://login.salesforce.com/?type=twoboxkeeps the old page with the username and password boxes together, undoing the username-first change.
Both are bridges. The sturdier fix is to log automation in through your My Domain login URL, which the email change does not touch, or better still, not through the login page at all. A test that needs a session can get one from a JWT-authorised integration user, which is how the CLI does it. Also expect MFA on test users: Salesforce's note reminds you that MFA challenges can be completed by automation, and the MFA enforcement guide covers where that applies.
API integrations do not need changes for this. They do need changes for something else on the same timeline: the OAuth username-password flow retires on 20 February 2027. Do not confuse the two in a change request.
Steer users to My Domain
The cleanest way to make this a non-event is to stop people using login.salesforce.com at all. Your My Domain login page is unaffected by the email change, can carry your branding and your SSO buttons, and is the URL your security team can reason about. Publish it on the intranet, put it in the welcome email, and make it the bookmark.
If you want to enforce it, the Prevent login with login.salesforce.com and welcome.salesforce.com setting in My Domain blocks the generic pages for your users. Turning it on also turns off email login for your org, which is either what you want or a surprise, so decide on purpose. Test it in a sandbox first: anyone who logs in only through the generic page, and any integration that does, will notice.
What to tell users
Keep it short and send it before your production org gets the change. Something like:
The Salesforce login page now asks for your email address instead of your username. Type your work email and carry on as usual. If you have more than one Salesforce account, you'll get a code by email, then choose the account. If you share a mailbox or can't receive email at your address, click "Log In with Username". Even easier: use our login page at https://yourcompany.my.salesforce.com, which hasn't changed.
Add a screenshot of the new page, and give the help desk the three queries above, so they already know which callers to expect.
Frequently Asked Questions
Q: Is Salesforce removing usernames?
A: No. Usernames still exist, must still be unique, and still work. The "Log In with Username" option stays on the page, ?login=1 opens it directly, and API logins use usernames as before.
Q: Can admins switch email login off?
A: Salesforce documents no setting that keeps login.salesforce.com on the old page. Blocking login through login.salesforce.com and welcome.salesforce.com in My Domain settings does disable email login for your users, as a side effect of sending them to My Domain.
Q: Does this weaken security?
A: It does not change how anyone authenticates: passwords, MFA, passkeys and SSO still apply. Where one email maps to several accounts, Salesforce asks for an emailed code before showing them. It does make the email address more important, so keep it accurate and keep email change verification on.
Q: Does it affect SSO users?
A: SSO still works. A user who types an email that maps to an SSO-enabled account is sent to the identity provider. Users who start from the identity provider never see the Salesforce login page at all.
Q: Why did my Selenium tests start failing?
A: Because the first box now expects an email address, and before that, the password box moved to a second screen. Use ?login=1 or ?type=twobox as a bridge, and move tests to My Domain or token-based login for good.
Key Takeaways
- The first box changed, not authentication. Email is the default identifier on Salesforce's standard login pages; nothing else about logging in changed.
- My Domain, Experience Cloud and API logins are out of scope. Pointing users at My Domain makes the change invisible to them.
- Shared and unreachable email addresses are the real risk. Find them with a query this week, not a ticket next month.
- Automation needs one URL change.
?login=1buys time; My Domain or token-based login fixes it properly.
What's Next?
Recommended Reading:
- Salesforce Is Retiring the Email Change Verification Exemption
- Salesforce MFA Enforcement in 2026: What Admins Must Verify and Do
- Salesforce Retires the OAuth Username-Password Flow on 20 February 2027
Action Items:
- Run the three queries in production and in your most-used sandbox.
- Change every automated login to
?login=1or, better, your My Domain URL. - Send users the two-sentence notice and the My Domain link.
Seen a case this misses, or a user group that got stuck in a way I have not described? Leave a comment below.
Responses
Checking your session.
Loading responses.