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.