Why is transactional email a different problem than marketing?
Transactional messages — password resets, OTPs, order confirmations, shipping notifications, account alerts — have to arrive within seconds of the triggering event, every time, regardless of the time of day or the volume that day. Inbox placement matters less than delivery latency and SLA reliability, because the recipient is actively waiting for the message in front of a screen. A 30-second delay on an OTP is a customer service ticket; a 5-minute delay is a churned account. This is a different problem from marketing email and it benefits from being treated as one.
Why do transactional senders move from AWS SES?
SES is the most common starting point for transactional email because it is the cheapest per-message. Customers tend to outgrow it for three reasons: (1) the IP warmup process is entirely DIY and most teams underinvest in it, leading to throttling at Gmail and Outlook when volume spikes during a launch or a Black Friday-type event; (2) when something goes wrong, the path to a human at AWS who actually understands email is gated by Business Support pricing and not optimized for the case where you need an answer in 30 minutes, not 30 hours; (3) the burden of monitoring deliverability across mailbox providers, parsing DMARC reports, and managing IP reputation falls on the customer team, who almost always have other things to do.
What does OS Domains change for transactional senders?
Three things are tuned differently for transactional traffic on our platform versus marketing. First, message priority queueing: transactional messages bypass any per-customer batch queue and go directly to the per-IP dispatch lane, with a separate rate limit pool. Second, we warm IPs assigned to transactional pools faster because engagement signals are unambiguous (recipients open password resets and shipping notifications at high rates, fast). Third, the on-call rotation has separate paging thresholds for transactional latency anomalies — if median delivery latency exceeds 3 seconds for a single customer for more than 5 minutes, the on-call engineer is paged regardless of overall platform health.
Is authentication required for transactional email?
The bulk-sender rules Gmail, Yahoo, and Microsoft rolled out from February 2024 onward do not exempt transactional traffic the way many teams assume. The thresholds count all mail from a domain, so a SaaS sending password resets and shipping notices from the same domain as its newsletters inherits the requirement: aligned SPF inside the ten-DNS-lookup limit, a valid DKIM signature on every stream, and a published DMARC policy. Microsoft began rejecting non-compliant high-volume mail outright in 2025, returning a hard 550 rather than a silent junking, which for an OTP means the code never arrives and the login simply fails. The failure is invisible from the sending side unless you are watching bounces per provider, because the request returns a normal acceptance and the rejection happens downstream. We authenticate transactional pools to enforcement by default, monitor the per-provider acceptance and bounce signals specifically for the transactional streams, and alert on a rejection-rate change at a single provider before it turns into a wave of "I never got the code" tickets. Fast delivery and correct authentication are the same requirement now: an unauthenticated OTP is not a slow OTP, it is a missing one.
Apple Mail Privacy Protection is a non-issue here, and that clarifies the metrics.
Marketing teams spent the last few years adjusting to Apple Mail Privacy Protection inflating open rates, and the reflex is to ask how it affects transactional sending. It does not, because open rate is not a metric that matters for transactional mail in the first place. Nobody optimizes a password reset for opens; the recipient is in front of the screen waiting, and the only questions are whether the message arrived and how fast. That clarity is a feature of the workload. The signals we hold transactional pools to are delivery confirmation from the recipient mailbox, end-to-end latency from API submission to MX acceptance, and bounce rate per provider — none of which Apple prefetching can distort. When a customer migrating from a marketing-oriented platform asks us to report opens on their OTP stream, we steer them to the numbers that actually predict a working login: median and p99 latency, provider-level acceptance, and the rate of duplicate sends suppressed by idempotency. The absence of the open-rate distraction is part of why transactional deserves its own pool, its own dashboard, and its own paging thresholds.
The SES economics that look cheap until you price the whole thing.
Amazon SES advertises ten cents per thousand messages, and on the headline number nothing beats it. The total cost shows up in the line items underneath. The free tier that used to cover sixty-two thousand messages a month was cut in 2023 to three thousand for the first year only, a dedicated IP is a separate monthly charge of around twenty-five dollars, the Virtual Deliverability Manager that gives you usable reputation insight is a paid add-on, and AWS data-transfer fees apply on top. None of that is the real cost, though. The real cost is operational: SES hands you a raw sending pipe and leaves IP warmup, DMARC report parsing, blocklist monitoring, and per-provider reputation management to your team, and the path to a human who understands email runs through Business Support pricing and is not built for the case where an OTP latency spike needs an answer in thirty minutes rather than thirty hours. Teams move to us when the engineering time spent operating SES, plus the add-ons, plus the cost of the launch where unwarmed IPs got throttled at Gmail, adds up past a managed plan that includes the warmup, the monitoring, and the on-call engineer in the base price. The crossover is rarely about the per-message rate. It is about who does the work.
How are OTP and payment confirmations handled?
A password reset that sends twice is an annoyance; a payment confirmation that sends twice can trigger a duplicate support escalation or a fraud flag, and an OTP that races a retry can lock a user out of their own login. Transactional flows are full of these exactly-once requirements, and the infrastructure has to treat them as first-class rather than assume the application handles deduplication. We accept an Idempotency-Key header on every send, and a duplicate call carrying the same key within a twenty-four-hour window returns the original response instead of dispatching a second message, which makes a retry after a timeout safe rather than dangerous. The webhook stream that reports delivery state carries the same key, so the application can reconcile what was actually sent against what it intended to send. For OTP specifically, the expiry window is part of the design: a code that takes three minutes to arrive because a tenant quarantined it is functionally expired before it lands, so we treat per-tenant OTP latency as a reputation problem to solve at the IP level rather than a delay to tolerate. The category rewards infrastructure that assumes the application will retry and is built to make retries harmless.
Where email is the wrong channel for the code, and we will say so.
Email is a strong default for transactional delivery, and it is not always the right channel for a one-time code. A login flow that demands the second factor inside a thirty-second countdown is fighting the inherent variability of email delivery to corporate mailboxes, where a tenant gateway can add two or three minutes regardless of how clean the sender is. For those flows, SMS, an authenticator app, or a push-based factor is the better primary channel, with email as the fallback rather than the front line. We are an email provider, so the SMS or RCS leg is not something we run, and we will name a specialized provider for it rather than pretend an email API solves a latency problem that belongs to a different medium. What we do well is the email side of a multi-factor design: the account-recovery link, the new-device notification, the confirmation that a factor was changed, and the OTP for flows where a few seconds of variance is acceptable. Drawing that line honestly in an evaluation tends to build more trust than claiming email answers every authentication-delivery question, because the buyer has usually already felt the corporate-inbox latency problem firsthand.
What we SLA, and what we are honest about not controlling.
A reliability claim is only useful if it is precise about its own boundary. We SLA the part of the path we control: the latency from API submission to hand-off at our MTA sits under two hundred milliseconds at p99, and the platform availability target is 99.99% with service credits of five percent per tenth of a percent below it. We deliberately do not put a sub-two-second guarantee on end-to-end delivery, because the last hop depends on the recipient mailbox, and a corporate Exchange server or a legacy on-premise gateway can respond slowly for reasons no sending platform can fix. What we measure and publish is the median, which sits around 1.4 seconds across major providers, and the p99 around 3 to 4 seconds, with the slow tail attributable to recipient infrastructure rather than ours. When an incident does hit the platform side, the incident commander pages affected customers within thirty minutes of detection, Performance and Enterprise accounts get a war-room invitation with our engineering, and a written root-cause analysis follows within forty-eight hours. The honesty about the boundary is the point: a vendor that puts an SLA on something it does not control is writing a check the recipient mailbox will bounce.
Suppression discipline for transactional is different from marketing.
Marketing sending leans on aggressive suppression — once an address bounces or complains, you stop, because the cost of sending again outweighs the value of the message. Transactional sending cannot be that blunt, because the message is one the user asked for and may urgently need. A hard bounce on a password-reset address still has to surface to the application so it can prompt the user to correct the address on file, rather than silently dropping the only path back into the account. We keep transactional suppression scoped tightly: hard bounces and explicit complaints suppress, transient deferrals retry on a backoff, and the webhook reports each outcome so the application decides what to do rather than the platform making an irreversible call on a message the user is waiting for. The discipline is narrower on purpose, because over-suppressing transactional mail locks people out of their own accounts.