Deliverability you can act on
Every provider claims high deliverability. The claim is close to unfalsifiable, because inbox placement is decided mostly by your list and your content, and no platform controls either one. We stopped selling the outcome and built for the inputs instead.
New sending IPs warm up on a six-stage ladder, from 50 messages a day to 10,000. Per-stage bounce ceilings hold you at a stage rather than letting a bad week compound. Dedicated IPs are included from the Elite plan up. SPF and the bounce return path are published on a send. subdomain we operate. Your own domain keeps its ten-lookup SPF budget intact, and DKIM signing is ours to maintain rather than yours. What you add to DNS is in the domains guide(opens in a new tab)
.
A hard bounce suppresses that address across every domain sharing your apex. A burn on mail.example.com also protects news.example.com.
Add every domain and subdomain you send from. The count is not metered by plan.
You can see all of it while it happens. Every message writes a log line you can filter by your own tags, alongside dashboards for bounce reasons, sending IPs, top links and webhook health. A bounce spike on one subdomain traces back to the send that caused it, while you can still do something about it.
Your application finds out at the same time you do. Webhooks are HMAC-signed with a secret shown once and rotatable on demand. The signature covers a timestamp, and your receiver can reject a replay. An endpoint has to answer a one-time challenge before we will save it. A typo cannot quietly point your events at someone else’s server.
Every message scanned first
Every message is scanned before it is charged to your quota, the HTML and the text, over REST and over SMTP, templated or raw. The scan is mandatory, because the day it earns its keep is the day an API key leaks.
Oversized bodies, disallowed markup and forbidden patterns are rejected outright. Clickable links are checked against Spamhaus, and a send carrying a listed domain is refused and recorded as a hard bounce against the sending domain. The cost lands where the problem is, and the recipient’s address stays deliverable. The fault is in the message rather than in the address.
Two ways in, both first-class
POST to the REST API, or relay through SMTP from whatever you already run. Templates, tags and topics all work over SMTP headers, and an existing system needs no rewrite to use them. Point it at us and judge the result before you commit to anything.
{
"from": "billing@acme.io",
"to": "ada@example.com",
"topic": "receipts",
"tags": [
{ "name": "campaign", "value": "q4_launch" }
]
}From: billing@acme.io
To: ada@example.com
Subject: Your receipt
X-Mailkube-Topic: receipts
X-Mailkube-Tags: [{"name":"campaign","value":"q4_launch"}]Retries are safe. An Idempotency-Key is honoured for 24 hours, so a request that times out halfway can be repeated without sending twice.
If you would rather the relay ran inside your own cluster, it does, OpenShift and restricted security contexts included.
Your stack, already covered
Official SDKs cover Python, Go, Node, PHP, Ruby and Java. Django, Laravel, Rails and Spring Boot get a package of their own that plugs into the framework’s own mail layer. Flask, FastAPI, Gin, Echo and Fiber get worked integration guides.
The Node SDK has no runtime dependencies and uses web standards only. A single build runs unchanged on Node, Cloudflare Workers, Deno, Bun and Lambda, with no compatibility flag to set.
There is a CLI as well, one binary that sends over either transport, manages scheduled sends and runs a local webhook receiver while you develop. It carries a skill file for coding assistants, so yours reads the real command surface instead of inventing one.
Classified before it leaves
A topic(opens in a new tab) is the mailing list a send belongs to: a newsletter, a product update, a receipt. Name it on the REST field or in an SMTP header, and every message leaves already classified, rather than being sorted out afterwards from a subject line.
Tags are your own metadata, up to twenty per message, and they follow the message into the logs, the dashboards and the webhook payload. Slice delivery by whatever your business cares about.
Templates are versioned and rendered server-side, over REST and SMTP alike. Engineers own the structure and everyone else owns the copy inside it. A wording change stops needing a pull request, a deploy and an interrupted engineer.
Where your data lives
Customer data is stored at rest in the European Union, and operational access to it happens from inside the EU. Our infrastructure sub-processor runs it from European data centres and contracts through a United States entity in the French OVHcloud group. Two things do cross that boundary in normal operation. The first is connection metadata, which our CDN handles at the point of presence nearest the recipient. The second is whatever you put in a support ticket. Both run on Standard Contractual Clauses, as does every sub-processor that contracts through a United States entity, and we name all of them.
The mechanics are the checkable part. A lint gate keeps recipient addresses and subject lines out of server logs, and it fails the build rather than filing a ticket. Error reports pass through a scrubber before they leave the process. Retention windows are enforced by a job that runs daily, and when data is erased the caches keyed on it are dropped with it.
All of it is in the data processing agreement, including the sub-processor list, the 14 days of notice before that list changes, and your right to object. There is an Article 27 representative in the European Union, and the company itself is incorporated in Delaware.
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.
If what you need is a campaign builder with audience segmentation and send-time optimisation, that is a different product, and some of the ones that exist are very good. mailkube sends your application’s mail and tells you what happened to it.
The longer argument, including the parts we decided not to build, is in Why we built mailkube.