4SO LabDeliverability is a process
Routing, Shaping, Suppression, Warm-up and Feedback have to be seen together.
MAIL PLATFORM / GATEWAY
4SO Mail GatewayOutbound Delivery · Inbound Protection · Lifecycle
An independent Mail Platform for teams that want to run Outbound Delivery, Inbound Protection, Domain Identity, Queue, Deliverability, lifecycle and Observability as one product.
Outbound DeliveryInbound ProtectionMulti-tenantSelf-hosted
4SO Mail Gateway components: the message path from ingress to delivery
- 1Stable ingressHAProxy provides stable transport and HA endpoints for submission and receiving.
- 2Protection chainSPF, DKIM, DMARC and ARC plus Rspamd and ClamAV before any backend or quarantine outcome.
- 3Queue & spoolKumoMTA owns submission, queue and delivery; the spool is node-local, not shared.
- 4Routing & shapingA product-controlled Unbound resolver path, with Valkey for shared runtime data where required.
- 5Sending identity & DKIMSending pools, DKIM and DNS readiness move with the domain lifecycle.
- 6DestinationsDelivery with explicit state; queue, TLS and deliverability signals land in Prometheus and Grafana.
- 7Control PlaneRust Control API with PostgreSQL, Keycloak identity, OpenFGA authorization and OpenBao for secrets and recovery.
- 8Human approvalHigh-risk IAM changes: durable job, separate approval, execute-time reauthorization and post-check.
01PROBLEM & OUTCOME
Product problem
Enterprise email is more than sending and receiving messages.
Delivery, Reputation, DKIM, Queue, Inbound Security, Quarantine, Feedback and recovery each have their own failure modes. Mail Gateway brings these components into one coherent operating model.
Receiving needs layered defense
Authentication, Anti-spam, Anti-malware, Quarantine and Backend policy form a single chain.
Domains and tenants have operational boundaries
Sender authorization, access and sensitive changes are executed within the correct domain.
Nodes and the Control Plane have a lifecycle too
Provisioning, Drain, Switchover, Upgrade, Backup and recovery are part of the product itself.
02CAPABILITY SNAPSHOT
Capability snapshot
Outbound and Inbound on one platform, with clear boundaries.
Mail Gateway runs the sending, receiving and operations paths with a shared access model and shared observability.
High-volume sending
Authenticated submission, routing, queue and delivery from the Mail Data Plane.
Domain identity and DKIM
Domain authorization and the lifecycle of the sending signature.
Reputation and Suppression
Bounce, Complaint, Suppression and Warm-up management to protect Deliverability.
SPF / DKIM / DMARC / ARC
Authentication and evaluation of inbound messages on the Receiver path.
Anti-spam / Anti-malware
A protection chain that runs before delivery to the Backend or Quarantine.
Quarantine workflow
Hold, Release, Delete and Expiry with controlled access.
Queue and Delivery Visibility
Health, Routing, TLS, Queue and Deliverability in a single operational view.
Backup, PITR and recovery
Control Plane and mail-node lifecycle with defined recovery paths.
4SO
The Mail Data Plane does not depend on an LLM to send or receive mail; the mail-serving path is deterministic.
03DEPLOYMENT PROFILES
Deployment model
The Control Plane and mail nodes scale independently.
The product starts from a simple Control Plane and can grow into an HA Control Plane with multiple Mail Nodes for Outbound and Inbound roles; the Manager never enters the Mail Data Plane.
| Profile | Control Plane | Mail Data Plane | Use case |
|---|---|---|---|
| Single Manager | One Manager | One or more Mail Nodes | Simple deployment and central management |
| Distributed Mail Nodes | Central Control Plane | Separate nodes for Outbound / Inbound | Separation of capacity and Data Plane roles |
| HA Control Plane | Multiple Managers | Independent Mail Node Pool | Management redundancy without the Manager entering the Mail Data Plane |
| Recovery-ready | Control Plane + Backup/PITR | Rebuildable node lifecycle | Controlled recovery after failure |
04ARCHITECTURE
Architecture
The Control Plane decides; the Data Plane moves the mail.
Identity, Authorization, Tenant state and lifecycle live in the Control Plane; SMTP, Queue and Protection run on the mail nodes.
EXPERIENCEAdmin / Customer UI & APIDomain, Campaign, Routing, Inbound policy and operator actions.
↓
CONTROLMail Control PlanePostgreSQL, Identity, Authorization and Secret workflows.
↓
OPERATIONSDurable OperationsProvisioning, Approval, Activation, Rollback and recovery.
↓
DATA PLANEMail NodesKumoMTA/SMTP, Queue, Receiver, Protection and the Delivery runtime.
| Plane | Component | Responsibility | Operational boundary |
|---|---|---|---|
| Control | PostgreSQL + Product Authorization / Keycloak Identity | Tenant, Domain, policy, IAM, durable jobs and audit | Mail delivery does not depend on a live Control Plane for normal serving |
| Outbound | KumoMTA | SMTP submission, queue/spool, routing, shaping and Internet delivery | Node-local spool; there is no shared spool |
| Transport | HAProxy | Stable internal transport and selected HA endpoints | The proxy does not take over product ownership or queue semantics |
| Inbound Protection | Rspamd + ClamAV | Spam/policy evaluation and malware scanning | The protection chain runs before backend/quarantine |
| DNS / Runtime State | Unbound + Valkey | Product-controlled resolver path and shared runtime authority where needed | Resolver path and runtime state stay under product control |
| Runtime | Linux / VM Mail Nodes | KumoMTA, SMTP, sending IPs, DKIM and the queue data plane | Kubernetes is not a prerequisite for the Mail Data Plane |
TECH
Control-plane Security Contract. Mail Gateway keeps Identity, Authorization and the Secret lifecycle separate from the Mail Data Plane, and binds high-risk mutations to a durable job and human approval.
| Domain | Component / Authority | Technical contract |
|---|---|---|
| Control API | Rust Control API + PostgreSQL | Tenant/Domain/Policy/Job/Audit state persists in the Product database. |
| Identity | Keycloak | The OIDC subject carries the user identity; browser or MCP credentials never stand in for the user identity. |
| Authorization | OpenFGA + Product permission model | Unknown actions/routes fail closed, and permission is evaluated in resource scope. |
| Secrets | OpenBao | Secret material and the recovery workflow are kept separate from ordinary configuration and UI state. |
| High-risk IAM | Durable PostgreSQL Job | Request, human approval, execute-time reauthorization and authoritative post-check are separate steps. |
| MCP | Delegated OIDC + scoped product tools | MCP can pass requests/diagnostics through product authority; it has no self-approval or generic Admin API. |
| Observability | Prometheus + Grafana + product probes | Queue, TLS, routing and deliverability are shown from real telemetry; missing data is never presented as fabricated health. |
05LIFECYCLE
Lifecycle
The mail lifecycle runs from onboarding to recovery.
Domain and node provisioning is only the start; Deliverability, Protection, Queue, Rotation and recovery are all core product operations.
01Pre-checkPreflight
02ProvisioningProvision
03Domain and identityAuthorize
04SendingDeliver
05Receiving and protectionProtect
06MonitoringObserve
07Upgrade and rollbackUpgrade / Rollback
08RecoveryRecover
06MAIL PROFILES
Operational profile
Every mail path has its own tools and policy.
Instead of a one-dimensional Mail Server, the product coordinates several specialized workflows under one Control Plane.
Outbound SenderDELIVERY
High-volume sending path with Queue and Routing.
- Submission / HTTP injection
- DKIM and Sender authorization
- Routing / Shaping / Pools
Inbound ProtectRECEIVER
Public receiving with Authentication and Protection.
- SPF / DKIM / DMARC / ARC
- Anti-spam / Anti-malware
- Backend delivery / Quarantine
DeliverabilityREPUTATION
Control over sending behavior and feedback.
- Suppression
- Warm-up / Safety policy
- Bounce / FBL / OOB feedback
Tenant OperationsMULTI-TENANT
Domains, access and domain-scoped operations.
- Tenant / Domain boundaries
- Role-based actions
- Audit / approval workflows
Mail Node LifecycleINFRASTRUCTURE
Nodes are manageable resources too.
- Provisioning / Trust
- Drain / Fence / Switchover
- Health / recovery
Control Plane RecoveryRESILIENCE
Service management has its own Backup and recovery path as well.
- Backup / Restore
- PITR
- Upgrade / rollback
07ACTION & WORKFLOW CONTRACT
Typed Action flow
AI agents, the browser and the API all go through the owner workflow; there is no generic mutation proxy.
For administrative operations, the Plan and the impact of a change are visible before execution, and high-risk approval is kept separate from execution.
01DiscoverLIST ACTIONS
02PlanCREATE PLAN
03ImpactPRECONDITIONS
04ApproveHUMAN APPROVAL
05ExecuteDURABLE JOB
06VerifyPOST-CHECK
OUTBOUND FEEDBACK LOOP
Queue → Delivery → Feedback
Delivery is not the final outcome; bounces and telemetry feed back into policy.
SUBMISSION
→
QUEUE /
SPOOL
SPOOL
↓
POLICY
LOOP
LOOP
↑
INTERNET
DELIVERY
DELIVERY
←
BOUNCE /
TELEMETRY
TELEMETRY
routing · shaping · DKIM · delivery feedback
Node-local spool is not lost when the Control Plane goes down.
INBOUND BRANCH
Deliver / Quarantine / Reject
Inbound mail reaches an explicit outcome after auth and content gates.
SMTP RECEIVE
↓
SPF · DKIM · DMARC
↓
RSPAMD + CLAMAV
↓
DELIVER
QUARANTINE
REJECT
A protection failure is never bypassed; it goes to a policy-defined outcome.
APPROVAL GATE
High-risk IAM with Human Approval
Plan, Approval and execute-time reauthorization are kept separate.
PLAN + IMPACT
↓
HUMAN
APPROVAL
APPROVAL
↓
REAUTHORIZE
↓
KEYCLOAK WRITE
authoritative post-check closes the durable job
MCP or an agent is not allowed to self-approve or perform generic admin mutations.
Domain Onboarding
A domain follows one workflow from ownership to delivery readiness.
01Tenant / Domain02Ownership03DKIM04DNS Readiness05Routing Policy06Activate
Failure / RecoveryIncomplete validation or DNS readiness stops activation.
Outbound Delivery
Queue/spool is part of an independent Data Plane.
01Submission02Policy03Queue / Spool04Routing / Shaping05DKIM Sign06Internet Delivery
Failure / RecoveryNode-local spool is preserved; a Control Plane failure does not erase the queue.
Inbound Protection
Inbound messages pass through several gates.
01SMTP Receive02SPF / DKIM / DMARC03Rspamd04ClamAV05Route / Quarantine06Delivery
Failure / RecoveryA protection failure sends the message to a policy-defined outcome, not a bypass.
DKIM Rotation
Rotation runs with a secret boundary and a post-check.
01Rotate Request02Authorization03Key Material04DNS Stage05Signer Switch06Verify
Failure / RecoveryOld/new overlap and rollback stay within the owner workflow.
High-risk IAM
Approval is separate from execution.
01Plan02Impact03Human Approval04Reauthorize05Keycloak Write06Authoritative Post-check
Failure / RecoveryExpired or revoked authorization is rejected at execution time.
Mail Node Lifecycle
Node mutation takes spool and service role into account.
01Preflight02Provision / Drain03Fence04Service Mutation05Queue Check06Runtime Verify
Failure / RecoveryA switchover is declared successful only after Queue Check and Runtime Verify.
ADDITIONAL OPERATIONAL FLOWS
Additional operational flows
Queue incidents and Routing/Shaping are independent, high-risk Day‑2 changes.
Queue Incident Recovery
A backlog or delivery incident is investigated while preserving the truth of the node-local spool.
01Detect Backlog02Scope Tenant / Route03Inspect Spool04Freeze Risky Change05Typed Queue Action06Delivery Post-check07Unfreeze / Record
Failure / RecoveryQueue state is never blindly replayed or purged; that node’s spool and the operation history are the basis for recovery.
Routing / Shaping Change
Delivery policy goes through Impact and Telemetry before and after it is applied.
01Plan Provider / Domain02Impact Preview03Authorize04Persist Policy05KumoMTA Apply06Observe Queue / TLS07Delivery Verify
Failure / RecoveryA failed post-check keeps the change in a Failed/Reconcile state; changes outside Product Authority are not allowed.
| Action / Flow | Admission / Preconditions | Execution / Lock | Success Criterion | Failure / Recovery |
|---|---|---|---|---|
| Domain Onboarding | Valid Tenant/Domain ownership, authorization and policy input | Typed owner action; config/runtime mutation goes through the Control API | Domain/DKIM/routing readiness from Product state and runtime read-back | Validation failure before activation; partial state is tracked through workflow recovery |
| DKIM Rotation | Domain scope, signer identity and rotation preconditions | Durable mutation with audit and bounded secret handling | Active key/signing state and DNS-facing readiness are verified | Old/new key overlap and rollback are owner-specific; secret material is never shown in MCP/UI |
| Queue / Delivery Action | Exact tenant/queue/message scope and permission | Typed queue action; there is no shell/raw SQL/direct Kumo admin proxy | Queue/history post-check shows the result of that same action | An unknown outcome requires read-back; replay follows the owner’s idempotency semantics |
| Routing / Shaping / Suppression | Provider/domain/resource scope + risk/permission contract | Registry-backed action with Product policy authority | Effective route/pool/suppression state is read back after the mutation | Unknown action fails closed; historical risk downgrade is not allowed |
| IAM User Lifecycle | Delegated OIDC subject and Product authorization; high-risk impact preview | Request → independent human approval → execute-time reauthorization → Keycloak Writer | Authoritative Keycloak post-check confirms enabled/session/group state | MCP has no approve/execute bypass; stale/revoked authorization is rejected again at execute time |
| Mail Node Lifecycle | Pinned target/release identity, preflight and runtime readiness | Provision/Drain/Fence/Switchover tied to durable lifecycle/evidence | Node role, queue/spool and service health are verified from runtime | Node-local spool is assumed; a switchover failure is never hidden behind an assumed shared spool or fabricated success |
FLOW
The Management MCP lifecycle is explicitly list actions → create plan → inspect impact/preconditions → human approval → execute → post-check. An agent cannot approve its own proposal and has no general-purpose shell, raw SQL, filesystem or secret-export tool.
08OPERATIONS CATALOG
Operations catalog
From Domain to Queue and recovery, operations in one Workbench.
Operators should be able to see sending and receiving status and take the necessary action without switching between separate tools.
Run email as a critical data plane.
4SO Mail Gateway brings sending, receiving and operations together in one self-hosted, traceable product.