Skip to main content

How to set up SSO/SAML in lemlist

Updated today

By the end of this tutorial, you’ll know how to configure SSO for your team in lemlist, verify and manage your company domains, choose whether to enforce SSO, and connect Microsoft Entra ID, Okta, or Google as your organization login provider.

Note: This feature is available only on the Enterprise plan.

SSO helps your team sign in with your company identity provider instead of managing passwords directly in lemlist. It also gives admins more control over domain-based access, login enforcement, and cross-app authentication across the Lempire ecosystem.

Why this matters

SSO makes access more secure and easier to manage because your users authenticate through your organization’s existing identity provider. It also reduces password-related issues, lets you control which domains can access your team, and supports login across lemlist, lemwarm, and lemcal.

Before you begin

  • You should already know how to access your team settings in lemlist.

  • You need to be a team admin in lemlist to configure SSO.

  • You need admin rights in your identity provider if you’re using Microsoft Entra ID or Okta.

  • You should already know which company email domains you want to secure with SSO.

Important: If you are not a team admin, the SSO option is disabled.

Supported identity providers

  • Microsoft Entra ID — uses SAML 2.0. You provide the App Federation Metadata URL, and lemlist extracts the certificate and login endpoint automatically.

  • Okta — uses SAML 2.0. You provide the Okta metadata URL and complete the same SAML-based flow.

  • Google — uses Google OAuth, not SAML. Setup is simpler and does not require a metadata URL.

Phase 1: Start the SSO setup wizard

  1. Open lemlist and go to your team settings.

    This is where team admins can manage organization-level login controls.

  2. Find Log in with your organization (SSO) and open the setup flow.

    This launches the guided wizard used to configure your provider, domains, and enforcement settings.

  3. Choose your provider: Microsoft Entra, Okta, or Google.

    This choice determines whether you complete a SAML setup or a Google OAuth setup.

Phase 2: Add and verify your domain(s)

Your domains determine which users can authenticate through your organization login. lemlist supports multiple domains per organization.

  1. Add the email domain or domains that should use SSO, such as acme.com.

    This tells lemlist which users belong to your organization for SSO purposes.

  2. Verify ownership of each domain before activating it.

    This prevents another team from claiming a domain they do not own.

Choose a verification method

You can verify each domain in one of two ways:

  • Email verification — Enter an email address on that domain, such as [email protected], then click the verification link sent to that address. The link expires in 15 minutes.

  • DNS TXT verification — Add a TXT record named _lemlist-challenge.yourdomain.com and set the value to the token shown during setup. After the record propagates, click Verify.

Good to know: A domain must be verified before it becomes active for SSO.

Manage verified domains

After verification, you can:

  • View your verified domains

  • Add more domains

  • Remove domains

  • Configure SAML bypass per domain

Use SAML bypass when needed

SAML bypass is a per-domain toggle that allows password login alongside SSO for that specific domain. This is useful for fallback admin accounts or service accounts that may need non-SSO access.

Phase 3: Review team impact before activation

Before SSO is activated, lemlist checks how your current team members are affected.

  1. Review users whose email addresses match one of your SSO domains.

    These users will use SSO going forward once SSO is active.

  2. Review users whose email addresses do not match your SSO domains.

    During setup, lemlist can show these users so you can remove them from the team before activation.

Important: If a user’s email domain does not match the configured SSO domains, they may be removed from the team during setup.

Phase 4: Choose how strictly SSO is enforced

You can decide whether SSO is optional or required for matching users.

If Force SSO is enabled

  • Users with a matching SSO domain must log in with SSO

  • Password and OAuth login are blocked for those users

  • Domains with SAML bypass enabled can still use password login

  • Resume login for an existing session still works

If Force SSO is not enabled

  • Users can sign in with SSO or with traditional methods such as password, Google, or Microsoft login

Best practice: Leave Force SSO off while testing. Once your provider, domains, and assignments are confirmed, you can enforce SSO for matching users.

