Security Overview

Protect accounts with 2FA, SSO, app passwords, and recovery options.

Account security (users)

Open Settings → Security in the inbox or /settings.

• Change password — update your login password.
• Two-factor authentication (2FA) — TOTP app (Google Authenticator, Microsoft Authenticator, Authy, etc.), backup codes, and unusual-sign-in email/SMS OTP. Setup guide →
• Recovery email and phone — alternate contacts for account recovery. Verify the phone in Settings → Security before it can receive SMS OTP.
• App passwords — required for IMAP/SMTP in Outlook and mobile clients. App passwords guide →

Login flows

• /login — email and password; optional Remember me (stores email only, never password).
• /first-login-password — forced password change on first login.
• /forgot-password and /recover-account — email recovery with optional 2FA verification.

Organization authentication policy (admins)

In Admin → General → Authentication policy, choose whether 2FA is optional or required, who it applies to, and which channels (authenticator, email OTP, SMS OTP) the org will allow. Users still enroll in Settings → Security. Same split as Google Workspace: users manage methods; IT sets policy. Details: Authentication policy.

Authenticator login, backup codes, required 2FA after grace, unusual-sign-in email OTP, SMS OTP (when the platform gateway key is set), trusted devices, and step-up for password / recovery / mailbox export are live. SSO still uses the company IdP for MFA. Admin guide: Authentication policy.

Organization SSO (admins)

In Admin → General → SSO, configure your identity provider, enforce SSO for all users, enable auto-provisioning, and map IdP attributes to MoovMail profiles. Exact callback URLs for your tenant are shown only in Admin (copy them into your IdP). Public docs intentionally mask full hostnames.

Corporate SSO — MoovMail mail + other org apps

This is the primary enterprise scenario: the company uses MoovMail for email, and employees also use Slack, Salesforce, HR tools, and other apps. Those apps already share one company identity provider (IdP) such as Okta, Microsoft Entra ID, Google Workspace (as IdP), Auth0, WorkOS, Keycloak, or ADFS.

MoovMail SSO means sign into MoovMail using that same company IdP. MoovMail does not become the login system for the other apps. MoovMail is registered as one more application on the customer IdP — the same pattern used by most SaaS products.

End-user flow

1. User opens MoovMail /login and enters work email (user@company.com).
2. MoovMail discovers SSO for the verified domain and shows Continue with {provider label}.
3. Browser redirects to the company IdP (same login used for other org apps, including MFA if the IdP requires it).
4. IdP returns to MoovMail; MoovMail links or provisions the user and issues the normal MoovMail session (JWT).
5. User lands in the inbox.

What each side configures

• Customer IdP admin — create an OIDC or SAML application for MoovMail; paste MoovMail redirect / ACS / metadata values from Admin → SSO.
• MoovMail org admin — Admin → General → SSO: choose OIDC or SAML, paste IdP credentials/endpoints, enable SSO, optionally auto-provision and enforce SSO.
• MoovMail platform — public app URL must be correct so callbacks resolve (your Admin panel shows the live values).

Callback paths (host masked in public docs)

Full hostnames are shown only inside Admin → General → SSO. Below, the host is masked (first 10 characters + xxxxx...). Path shapes stay visible so admins know what to register:

• OIDC redirect URI — https://moxxxxx... + path /api/auth/sso/oidc/callback
• SAML ACS — https://moxxxxx... + path /api/auth/sso/saml/acs
• SAML SP metadata — https://moxxxxx... + path /api/auth/sso/saml/metadata?organizationId=…

Recommendations

• Test with one pilot user before turning on Enforce SSO (enforce blocks password login for the org).
• Enable IdP MFA / Conditional Access on the customer side; MoovMail treats successful SSO as the primary login factor.
• Use Auto-provision only when every IdP user on the domain should receive a MoovMail mailbox and seat on first login.
• Prefer a broker (WorkOS / Auth0) via OIDC when the company has many IdPs — one MoovMail OIDC config covers Okta, Azure, Google, and others behind the broker.
• Keep attribute mapping aligned so email (and optionally first/last name) match MoovMail profiles.
• Remember me on /login stores email only, never passwords.

Google Workspace and Microsoft 365 — clarification

Teams sometimes ask about “Gmail” or “Office 365” SSO separately. Those names mix two different products:

• As mail hosts — if the company keeps mailboxes on Google Workspace or Microsoft 365 Exchange, that is a mail hosting / migration decision, not MoovMail SSO. MoovMail SSO does not turn MoovMail into Gmail or Exchange, and it does not replace those mailbox products.
• As identity providers — if the company uses Google Workspace or Microsoft Entra ID only to authenticate users while email stays on MoovMail, that is still the corporate scenario above: configure MoovMail Admin → SSO with SAML (typical for Google Workspace) or OIDC / SAML(typical for Microsoft Entra). No separate “Gmail product” or “Office 365 product” integration is required for login.

In short: do not treat Google/Microsoft mail products as MoovMail feature work for SSO. Treat them as optional IdPs under the same OIDC/SAML path when MoovMail is the mailbox.

OIDC broker pattern (WorkOS / Auth0)

Recommended when one customer has multiple upstream directories or wants a single integration surface: connect MoovMail once via OIDC to WorkOS or Auth0; the broker federates Okta, Azure AD, Google Workspace, and others. MoovMail still receives one OIDC callback and issues its own session.

SSO roadmap (planned)

Available today: per-org OIDC and SAML, domain discovery, enforce SSO, auto-provision, Admin configuration UI.

Planned next (not all shipped yet):

• Plan-tier gate — allow SSO only on plans that include the SSO entitlement.
• SCIM — push/pull user lifecycle from the IdP directory.
• SAML SLO — single logout across MoovMail and the IdP.
• IdP metadata auto-import — fetch and apply metadata from a URL (field exists for reference today).
• OIDC PKCE — stronger public-client / browser flows.
• Multi-IdP per org — more than one IdP configuration on a single organization.
• Mobile SSO — same discover/login flow in the mobile apps.

UEM / device platforms (for example Scalefusion)

Products such as Scalefusion combine unified endpoint management (UEM), SSO/access, and device compliance. MoovMail can participate in that ecosystem without becoming a UEM itself:

• SSO app integration — register MoovMail as an OIDC/SAML app on the customer IdP (or on a UEM-bundled IdP such as OneIdP). Employees get one sign-in; MoovMail uses the existing Admin → SSO setup.
• Conditional / compliant-device access — typically enforced by the IdP or UEM (device posture, managed device required) before the browser reaches MoovMail. MoovMail receives a successful assertion only after those checks pass.
• Business fit — MoovMail benefits as the secure mail destination; the UEM vendor benefits as the device/access control plane; the end customer gets managed devices plus MoovMail behind the same identity.

A deeper partnership (APIs for compliance signals inside MoovMail, mobile app management catalogs, or exclusive marketplace listing) would be a separate commercial and engineering project. Baseline SSO compatibility does not require MoovMail code changes beyond the existing OIDC/SAML support.

Admin security actions

• Reset user password or 2FA from Admin → User Management.
• Review login history (IP, device, browser).
• Admin pages use a 1-hour idle timeout; inbox, calendar, and other apps stay signed in until logout or a confirmed server/app version update (temporary network blips do not sign users out).

Email security

• SPF, DKIM, and DMARC protect your domain reputation — see DNS guides.
• Spam folder and server-side scanning reduce unwanted mail.
• Block sender from any open message.

2FA nudge

MoovMail may prompt users who have not enabled 2FA to set it up for better account protection.

Public security information

High-level practices are described on /security (marketing/legal page).