Transactional email infrastructure for the messages your users are waiting for.

A transactional email is one a specific person triggered and is waiting for. It is sent in response to an action that one recipient took — they bought something and want the receipt, they asked to reset a password and need the link, they logged in from a new device and expect the security alert, they booked a table and want the confirmation. The send is one-to-one, event-driven, and immediate. Marketing email is the opposite in every structural respect: one-to-many, scheduled by the sender, and arriving whether or not the recipient was thinking about you at that moment.

The crucial distinction is not the content of the message but the state of mind of the person receiving it. A transactional email lands on someone who is, very often, looking at their inbox right now, waiting for exactly this message. They are refreshing the screen for the login code, watching for the receipt to confirm the charge went through, expecting the reset link so they can get back into their account. That waiting changes everything about what the infrastructure has to guarantee, because the gap between sending the message and the recipient seeing it is a gap the recipient is consciously experiencing.

That is why transactional email is treated as a first-class workflow rather than a feature bolted onto a marketing platform. The requirements it generates — speed, isolation, reliability, observability — are not the requirements that marketing email generates, and a system optimized for sending a million newsletters on a schedule is not automatically good at delivering one login code in under a second. The rest of this page is about the specific infrastructure decisions that follow once you take seriously that someone is on the other end, waiting.

There is a useful test for whether mail belongs on transactional infrastructure: would a delay or a failure produce a support ticket within minutes? A late newsletter produces nothing; a late password reset produces a frustrated customer who cannot log in, and a failed one produces a support contact and an erosion of trust. Mail that fails that test loudly — auth codes, receipts, alerts, confirmations — is transactional, and it earns the dedicated infrastructure that the test implies. Mail that fails quietly, where no one notices a delay, is marketing, and it belongs on different infrastructure with different priorities.

The boundary is not always perfectly clean, and some mail sits ambiguously between the two — an order-status update, a shipping notification, a re-engagement nudge dressed up as an account alert. The test still helps: route the message by whether a person is waiting for it, not by what category a marketing taxonomy would file it under. A shipping notification someone is refreshing the page to see is transactional in every way that matters to infrastructure, even if a marketing team thinks of it as part of a lifecycle campaign. When in doubt, the safer default is to treat mail as transactional and give it the isolated, prioritized path, because the cost of under-serving a message someone is waiting for is far higher than the cost of over-serving one they are not.

Transactional and marketing email have opposite reputation dynamics, and that opposition is the whole reason to keep them apart. Transactional mail is opened almost every time, because the recipient asked for it and is waiting; that high engagement builds excellent sender reputation on the IPs that carry it. Marketing mail, however good, has lower and more variable engagement by nature — some recipients open, many do not, a few complain. Receivers read engagement as reputation, and they read it per IP.

When both streams share infrastructure, the lower-engagement marketing mail drags on the reputation of the IPs that also carry your transactional mail. A campaign that underperforms, or a list segment that generates complaints, can degrade the inbox placement of the password resets and receipts your users genuinely depend on. The asymmetry of the damage is what makes this unacceptable: a marketing email in the spam folder is a missed open, but a password reset in the spam folder is a customer who cannot get into their account, contacting support, losing trust in the product.

So we run transactional mail on IP pools isolated from marketing entirely. The transactional pool stays pristine because it carries only the high-engagement mail that builds reputation; the marketing pool carries the variable engagement without ever touching the infrastructure that delivers critical messages. This is the same principle the most respected transactional providers have converged on — named, separate streams for transactional versus bulk — and it reflects a broader truth: marketing and engineering optimize for different things, and the mail that gates a user's access to your product should not share fate with the mail that promotes it.

The isolation extends beyond just the IPs to how the streams are reasoned about and operated. Transactional sending is steady and event-driven, its volume tracking your application's real usage; marketing sending is bursty and campaign-driven, spiking when a send goes out. Putting them on shared infrastructure means a marketing burst competes for the same capacity that a steady stream of login codes needs, and the steady stream is the one that loses. Separate pools let each be sized and operated for its own pattern — the transactional pool for low-latency, always-on reliability, the marketing pool for absorbing scheduled spikes — so neither compromises the other. The separation is not only about reputation; it is about giving two genuinely different workloads the two genuinely different operating environments they need.

