Why mailkube?
Email is core infrastructure. Most platforms don't treat it that way. They're either marketing tools with an API bolted on, or outbound-only pipes with no meaningful observability. Neither is built for teams who need to reason about what happens after they hit send, and then act on it. mailkube is built for those teams.
This page is the short version. The longer one, including what we deliberately left out, is in Why we built mailkube.
Deliverability you can reason about
High deliverability is a claim every provider makes. We’d rather give you the tools to maintain it yourself. Every message produces a signal you can act on: a complaint rate creeping above 0.1%, a bounce spike traced to the send that caused it. Inbox placement is not magic, and we would rather show you the inputs than promise you the outcome.
Templates as an organisational boundary
Most email APIs treat templates as a way to avoid hardcoding HTML. We think they are a contract between your engineering team and everyone else: engineers define the structure, everyone else owns the content inside it. Copy changes without a pull request, a deployment, or an interrupted engineer.
Two ways to integrate, both first-class
A versioned REST API with typed, open source SDKs, and a full SMTP relay for stacks that already speak SMTP. Same features, same observability, same inbox placement on both paths. Neither is an afterthought, and neither is a wrapper around the other.
Inbound email
Most providers stop at outbound. When an email arrives at your domain, mailkube parses it and delivers the payload to your webhook, attachments included. This is still an early capability, and it is deliberate: reply detection, ticket creation and abuse handling all need receiving to be a first-class operation.
Multi-region delivery
Your messages are sent from the infrastructure region closest to your recipient. Shorter paths mean lower latency, fewer hops, and better placement signals. You do not configure this. It is simply how the platform works.
Who this is for
Teams that treat email like any other part of their production stack: instrumented, cleanly integrated, expected to work. SaaS products sending password resets and billing confirmations. Fintech platforms where a misdirected email is a compliance problem. Developer tools where the people building the product are the people evaluating the infrastructure.