Phase 5: Complete provider-specific setup

Set up SSO with Microsoft Entra ID

  1. Open Microsoft Entra admin center and go to Enterprise applications > All applications.

  2. Create a new application for lemlist.

    This gives you a dedicated enterprise app to manage SSO access.

  3. Select SAML as the sign-on method.

  4. In the SAML configuration, copy your team values from lemlist and paste them into Microsoft Entra.

    • Paste the lemlist Identifier (Entity ID) into the Entra Identifier (Entity ID) field

    • Paste the lemlist Reply URL into the Entra Reply URL (Assertion Consumer Service URL) field

  5. Copy the App Federation Metadata URL from Microsoft Entra and paste it into the matching field in lemlist.

    lemlist uses this URL to automatically extract the certificate and login endpoint.

  6. Assign the right users or groups to the application.

    This controls who can actually access lemlist through Entra.

Set up SSO with Okta

  1. Sign in to your Okta admin dashboard and go to Applications > Applications.

  2. Click Create App Integration and choose SAML 2.0.

  3. Create the lemlist integration and continue through the setup screens.

  4. Copy your team values from lemlist into Okta.

    • Paste the lemlist Single sign-on URL into Okta’s Single sign-on URL field

    • Paste the lemlist Identifier (Entity ID) into Okta’s Audience URI (SP Entity ID) field

  5. Add these attribute statements in Okta:

    • firstName → user.firstName

    • lastName → user.lastName

    • email → user.email

  6. Finish the Okta setup flow, then copy the App Federation Metadata URL from Okta into lemlist.

  7. Assign the relevant users or groups to the Okta application.

Important: If a user is not assigned to the Okta or Microsoft Entra application, they may not be able to access lemlist even if SSO is configured correctly.

Set up organization login with Google

  1. Select Google as your provider in the setup wizard.

  2. Complete the Google authentication setup in lemlist.

    Unlike Entra and Okta, Google uses OAuth rather than SAML, so no metadata URL is required.

  3. Finish the dedicated Google setup step and save your configuration.

Phase 6: Test the login flow

Testing helps you confirm that the correct users are redirected to the right provider before rolling SSO out fully.

  1. Save your SSO configuration in lemlist.

  2. Assign a test user in your identity provider.

  3. Have the user go to the SSO login page at /sso.

  4. Enter the work email address for a verified domain.

  5. Confirm the user is redirected to Microsoft Entra, Okta, or Google.

  6. Complete authentication and verify that the user is logged into lemlist automatically.

How invited users sign in

  • If SSO is active on the team, invited users receive an email explaining that they must log in via SSO.

  • When they click the invite link, they are taken directly to the SSO login flow.

  • After authenticating with their organization credentials, they are logged into lemlist.

Practical example

Here’s a common rollout pattern for an Enterprise team:

  1. Add acme.com and acme.co.uk as SSO domains.

  2. Verify one domain by email and the other through a DNS TXT record.

  3. Keep Force SSO off during testing so users can still sign in with their previous method if needed.

  4. Enable SAML bypass on one domain used by an admin fallback account.

  5. Assign a pilot group in Okta or Microsoft Entra and test the flow through /sso.

  6. Once successful, turn on Force SSO for full enforcement.

This approach reduces lockout risk while still moving the team toward centralized login management.

Edge cases and important behaviors

Team members and activation

  • If a user is already on the team and their email domain matches the SSO domain, they lose their previous login method and must use SSO. They are not disconnected from their current session, and no email is sent to inform them of the change.

  • If a user is not on the team but their email domain matches the SSO domain, nothing happens. SSO enforcement applies only to current team members.

  • If a user’s email domain does not match the SSO domain, they can be removed from the team during setup, but their login method for other teams is unchanged.

  • If some users already had a lemlist account that matches the SSO domain, their accounts are merged so they can use SSO to log in.

