A billing confirmation does not arrive. The customer says they never got it, support checks the dashboard, and the dashboard says delivered. That is where the trail ends.
Nobody can say whether it reached the inbox, landed in spam, or sat in a deferral queue for six hours because a shared IP picked up a listing that morning.
Sending is solved. Everything after it is not
Every provider is good at accepting your message. That part of the problem was finished years ago.
What most platforms do not give you is the rest of the story. You get an accepted status, a delivery percentage, and a chart counting opens. None of that tells you where a specific message went, or why the last three hundred to one domain behaved differently from everything else you sent that week.
So teams end up reasoning about their most critical notifications by guesswork, on infrastructure they cannot see into.
Email is infrastructure, not a marketing channel
That is the whole disagreement, and everything below follows from it.
Treat email as a marketing channel and the tooling you build is campaign-shaped: audiences, engagement scores, send-time optimisation, a dashboard of rates. Treat it as infrastructure and you build the things you would expect from any other production dependency. Instrumentation. Clear failure modes. The ability to answer a question about one request.
We took the second view, and it decided the rest.
Signals, not promises
Every provider claims high deliverability. It is the least falsifiable claim in the category, because inbox placement depends on what you send and who you send it to, not on whose pipes you rent. A provider can give you good infrastructure and sane defaults. It cannot promise you an outcome that is mostly determined by your own list and your own content.
So we stopped selling the outcome and built for the inputs instead.
Every message produces events: accepted, deferred, bounced, complained. Those are not dashboard decoration. They are the early warning:
- Complaint rate crossing 0.1 percent, visible while you can still act on it rather than after a mailbox provider has already reacted.
- A bounce spike on one subdomain, traced back to the send that caused it.
- A bounce reclassified when the failure was ours, so your reputation is not charged for our outage.
That last one matters more than it sounds. If a receiving server rejects your mail because something on our side misbehaved, counting it against your sending reputation would be both wrong and invisible to you.
Where your data lives is not a footnote
Customer data is stored and processed in the European Union, on European infrastructure, and operational access to it happens from within the EU. Privacy is handled as an architecture problem rather than a page in the footer.
That means specific things, and they are checkable. A logging-hygiene gate and an error-monitoring scrubber keep recipient addresses, subject lines and template variables out of server-side logs and error reports. Retention windows are enforced by a daily automated job rather than by good intentions, and when data is erased the caches keyed on it are invalidated too, so nothing stale outlives it. All of it is written down in a data processing agreement you can actually read, including every sub-processor and where each one sits.
Worth separating from all of this: your messages are still sent from the infrastructure region closest to your recipient. Where data is governed and where mail leaves from are two different facts. Shorter delivery paths mean lower latency and better placement signals.
One platform, every way in
You can POST to a REST endpoint or relay through SMTP from any client. Both are first class, and neither is a wrapper around the other.
curl -X POST https://api.mailkube.com/mta/v1/emails \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "billing@example.com",
"to": "customer@example.com",
"subject": "Your receipt",
"tags": [{ "name": "kind", "value": "receipt" }]
}'
The same message over SMTP carries the same features through headers, so an application that already speaks SMTP does not need rewriting to get tags, topics or templates. Plenty of platforms treat SMTP as a legacy on-ramp with half the feature set, which forces a migration before you can evaluate anything. We would rather you point an existing system at us on a Tuesday and judge the result.
The SDKs are open source, so you can read what they do, fork them, or check the error handling before trusting it. And the relay runs in your own cluster if you want it there, including OpenShift under restricted security contexts.
Who built it, and why the design looks like this
The team came out of ISP, telecom and carrier-grade systems, where a queue backing up was somebody’s pager at three in the morning.
That background shows up in one specific decision. The API owns all policy and all state: every authentication check, quota decision, signing key and routing rule is resolved there at request time. The transports stay stateless couriers. It is a more demanding design than letting each edge node keep its own copy of the truth, and it is the reason a policy change takes effect everywhere at once instead of eventually.
Paying should not be the thing that stops you
Billing is where platforms quietly exclude people. Card-only, one currency, one processor built for one market, and a large part of the world is locked out of a product that would otherwise work fine for them.
mailkube supports regional pricing and local payment methods, so the payment step is not the reason you cannot adopt it. The specifics are on the pricing page, which adapts to where you are.
What we did not build
There is no campaign builder. No drag and drop audience segmentation, no send-time optimisation, no engagement scoring.
Those are real products and some of them are very good. They are not this one, and building them badly alongside an infrastructure product would make both worse.
Where we actually are
Inbound is early. mailkube parses incoming mail and delivers it to your webhook, and that path is younger and less proven than the outbound one. If receiving is the core of what you are building, you should know that before you start rather than after.
We would rather say so here than have you find out in week three.
Try it
The quickstart sends your first message in about four minutes. The full reference for REST, SMTP, the SDKs and the CLI is at docs.mailkube.com.
If you want the shorter argument for the design rather than the story behind it, that lives on the why page.