For marketing email, a delay of a minute or even an hour is invisible — no recipient is timing the arrival of a newsletter. For transactional email, the delay is the product experience. A one-time login code that takes forty seconds to arrive is, from the user's side, a login that is failing, and many will give up or request another code before the first one lands, compounding the problem. Password resets are widely recognized as the most time-sensitive transactional mail precisely because the user is blocked from doing what they came to do until the message arrives.

This is why our transactional pools target a P99 queue time under 500 milliseconds, with median well under 100 — the queue time is the part of the latency we control, the gap between accepting your message and handing it to the receiver, and we hold it tight because every millisecond of it is a millisecond the user spends waiting. Priority routing is the mechanism: transactional mail jumps ahead of bulk campaign traffic in the queue, so even when a large marketing send is in flight, a login code is not stuck behind a million newsletters.

It is worth being precise about what latency we can and cannot control, because honesty about that boundary matters. We control the queue time — submission to handoff — and we hold it to the sub-second targets above. What happens after handoff is partly the receiver's: a mailbox provider applies its own processing, and a few receivers introduce small delays of their own. What we guarantee is that nothing on our side adds avoidable delay to a message someone is waiting for, and that transactional mail is never made to wait behind bulk traffic. The way to verify any provider's claim here is the standard test: trigger a thousand login codes, measure the time to acceptance and to inbox, and watch how the system behaves when a webhook endpoint goes down mid-run.

The priority routing that makes this possible is not just a queue ordering; it is a commitment that holds under load. The hardest moment for transactional latency is precisely when a large marketing campaign is going out, because that is when the most mail is competing for capacity. A system that prioritizes transactional mail only when it is convenient will let login codes slip exactly when a big send is in flight — the worst possible time. Real prioritization means the transactional stream keeps its sub-second queue time even mid-campaign, because the infrastructure reserves the capacity to honor that commitment rather than borrowing it from the campaign and hoping no critical mail arrives in the gap. Holding the guarantee under load is the whole point; a guarantee that only holds when nothing else is happening is not a guarantee at all, and it is exactly the kind of hollow, conditional guarantee a marketing-first platform tends to make about the transactional mail it quietly treats as a secondary, lower-priority concern.

The most common mistake is the one this page keeps returning to: sending transactional mail from the same infrastructure as marketing. It is an easy trap, because if you already use one provider for campaigns it is tempting to just point your password resets at the same place. The result is that your most critical mail inherits the reputation swings of your least critical mail, and the day a campaign underperforms is the day your login codes start landing in spam. Many teams discover this only after an incident, and end up splitting the streams retroactively — which is harder than designing them apart from the start.

A second mistake is treating delivery as fire-and-forget, with no observability into what actually happened to each message. Without webhook events, a transactional email that silently fails — a soft bounce that never retried, a deferral nobody noticed — becomes a support ticket from a confused user and a debugging session with no data. The fix is to wire the events into your own systems from the start, so that a failed delivery triggers a visible signal rather than a silent gap. The providers that treat transactional mail seriously expose this lifecycle in full; the ones that treat it as a feature checkbox surface only a delivery count and leave you blind to the failures.

The third mistake is skipping authentication, or setting it up once and never maintaining it. Transactional mail with broken or misaligned SPF, DKIM, or DMARC is mail that receivers distrust regardless of how engaged the recipients are, and authentication that worked at launch can silently break when a key rotates or a DNS record is edited. Because transactional mail is the mail you cannot afford to have distrusted, the authentication under it has to be maintained continuously rather than configured and forgotten. These three mistakes share a root: treating the mail your users wait for as if it were the mail they ignore. Avoiding all three comes down to a single discipline — giving transactional mail infrastructure that matches its importance instead of borrowing whatever the marketing stack happens to provide, because the gap between those two choices is measured in locked-out users and support tickets. The teams that get transactional email right are the ones that made it a deliberate infrastructure decision early, rather than discovering its real importance later through a painful outage that taught them the difference the hard way.