Invitations and joining teams

  • If a team with SSO invites a user whose email does not match the SSO domain, the invite is blocked.

  • If a user on a team without SSO is invited to a team with SSO, they lose other login methods and must use SSO going forward. They are not disconnected, and no email is sent to inform them of the change.

  • If a new user logs in via SSO for the first time, they are automatically added to the SSO team. No separate team is created, and no email verification is required.

  • Users created with SSO can join other teams, unless Force SSO is enabled and the target teams do not also use SSO with the same verified domain.

Passwords, magic links, and login email changes

  • If an SSO user tries to reset their password, the reset is blocked with this error: "Your account is using Organization login (SSO), please contact your admin to reset your password."

  • If an SSO user clicks Get magic link, they see the same error. Magic links are disabled for SSO accounts.

  • If a user tries to change their login email to one that does not match the SSO domain, the login email field is disabled in settings while SSO is active on the team.

Multi-team behavior

  • If a user belongs to one SSO team and one non-SSO team, they must use SSO to log in, and that login gives them access to both teams.

  • If a user is removed from the SSO team in the identity provider but is still on a non-SSO team, they can become blocked at login and may need support to regain access.

  • If a user leaves a team with SSO enabled, they lose SSO login but are not disconnected immediately. They receive an email with a link to create a password.

IT admin and security notes

  • If an IT admin blocks a user from accessing lemlist through identity provider groups, the user cannot log in with SSO or join the enterprise team. They can still create a separate account with another login method and open a new team.

  • Multiple teams can configure SSO with the same domain. There is no cross-team uniqueness check. At login time, the system finds all matching providers across the user’s teams.

  • Domain ownership is validated before SSO can be activated, using email or DNS TXT verification.

  • Some SSO and password reset errors may reveal that a company uses lemlist. This is an accepted risk at this time.

Troubleshooting and pitfalls

Issue: A user cannot access lemlist through SSO

Root cause: The user may not be assigned to the app in Okta or Microsoft Entra, or their email domain may not match a verified domain.

Fix:

  • Confirm the user is assigned to the application in your identity provider

  • Check that their login email matches one of the verified SSO domains

  • Verify the correct metadata URL was pasted into lemlist

Issue: Domain verification fails

Root cause: The email link may have expired, or the DNS TXT record may not have propagated yet.

Fix:

  • Request a new email verification link if the previous one expired after 15 minutes

  • Double-check the TXT record name and token value

  • Wait for DNS propagation, then click Verify again

Issue: Users are locked out after enabling Force SSO

Root cause: SSO was enforced before testing or before configuring a fallback access path.

Fix:

  • Keep Force SSO off until testing is complete

  • Use SAML bypass on a trusted admin domain if fallback password access is required

  • Confirm provider assignments before rolling SSO out team-wide

Issue: A user cannot use password reset or magic links

Root cause: Their account is now managed through organization login.

Fix:

  • Have the user sign in through /sso with their work email

  • Ask the team admin to review the SSO configuration if access still fails

Issue: A team member’s email does not match any SSO domain

Root cause: Their login email is outside the verified domains used by the organization.

Fix:

  • Review the user during the setup wizard

  • Remove them from the team if needed

  • If you need them to stay, verify whether an additional domain should be added to the SSO configuration

FAQ

What happens if I downgrade from Enterprise?

Your SSO configuration remains saved but becomes inactive. Users will need to log in with password or OAuth until the team is back on Enterprise.

Can I have both SAML and Google SSO on the same team?

No. Each team can have only one SSO provider configured at a time. You choose Microsoft Entra, Okta, or Google during setup.

Can I switch providers after setup?

Yes. You can reconfigure SSO by going through the setup wizard again and selecting a different provider.

Is there a way to test SSO before enforcing it?

Yes. After setup, leave Force SSO off so users can log in with SSO or traditional methods while you test.

Related Articles
Connect your email provider to lemlist
Understand lemlist plans and features
Access and manage purchased email accounts in lemlist
Use SSO in lemlist (Google/Microsoft) and switch back to password login
Set Up Domain Redirections in lemlist
Did this answer your question?