Mail Infrastructure / Deliverability
4SO Mail Gateway
A Linux/VM-first platform for outbound delivery, inbound protection, routing, reputation and mail lifecycle operations.
- KumoMTA
- Routing & shaping
- Reputation
- Inbound protection
- Recovery
The problem
Problem
Mail sits at the intersection of protocol, reputation, abuse, security and operations; installing an MTA alone does not create a product or deliverability.
Why It Is Hard
Routing, sending identity, rate control, queue behavior, protection and reputation must work with observability and recovery without depending on a hosting panel.
The decision
Leadership / Architecture Role
Kept the data plane on hosts and VMs, avoided unnecessary Kubernetes complexity and designed the product independently from hosting panels.
Key Decisions
Keep Kubernetes out of the critical delivery path, remove hosting-panel adapters and treat multi-IP, routing and rate control as product capabilities rather than configuration snippets.
The architecture
Architecture
A host and VM data plane handles SMTP, queues and sending identity; a separate control plane owns tenants, policy, routing, evidence and lifecycle; other mail servers integrate through explicit contracts.
Failure & Recovery Model
Queues and spool must behave predictably across restarts or control-plane impairment; recovery is based on observed delivery state.
Security / Authority Model
Tenant isolation, DKIM and key handling, inbound protection, abuse controls and secret management are part of the lifecycle.
The value
Product Experience
Domains, routes, sending identities, policy and health become product workflows so operators do not have to manipulate scattered configuration manually.
Value Created
Deliverability, routing, protection and lifecycle become a manageable capability instead of disconnected configuration.
The boundaries
Trade-offs
A Linux/VM-first design reduces orchestration complexity but demands strong discipline in packaging, upgrades and host lifecycle.
What Was Intentionally Excluded
Dependencies on hosting panels, Kubernetes in the critical SMTP path and AI as a delivery dependency are intentionally excluded.
Truth boundary
Current Truth / Limitations
AI is an operations aid, not a delivery-path dependency; physical certification remains separate from source readiness.
designed → source implemented → runtime tested → production certified
Each level is claimed separately; a lower level never implies a higher one.
Start a conversation
If technology should move your organization forward rather than hold it back, let’s talk.
The first conversation is about your problem, not about me: where you are stuck, what is at stake and whether I am the right person to solve it.
Bring the problem