Manage domain users
Each mailbox belongs to a domain user with their own sign-in, separate from your panel account. Domain users explains the model.
You never handle a user's credentials. You control two things:
- the policy: which authentication methods you accept
- the oversight and emergency controls, which this page covers
All of it is on the user's page under Domain Accounts, mostly on the Authentication tab. Sessions, Connected Apps, Auth Log, and Access Log have their own tabs.
The authentication policy
Two settings decide which credentials you accept:
| Setting | Controls |
|---|---|
| Traditional password authentication | The mail and file protocols. |
| Modern (browser-based) authentication | Webmail, the sign-in portal, and every application that uses the identity provider. |
Both are on the Authentication tab and default to Use default policy, the value for the whole domain.
- Authentication policy: what each setting accepts, which paths stay open, and which position to choose.
- Policy tiering: how the domain default and the per-user override combine.
What you can see and revoke
The Authentication tab shows the user's current state:
- when the password was last set, and whether it is System generated or Set by user
- whether two-factor authentication is Set
- the user's passkeys and app passwords: descriptions and creation dates, never the secrets
- the user's devices, on the Devices tab: the phones and computers that approve their sign-ins, alert them to sign-ins, or both. The tab shows which of the two each device does.
You can delete any passkey, app password, or device; passkeys and app passwords also all at once. You can also create an app password for the user. The panel shows its value once.
Sessions lists the user's live browser sign-ins with the application, start time, last activity, and expiry, and has Logout per session and Logout All.
Connected Apps lists the applications the user authorized through the identity provider. You can revoke that access here.
The sign-in portal describes what the user sees and can do with these same objects.
Reset credentials
There are two reset actions, separate by design:
| Action | Use it for | What it does |
|---|---|---|
| Reset credentials | A lost or compromised password. | The current password stops working immediately and all sessions are signed out. You get a single-use welcome link, valid for 72 hours, to hand to the user as when you invite them. The user has no password until they complete it. |
| Reset Two-Factor Authentication | A lost authenticator device, with the backup codes lost too. | Removes the authenticator enrollment and the backup codes so the user can set up a new one. The password and passkeys stay. |
Lockdown
Lock Down Account is your response to a compromised domain user. One confirmation applies the measures you select.
Selected by default:
- reset the credentials, and block the old password from reuse
- remove all app passwords and passkeys
- remove all devices, so an attacker's device can't approve the next sign-in
- empty the user's outgoing mail queue
An attacker usually compromises a domain user to send mail, and the queue is where that mail waits.
Optional measures make the policy permanently stricter: require two-factor authentication, limit traditional authentication to app passwords, or force passwordless sign-in.
You can also remove the backup codes. Anyone with the password can make a new set, so if an attacker had the password, remove them. The user keeps the authenticator app, and the portal asks them to make new codes after they sign in. This isn't selected by default, because for a user who lost the authenticator app, the backup codes are the only way in.
A hidden rule that forwards or deletes mail survives a password change, which makes it a common way for an attacker to keep access. The lockdown screen can remove the user's Sieve script for you.
If you reset the credentials, the confirmation page shows a new welcome link with the list of measures applied; recovery is the normal invitation flow. Each lockdown is recorded, and the user's page shows the count and history.
If the user's outgoing mail is held for review, a lockdown is also how you end the quarantine. See Outgoing Quarantine.
Sending-rate limits are usually how you learn about a compromise in the first place. Quotas and limits covers them.
Access control after sign-in
The Email Access Policy section is independent of authentication. It can:
- turn off a whole protocol for one domain user: IMAP, POP3, SMTP submission, Sieve, or DAV
- limit connections to a list of networks you accept
See Account types.
The Group Membership section on the same page is the other half. A user's groups decide:
- which shared addresses they receive mail for
- which addresses they can send as
- which restricted pages they can open, where you use groups that way
A group rule keeps accepting an open browser session for a few minutes after the change, so changing the credentials alone isn't enough.
To investigate rather than restrict, use the Access Log and Traffic Log tabs: who connected from where, and what mail actually moved.
The auth log
The Auth Log tab shows the user's browser sign-ins, failed sign-ins, and credential changes. Account Auth Log, in the menu, shows the same rows for every user of your account. Rows are kept for 90 days.
Two kinds of failed sign-in mean the person typed the correct password:
| Row | What it tells you |
|---|---|
| A failure at the second step, e.g. right password, wrong code | The second step stopped the sign-in. Tell the user to change the password. |
| right password, but the policy is passwordless | The user's authentication policy doesn't accept a password in the browser. Usually the user typed the password instead of using the passkey. If they didn't, tell them to change the password. A mail client can still use it if your policy allows. |
An incorrect password under a passwordless policy shows as wrong password, as under any other policy.