Domain login policy

Once your organization holds a verified domain, you can give it a login policy. The policy governs every account that owns a verified email address on that domain, platform-wide — on every application, not just your own. Because you proved DNS control of the domain, Sudomimus treats you as authoritative over how that email namespace signs in.

The three policies

Policy	Effect on accounts with an email on this domain
ALLOW_ALL	No restriction. This is the default for every verified domain (and what an absent policy means).
BLOCK_ALL	Every login is refused, platform-wide, regardless of method.
SSO_ONLY	Every login must go through a specific federation connector — your IdP. Every other method (passkey, email OTP, consumer OAuth, Steam, native keys) is refused.

SSO_ONLY is covered end-to-end in Sign in with your IdP; the rest of this page focuses on how all three behave.

How enforcement works

The policy is an upper gate evaluated at the moment a login is realized, with one important property:

Account-taint, not email-of-the-moment

If any of an account’s verified emails sits on a VERIFIED domain with a BLOCK_ALL or SSO_ONLY policy, the whole account is governed by that policy — on every login, with every method, to every application. It does not matter which email the user typed this time, or whether they logged in with a passkey that has no email at all. The taint follows the account, not the request.

This mirrors how account-level disable works. The gate runs after the account-active check and before the identity (Layer 2) check, so it is genuinely a platform-wide policy, not a per-application rule.

A login the policy refuses is rejected with the wire reason EmailDomainBlocked (for BLOCK_ALL) or EmailDomainRequiresSso (for SSO_ONLY).

What a policy does and does not do

• It governs authentication, not authorization. A login that satisfies SSO_ONLY still has to pass the application’s Layer 2 realize rules and Layer 3 return rules. Authentication ≠ authorization — forcing SSO does not grant access, it only constrains how a user proves who they are.
• It does not revoke already-issued tokens. Like account disable, the policy is checked at login (realize) time only. Access and refresh tokens that were already minted keep working until they expire by TTL (access 3 hours, refresh 30 days). Setting BLOCK_ALL locks a user out of new logins immediately; it does not end their current sessions.
• It does not touch the account’s email ownership. Reverting to ALLOW_ALL restores normal access — nothing about the account was deleted.

Setting a policy

The login policy is set from the With portal, on the verified domain’s detail page (a Login policy tab). It can only be changed by the sole owner of the organization that owns the domain — if your organization has more than one owner, no single owner can unilaterally change how everyone on the domain signs in.

You can lock yourself out

The policy applies to every application, including the With portal itself, and there is no exemption for your own login. If you set BLOCK_ALL (or a misconfigured SSO_ONLY) on the domain of your own login email, you will lock yourself out of Sudomimus and will need staff to un-block you. The portal warns you before you do this — read the warning.

Related

Adopt a domain A login policy requires a verified domain — start here.

Sign in with your IdP The SSO_ONLY policy in full: forcing a domain's users through your connector.