/
Contact usSee pricingStart building

    About B2B Saas Authentication

    Introduction
    Stytch B2B Basics
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Next.js
      Routing
      Authentication
      Sessions
    Migrations
      Overview
      Reconciling data models
      Migrating user data
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for members
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    Single Sign On
    • Resources

      • Overview
        External SSO Connections
    • Integration Guides

      • Start here
        Backend integration guide
        Headless integration guide
        Pre-built UI integration guide
    OAuth
    • Resources

      • Overview
        Authentication flows
        Identity providers
        Google One Tap
        Provider setup
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Connected AppsBeta
      Setting up Connected Apps
      About Remote MCP Servers
    • Resources

      • Integrate with AI agents
        Integrate with a remote MCP server
    Sessions
    • Resources

      • Overview
        JWTs vs Session Tokens
        How to use Stytch JWTs
        Custom Claims
    • Integration Guides

      • Start here
        Backend integration
        Frontend integration
    Email OTP
      Overview
    Magic Links
    • Resources

      • Overview
        Email Security Scanner Protections
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Multi-Factor Authentication
    • Resources

      • Overview
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Passwords
      Overview
      Strength policies
    UI components
      Overview
      Implement the Discovery flow
      Implement the Organization flow
    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0

    Authorization & Provisioning

    RBAC
    • Resources

      • Overview
        Stytch Resources & Roles
        Role assignment
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
    SCIM
    • Resources

      • Overview
        Supported actions
    • Integration Guides

      • Using Okta
        Using Microsoft Entra
    Organizations
      Managing org settings
      JIT Provisioning

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

B2B Saas Authentication

/

Guides

/

Authentication

/

Magic Links

/

Resources

/

Email Security Scanner Protections

Protected Magic Links

Stytch's email magic links product has built-in protections that ensure seamless delivery of magic links in corporate environments without compromising on security.

One-Time Use Restrictions on EMLs

Each magic link that is sent to the user is one-time-use. Once the user clicks on the magic link and logs in, the embedded token that uniquely identifies the authentication request is “consumed” and cannot be used for subsequent logins. This is critical for security as it significantly reduces the chances of unauthorized access. Once the user has completed the authentication flow the token cannot be stolen or replayed by an attacker to gain access.

However, in corporate environments, where email security scanners are very prevalent, this security measure can sometimes make Email Magic Links unusable.

Email Security Scanners

Email security scanners are tools that scan incoming emails for malicious content, such as suspicious links or attachments, in an effort to protect the user from phishing attacks or malware. Most security scanners will inspect and click on any links present in emails, in order to identify suspicious redirects, attempts to execute malicious scripts or download malware, or signs of a phishing attempt.

When the link in question is actually an email magic link, the scanner will end up consuming the token before the email actually makes its way into the user’s inbox, preventing them from being able to use the link to login.

Stytch's Built-in Solution

In order to not compromise on the security of our EML product, while accounting for the prevalence of email security scanners, particularly in corporate inboxes, Stytch leverages our device intelligence product to handle “clicks” differently depending on if it is a real human user, or an email security scanner.

When we identify that the magic link has been clicked by an email security scanner, we do not treat the click as an authentication attempt – meaning the token is not consumed, and a session is not granted. The security scanner is able to inspect the link and identify that it is not malicious, without interfering with the one-time-use restriction. Once the scan is complete and the email is passed through to the user’s inbox, they are able to click on the link and successfully log in.

This protection comes out of the box for all Stytch customers, but if you are interested in learning more about other use cases of Stytch’s device intelligence product (such as bot-protection on your login page, or identifying and blocking fraudulent real users) you can contact sales here.

One-Time Use Restrictions on EMLs

Email Security Scanners

Stytch's Built-in Solution