How to Test Salesforce Email Login Verification Codes in 2026: QA Acceptance Steps

Salesforce says its default email-login experience begins rolling out to sandboxes in August 2026 and production organizations in October 2026, with rollout occurring by organization—not all at once (Salesforce login-change notes). Test the email entry, code delivery, code acceptance, account or organization choice, and final access as separate checkpoints. If one email is linked to multiple accounts, verify the code step and the account selection. A message arriving in the inbox does not prove that login succeeded.

This guide is for QA engineers checking Salesforce sandbox or test-organization login regressions, developers maintaining UI automation, and admins who need to verify which account and organization a shared email address reaches.

Last updated November 2, 2026. Rollout timing and login-flow details were checked against Salesforce Help. Your organization’s live page is evidence of that organization’s current behavior, not proof that every Salesforce organization has the same experience.

Before testing: identify the login surface

Start by writing down exactly where your test begins. A Salesforce test organization may use the general login page, a My Domain URL, an Experience Cloud site, a mobile app, or an organization’s single sign-on route. Those surfaces are not interchangeable. A result from one does not establish the behavior of the others.

Salesforce documents an email-login default experience and a phased rollout. The Help material also describes how users can log in with an email address and how access may differ when an email is associated with multiple accounts (Salesforce email-login guidance, multiple-account login guidance). Use those instructions to set your expected behavior, then verify the live route for your target organization.

The Salesforce login URL guidance describes the available login-address choices, including how to select the appropriate entry point for an organization (Salesforce login URL guidance). Check that guidance before changing a test URL or adding a query parameter. Do not invent a parameter, copy one from an unrelated environment, or treat a URL adjustment as proof that the account’s authentication policy changed.

Scope note: Treat the rollout dates as the start of a phased change, not as confirmation that your particular organization has switched. Record what the target organization shows on the day you test.

What should you check before testing Salesforce email login in a test organization?

Confirm that you have authorization to use the organization and account. Identify the organization by its expected name or other approved identifier, and note whether the account is a sandbox/test account or another authorized test identity. Make sure you can access the mailbox assigned to that account. If your team uses a shared mailbox, confirm that the people or automation running the test can retrieve the message without exposing unrelated mail.

Also record the entry URL and the intended route: general login, My Domain, Experience Cloud, SSO, or mobile. Keep those distinctions in the test case itself. “Salesforce login works” is too broad to be a useful acceptance statement. “This authorized test account reaches this named test organization through this login surface” is testable.

For test data, use an address and identity that do not expose a real person’s information. Separate the account’s display data from production customer data, and restrict access to captured screenshots and message content. For more on separating test identities from personal data, use this guide to data boundaries for test environments.

During the first run: capture the live email-login flow

Run the flow manually before relying on a UI script. Use the account and entry point recorded during setup. Capture the page after entering the email address, the authentication options shown, and the next destination. If the page offers a different path from your expectation, stop and record the difference rather than forcing the test through a guessed selector.

Do not infer a universal rollout state from one observation. Salesforce says the default experience is rolling out by organization, and the official change notes set out the planned rollout windows for sandboxes and production organizations. Your live observation answers a narrower question: what happened for this account, route, and organization during this run.

Use the same evidence categories in manual and automated runs. That makes it easier to identify whether a regression occurred at email entry, message delivery, code validation, account selection, or after authentication.

At code receipt: prove each state separately

A verification-code test has distinct outcomes. The message may be absent, delayed, delivered to an unexpected address, or present but rejected by the page. The login page may also accept the code and then present an account-selection step. Keep the mailbox result and browser result separate in your logs.

How do you verify the code step when an email is tied to multiple accounts?

Salesforce’s multiple-account guidance describes a flow in which a user may need to confirm identity with a code sent by email before choosing an account. Check whether that condition applies to the account you are testing; do not assume that every email login requires the same code step. Record the email address used, whether the page requested a code, and the options shown after the code was submitted.

Then verify the selected account or organization against the test case. A code can demonstrate that the user completed that checkpoint. It does not establish that the right organization was selected, that the user has the intended permissions, or that the final page belongs to the target organization.

To make the receipt check useful, match the message to the run. Confirm the expected destination address and inspect enough of the message to identify it as the current login email. Avoid logging the full code in a shared test report. If your automation needs to read an inbox, give it access only to a controlled test mailbox and avoid storing message contents longer than the test requires.

A message-delivery check and a page-acceptance check answer different questions. If you need a separate reference for those boundaries, see how to distinguish a received test email from a completed login flow. This Salesforce test should still use the Salesforce page’s response as evidence of code acceptance.

Does receiving the code mean the login passed?

No. Mark the mail-receipt checkpoint as passed only when the expected message reaches the authorized inbox. Mark code acceptance separately, based on the page’s response after submission. Then verify account selection and the final organization state.

