--- title: Domain login policy description: For users whose email is on a verified domain you own, decide platform-wide whether logins are allowed, blocked, or forced through your identity provider. editUrl: true head: [] template: doc sidebar: order: 3 hidden: false attrs: {} pagefind: true draft: false --- import { CardGrid, LinkCard } from "@astrojs/starlight/components"; Once your organization holds a [verified domain](/en-us/domains-federation/adopt-a-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](/en-us/domains-federation/federation-connectors/) — 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](/en-us/domains-federation/sign-in-with-your-idp/#forced-sso-domain-managed); 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: :::note[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](/en-us/application-rules/realize-rules/) and [Layer 3 return rules](/en-us/application-rules/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. :::caution[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