What this screen is for
Almost nothing about how MailGuardHQ behaves is written into the code. Rate limits, page sizes, token lifetimes, the thresholds that decide when a token's usage looks anomalous - all of them are rows you can edit here. That is deliberate: the first number anyone picks for a threshold is usually wrong, and finding that out should cost an edit rather than a deployment.
These are SYSTEM-scope values. One change here applies to every tenant at once. A customer tuning their own account settings is doing something much smaller, and they can never step outside the window a system value sets.
Reading a setting before you change it
Every row carries its own explanation, and it sits next to the field rather than on a help page, because a help page is somewhere you go afterwards.
- The description says what the setting actually controls, in plain words rather than in the name of the code that reads it.
- Lower means and Higher means say what each direction COSTS. Not a restatement of the name - the consequence. A threshold that warns earlier gives more notice and more noise; one that warns later is quieter and leaves less time to act.
- Allowed is the range the value may take. It comes from the row itself, so it is the same range the API enforces rather than a hint that might drift from it.
What happens when you save
The value is validated twice. The browser refuses anything outside the allowed range before it is sent, which saves a round trip that could only end the same way; the API validates again on write, and that is the check that actually guards the data. A value that reached the database unvalidated would be found at three in the morning as an exception rather than here as a refusal.
Every change is audited with your name, the value before, the value after, and when. That record is what makes a behaviour change distinguishable from a bug later, so there is no way to change a setting quietly.
Reset puts a setting back
Reset returns a setting to the value it ships with. It is a separate action from typing that number in yourself, and the difference is recorded: "put it back" and "set it to something that happens to equal the default" are different intentions, and six months later the trail should be able to tell them apart.
What this screen will not do
No secrets are here, and none ever will be
Connection strings, signing keys, the token hash key and the signup pepper live in Key Vault and are referenced by name. A secret in a table this screen renders is a secret on a screen, in a screenshot, and in whatever is recording the meeting.
Some values also cannot be changed here at all, and that is not an oversight. SPF's ten-lookup limit is fixed by RFC 7208 - making it editable would only let somebody set it to fifty and get confidently wrong answers.