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.

Different SSO authorities cannot be combined

Several domains may require the same connector; that remains one satisfiable SSO requirement. If verified emails on the account belong to domains that require different connectors, Sudomimus cannot choose A without bypassing B, or choose B without bypassing A. The account cannot start a login or receive fresh tokens until an administrator aligns a domain policy, a conflicting verified email is removed, or the identities are separated into different accounts. The login UI explains the conflict and does not offer a connector picker.

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), EmailDomainRequiresSso (for one unsatisfied SSO_ONLY connector), or SsoAuthorityConflict (for distinct connector pins).

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 access tokens in place. An access token that was already minted keeps working until it expires by TTL (3 hours by default). Refresh-token reissuance is different: Session API /refresh and the OIDC refresh-token grant re-check the current domain login policy. BLOCK_ALL, an SSO_ONLY connector change that the session’s original login no longer satisfies, or distinct SSO_ONLY pins deny the next refresh instead of allowing the session to keep rotating for the full refresh TTL.
• 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 domainA login policy requires a verified domain — start here.

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