If the message arrives but the page rejects the code, investigate the page result and the current test session; do not label the whole login successful. If the page accepts the code but the wrong account or organization is selected, record an account-selection failure. If the test stops on a verification screen, the end-to-end login is incomplete even if the mailbox check passed.

For a controlled QA run, use an outcome vocabulary that preserves these distinctions:

• Mail not received: the expected message was not found in the authorized test inbox.
• Mail received: the expected message arrived, but code submission has not yet been verified.
• Code rejected: the page did not accept the submitted code.
• Code accepted, selection pending: authentication advanced, but account or organization choice is incomplete.
• Wrong account or organization: the flow advanced to an unintended identity or destination.
• Login verified: the final state matches the expected test organization and account.

These labels are test-report categories, not Salesforce status names. Keep them separate from any wording shown by the product.

After verification: confirm the account and organization

When the page presents choices, compare each option with the intended test identity. The display name alone may be ambiguous if an address is associated with more than one account. Use the identifiers your team has approved for distinguishing test organizations, and record the selected option without exposing unnecessary personal or organizational data.

After selection, verify the final state. Check the organization identity using the page or in-product indicator your test team considers authoritative. Confirm that the expected landing page or protected test action is available. Do not use the arrival of the code, the appearance of an account choice, or a generic page transition as a substitute for checking access to the target organization.

How can you confirm the login really completed after receiving a code?

Use an explicit post-login assertion. It should check that the session reached the intended organization and that the page is no longer waiting for verification or account selection. If the test requires a particular role or permission, assert that separately; authentication and authorization are related but distinct results.

When the test fails, preserve the last confirmed checkpoint. For example, “code received; page rejected submission” is more actionable than “Salesforce login failed.” “Code accepted; wrong organization selected” points to a different investigation than “the expected message never arrived.” This detail helps QA and developers avoid changing the wrong part of the test or application flow.

For regression: preserve a separate username path

Email login and username login are separate paths to maintain when both matter to your product or operations. A UI test that starts with an email address cannot stand in for a regression test that must prove username login still works. Keep the account type, entry route, and expected final organization explicit in each test case.

How should automation continue to test username login?

First decide whether the test is meant to cover the email-login experience or a traditional username-login route. For the latter, consult Salesforce’s current login-address guidance for the supported entry point and any documented URL behavior. Apply only the route or parameter documented for that context. Do not hard-code an assumed button position or a single page label as a permanent selector contract.

Then maintain separate automation cases or clearly separated branches. The email path should assert the email-entry behavior and any applicable code and account-selection steps. The username path should assert that the intended login route is reached and that the authorized test account arrives in the target organization. If the route changes, update the expected behavior from official documentation and a fresh observation—not from a selector workaround alone.

A useful decision rule is:

• If the requirement is to validate the default email-login experience for this organization, use the email path and verify each applicable checkpoint through final access.
• If the requirement is specifically to preserve username login, use the Salesforce-documented route for that purpose and test it as its own path.
• If the route is My Domain, Experience Cloud, mobile, or SSO, follow the relevant documented sign-in surface instead of assuming the general login page applies.
• If the account is linked to multiple Salesforce accounts, include the code and account-choice checks when the observed and documented flow calls for them.
• If the test only proves that a message arrived, report a mail-receipt result—not a completed login.

Salesforce also publishes guidance for mobile login, which has its own sign-in context (Salesforce mobile login guidance). Keep mobile coverage separate from browser UI regression unless your test explicitly validates both.

At sign-off: record evidence and scope

Store the entry URL, account type, target organization, authentication options shown, mailbox outcome, code-submission result, account choice, and final page state. Mask credentials and verification codes in artifacts. Keep only the evidence your team needs to reproduce or review the result.

Use a short pass/fail record that reflects the tested scope:

• Pass: the authorized account used the specified login surface, completed every applicable checkpoint, and reached the intended organization.
• Needs investigation: the route or page differed from the documented expectation, or the outcome could not be tied to a specific checkpoint.
• Fail: a required checkpoint failed, the wrong account or organization was reached, or the test never established final access.

The conclusion should name the organization and route you actually tested. A pass in one sandbox does not establish that production, another sandbox, My Domain, Experience Cloud, mobile, or SSO uses the same flow. Likewise, one observation after a phased rollout does not prove that every organization has received the change.

For the email-receipt portion, a controlled test inbox can keep verification messages away from your primary mailbox and help isolate QA traffic. MsgMask offers a no-registration, immediate-use temporary inbox, but check its live receiving behavior against your specific test before making it part of a regression dependency. Do not assume a code will arrive or that every Salesforce route will accept the same email flow. For a one-off authorized test, start from the MsgMask inbox; for accounts that require long-term recovery, replies, or dependable access, use a managed test mailbox instead.