Policy tiering
A policy exists at two tiers:
- the domain's Mail service carries a default for every address on that domain
- each domain user can carry an override on their own account
The value that actually applies is the effective value, calculated from both tiers. An Enforced switch on the domain tier decides which one wins.
This applies to every policy in the panel that offers Use default policy:
- the authentication policy
- the Email Access Policy, for IMAP, POP3, submission, Sieve, and DAV
- the list of allowed IP addresses
- the spam score threshold
- the rate limit
Where each tier is
| Tier | Where | Enforced switch |
|---|---|---|
| The whole domain | The Mail service page: open Services, select the zone, then the domain's Mail service. See Email policies for the full list. | Yes, one per policy. |
| One user | The domain user's page under Domain Accounts: the Authentication tab and the Email Access Policy section. | No. A domain enforces on its users; a user enforces nothing. |
How the effective value is calculated
Each tier stores its value separately, and either tier can have none; that's what Use default policy means on a form. The calculation starts at the top:
If neither tier has a value, the built-in default applies: the main password is accepted for both authentication settings; IMAP, POP3, submission, and DAV are on; Sieve is off; the spam threshold is 6.0; there is no IP restriction.
An override that enforcement replaces stays stored and does nothing. Turn enforcement off again and it takes effect again. So enforcement is reversible, but turning it off can bring back a setting a user chose long ago.
The domain value is used exactly as it is; there is no "at least as strict as" comparison. Enforce Allow password on a domain where a careful user chose Passwordless, and that user's account becomes less strict.
When to enforce
| Leave it unenforced when | Enforce it when |
|---|---|
| The value is a good starting point and you accept that an individual changes it. It applies to every user who chose nothing else; a user who needs something different sets it themselves. | The value is a requirement for the whole domain, not a suggestion, e.g. "no mail access with a plain password on this domain, ever". |
Enforcement cuts both ways, and both are the point: a user can't make the rule less strict, and can't make it more strict either.
Some of your users want a passwordless browser sign-in and others aren't ready for it. Enforce Allow password with 2FA, and you hold everybody at the middle setting.
Set the domain default to the level that suits most users, and enforce only the minimum you accept for anybody.
Read the effective value
A domain user's page shows each policy with the value that applies to that user, and a marker says which tier it comes from:
| Marker | Meaning |
|---|---|
| (inherited) | The user set no value. What you see comes from the domain default or the built-in default. |
| An Enforced badge | The domain locked this policy. The user's own setting, if any, has no effect, and their form offers nothing to change. |
| No marker | The user's override, in effect. |
A change takes effect at the next sign-in
The value is calculated when a credential is checked, so a policy change reaches every new sign-in immediately, including the next IMAP connection and the next browser sign-in.
A browser session that is already authenticated keeps working, and an OpenID Connect application that already signed the user in keeps the claims it received then.
When a policy change is your answer to a compromise rather than ordinary maintenance, also revoke the user's sessions, or use Lock Down Account, which does both in one step. See Manage domain users.