Email policies
A domain's Mail service carries the rules for every address on it: how people sign in, which mail protocols they can reach, and a few per-user limits. Set them once on the service and every mailbox inherits them.
All three groups are on the Mail service page: open Services, select the zone, then the Mail service for the domain. The same page holds sender verification and the mail gateways.
Most defaults are right from the start. This page is for making them stricter for a domain, and for seeing what a user can and can't change on their own account.
Defaults, overrides, and "Enforced"
Every policy here works the same way. The value you set is the domain default; each domain user can override it unless you turn on Enforced.
| State | What it means |
|---|---|
| Not enforced | A starting point. It applies to every user who hasn't set their own value. |
| Enforced | Locked. The user's own setting is ignored, and the user can't make the rule less strict. |
Enforce a policy that is a security requirement for the whole domain, such as "no mail access with a plain password, ever". Leave it unenforced when it's only a good default and you accept that an individual changes it.
A user's override lives on the mailbox itself; see Manage domain users. Policy tiering gives the order of resolution, what happens to an override once you enforce a policy, and the built-in defaults.
Authentication Policy
Two settings decide how a user proves who they are, one for each of the two very different places a user signs in from.
Traditional password authentication covers the system mail and file protocols: IMAP, POP3, SMTP submission, FTP, SFTP, CardDAV, and CalDAV.
| Setting | Effect |
|---|---|
| Allow password & app passwords | The main password works for these services, and so does an app password. |
| Disallow password, allow app passwords | The main password stops working here. The user creates an app password for each app. |
Modern (browser-based) authentication covers sign-in in a browser: the panel, webmail, and OpenID Connect.
| Setting | Effect |
|---|---|
| Allow password | A password alone signs the user in. |
| Allow password with 2FA | After the password, a second factor. A passkey alone always satisfies this. |
| Passwordless (using any Passkeys) | A password doesn't work; the user needs a passkey. |
| Passwordless (certified security key only) | A password doesn't work; the user needs a certified security key. A passkey on a phone or in a password manager doesn't count. |
The main password is one long-lived secret that the client sends on every connection. An app password lives in exactly one app, can be revoked on its own, and can't sign in to the panel or change an account setting.
So prefer OpenID Connect with passkeys, and give an app password only to a client that can't use modern authentication. The "Why restrict password authentication?" link on the policy gives the full reasoning.
The page also draws an Authentication Paths diagram of how a typical user can sign in under the policy you chose; check it before you save that you haven't locked everybody out. Authentication policy explains the diagram and which protocols support which branch.
Email Access Policy
Which mail protocols work at all. Each is on, off, or "use the default".
| Protocol | What it is |
|---|---|
| Webmail | Always on. It's the one way in you can't turn off, so a user is never completely locked out of their mail. |
| IMAP and POP3 | The two ways a mail client reads mail. |
| Submission (SMTP) | Sending mail from a client. |
| Sieve (ManageSieve) | Managing filtering rules on the server. |
| DAV (CalDAV/CardDAV) | Calendar and contact sync. |
If all your users read mail over IMAP, turning off POP3 costs them nothing and removes one more way in. Webmail stays on, so there is always a way in.
Account Policy
Per-user defaults, applied to every mailbox on the service:
| Setting | Notes |
|---|---|
| Rate Limit | How much mail one user can submit in a period. Shown for reference; your hosting provider changes it with service:mail:edit, not from this form. |
| Allowed IP Addresses | Limits sign-in to these IP addresses or CIDR ranges, one per line. Empty accepts any address. Useful when a domain's users should connect only from a known office network. |
| Spam Score Threshold | The domain default for the spam score, 6.0 until you change it. Lower catches more spam and marks more good mail as spam. See Spam filter. |
| Mailbox Quota | The default storage limit for a mailbox on this domain. Empty means no limit. |
| Also relay to your own server | Off by default. On relays a copy of each mailbox's mail to a server you run; enforced relays every mailbox on the domain. Does nothing until you turn relaying on for the domain. See Relay to your own server. |
| Delete mail older than | A retention period in days. Empty by default. |
Delete mail older than is unlike everything else on this page. It doesn't restrict access: it permanently deletes every message past that age in every mailbox on the domain, including Sent mail, Drafts, and mail the user flagged or never read. Delete old mail has the details.
Each of these has the same Enforced switch: offer them as defaults, or lock them for the whole domain.
What to do about a compromise
The policies are the rules for normal operation. When one mailbox has a problem, e.g. a leaked password or a suspicious sign-in, use the mailbox's Lockdown action rather than editing the domain policy. In one step it can:
- reset the password and block reuse of the old one,
- require two-factor authentication,
- turn off password authentication,
- revoke the app passwords and passkeys,
- empty the outgoing queue, and
- remove any Sieve script.
It's on the account's page, and each lockdown is recorded in the account's history.