The console is an expert cockpit — and the wrong first hour for someone who just wants a mail filter. Protection is one page that answers the three questions most operators actually have — how strict is it, what happens to flagged mail, and what protection is running — in outcome language, with nothing rspamd-shaped on it.

Strictness is a choice between four named levels — Relaxed, Standard, Strict, Aggressive — each with a one-line promise that includes its honest cost. And before anything is applied, the page shows what each level would have done to this deployment's own mail over the selected period: how many messages rejected, tagged, greylisted — computed from the live corpus, not from a brochure.

The page opens with a flow graph of the selected period: received mail fanning out into rejected, tagged, accepted and parked-for-inspection, then what ran while messages were parked and what they became when released — every box a real count from the deployment's own logs.

The picture follows the configuration. Turn the background judge off and its chip greys out; switch holding off and the branch collapses to a dashed outline. The diagram is the current policy, not a stock illustration of one.

A level adjusts how much mail flows into deep inspection and how the background judge leans on borderline calls; the protection machinery itself stays on at every level. A hand-tuned config shows as Custom — closest to Strict with the exact differences named, applying a level touches only the thresholds the level owns, and one button returns to the scanner's own configured values. Every apply is audited.

Each protection layer carries its own three-state switch — off, shadow, enforce. Shadow is evaluate-before-trust: the layer runs and reports, but contributes nothing to verdicts until you promote it. And for deployments whose thresholds must never move from a UI, a read-only mode keeps the whole page visible while Apply and the switches refuse, with the reason stated.

Turnkey deployments can start the console with a collapsed navigation — Overview, Protection, Quarantine, Mail Streams, Audit, Settings — and an Advanced view switch for the day the operator outgrows it. Nothing is removed: every expert page stays reachable, and support can still deep-link to any module.

Operator-defined rate limits, enforced live — no config rebuild. Each rule is a leaky bucket keyed by whatever selector you choose: a sending IP, an ASN, a sender domain, or an authenticated user.

The live viewer shows who is throttled right now, in readable form rather than as an opaque hash, and lets you release a bucket for a sender who tripped a limit they shouldn't have.

A fixed rate is a blunt instrument: the right limit for a bulk sender is wrong for everyone else. Adaptive mode holds each selector value to its own learned baseline, with your configured rate as the cold-start fallback until that baseline exists.

The obvious application is outbound abuse: cap each authenticated user at a sane hourly volume, and a compromised account stops being an open relay before anyone notices the password was stolen.

Correlates the signing configuration you have published with what DNS actually serves. Every selector is resolved live, and domains that sign with a broken or absent key are flagged — the failure mode that silently destroys deliverability and shows up nowhere in your own logs.

Alongside the configuration check: signed and ARC volume over time, and the verification mix on inbound mail.

Is every domain we sign for actually verifiable? Did someone rotate a key and forget the DNS record?

A signing configuration that looks correct on the mail server and is broken in DNS is invisible until recipients start rejecting your mail. This panel makes it visible.

Every operator action against the console is recorded: who, what, when, the outcome, and the redacted request payload. Filter by user, method, outcome, or a substring of the path and payload; each row carries a request id that joins to your structured logs.

Alongside the trail: an activity timeline, the top operators and endpoints, the method mix, and p95 latency.

Who changed that symbol weight? What did we approve last Tuesday, and did it succeed?

Admin-only, and the answer to the question every auditor asks about a tool that can change a production filter.

Share detection knowledge between deployments through a hub. Nodes publish rule, map and score edits, and neural training vectors; nodes can also pull other nodes' curated rules back down.

Pulled changes are staged and logged by default — auto-applying them is a separate, deliberate opt-in. Application is idempotent and happens at most once, and a node never re-applies its own changes echoed back.

Only rule definitions and derived vectors are federated. Raw mail, recipients, message ids, learn-queue contents, rescans and ephemeral actions stay on the node. Message ids are hashed where they are needed for deduplication.

The Bayes classifier is deliberately excluded: it trains on raw message tokens, so there is no privacy-preserving way to share it. Batches are signed and retried from a durable outbox.

Can my second datacentre benefit from what my first one just learned, without either of them shipping mail off-box?

Disabled by default, and configured from the admin-only Settings page — alongside the per-task model and API-key configuration for the console's LLM features. Turn federation on per plane, per direction.