How to choose a transactional email service

Nearly every provider sits in one of three categories. The category tells you more about your likely experience than any feature list will.

Raw sending capacity sold by a hyperscaler — Amazon SES is the canonical example. You get an enormous, extremely cheap pipe and essentially no product on top of it. There is no meaningful dashboard for debugging a single message, event handling is something you assemble yourself out of other cloud services, and reputation management is entirely your responsibility.

This is the right choice when you have a dedicated deliverability function, when your volume makes per-message pricing dominate everything else, and when you would rather build the missing product than pay for someone else’s. It is the wrong choice for a small team that thinks it is buying a solved problem — the sandbox escalation, the bounce-handling pipeline, and the reputation work all land on you.

A well-designed developer product built on top of someone else’s sending infrastructure — commonly a cloud primitive underneath. The developer experience is usually excellent: clean API, good docs, fast onboarding, sensible defaults.

The trade-off is that the provider does not control the layer that determines deliverability. When the underlying pool has a bad week, the provider is in the same position you are — filing tickets with an upstream vendor. And because the entry tier is typically free and generous, the shared pool carries a large population of accounts that have not been vetted by anything stronger than an email confirmation.

A provider that owns and runs its own mail servers and IP ranges. Because the infrastructure is theirs, they can decide who is allowed onto it, isolate a customer whose behaviour is causing problems, warm new capacity deliberately, and hand you your own servers when you need them.

The trade-offs are real. Operators are usually more expensive per message than a cloud primitive, and they tend to be stricter about acceptable use — which is precisely the mechanism that keeps the pool clean, but it does mean the signup path involves more scrutiny.

Providers publish delivery-rate numbers that are close to meaningless — a delivery rate counts messages the receiving server accepted, which includes everything routed to spam. These questions produce more useful answers.

Headline per-message pricing is the least interesting part of the cost. What determines your actual bill and your actual constraints is the shape of the plan.

The overage row is worth dwelling on. Transactional volume is not something you control — it follows product usage, and a good week can push you past a plan ceiling. A provider that hard-stops at the limit turns a growth spike into an outage of your password resets. A provider that bills overage keeps your product working and sends you an invoice, which is almost always the trade you want for critical mail.

Teams routinely overestimate the code cost of switching providers and badly underestimate everything else. The API call is not the hard part — most transactional send endpoints converge on the same handful of fields, and swapping one SDK for another is usually an afternoon.

Because the ramp dominates, run both providers in parallel during the transition rather than cutting over. Route a growing percentage of traffic to the new one, watch bounce and complaint rates at each step, and keep the old path available until the new identity is stable at full volume.

The row that catches most teams by surprise is the third. IP allowlisting requests arrive the moment you sell to a company with a security review process, and "our provider uses a shared range that may change" ends that conversation badly. It is worth knowing in advance whether your provider can give you IPs you are allowed to name.

We are in the third category: we own and operate the mail infrastructure our customers send from, which is what makes the rest of it possible.

Production mail runs on a transactional-only network. Only paying customers send from it — there is no free tier on the production pool — and marketing campaigns and cold outbound are not permitted on it at all. That is a deliberate constraint on who we will sell to, and it is the mechanism behind the pool quality rather than a marketing claim about it.

When shared is not enough, Dedicated provisions mail servers and IP addresses for your workspace alone. We build them, we run the full warmup ramp, and we operate them; your IPs are listed in the dashboard so you can hand them to a customer’s security team. The API contract does not change between tiers, so moving up is a billing decision rather than a migration project.

The honest limits: we are not the cheapest per message, and if you want to run marketing campaigns and transactional mail through one vendor, we are not that vendor by design. If unit cost dominates your decision, a cloud primitive will beat us on price.