Amazon SES at USD 0.10
per thousand.

SES looks cheap because the price-per-message is genuinely low. €0.10 per thousand at high volume is below every other provider in this category. The price-per-message is also not the variable that decides whether SES makes financial sense. The variable is engineer hours. SES is infrastructure, not a managed service. Senders who run SES in production spend somewhere between 10 and 40 hours per month on the operational layer that SES does not include — bounce processing, suppression list management, reputation monitoring, IP warmup, DKIM rotation, the dashboards and alerts that detect problems before they compound. The chart below maps actual TCO at 5 million monthly messages including engineer hours at fully loaded €120 per hour.

Three lines on the chart at 5 million messages per month workload. SES alone (raw infrastructure cost) sits at roughly €500 per month in send fees plus a few euros for SNS, S3, CloudWatch. SES with internal engineering effort included at the typical rate of 25 hours per month sits at roughly €3,500 monthly. Our equivalent at the Multi-IP tier sits at €949 per month all-in. The chart is uncomfortable for the SES side. The send-cost gap that looks like a 10x advantage for SES inverts to a 6x disadvantage once the labour is included. We do not draw this chart to be smug. The labour cost is real. We draw it because most senders evaluating SES for the first time miss the labour cost in their model and rebuild the budget at month four when the actual hours show up on a timesheet.

The honest framing is that SES wins for senders with engineering depth and time to invest in the operational layer, and we win for senders who would rather buy that layer pre-built. Companies like Netflix and Reddit run SES at huge scale because they have entire teams maintaining the bounce processing, suppression management, and reputation tooling around it. A growth-stage company with one engineer who is also responsible for half a dozen other systems does not have that depth. For them, SES looks cheaper on month one and is more expensive every month after. The decision is not about price. It is about which operational layer your team should be spending their hours on, and the answer to that question is rarely "the one our managed-service vendor would charge €949 per month to run for us."

Cold-start IP reputation on SES works differently than on managed providers and the difference matters more than most senders realise. SES allocates new IPs from a pool, and those IPs come with the aggregate reputation of every other SES customer who has ever sent from them. The default position is "shared reputation, mostly fine, occasionally surprising." For a high-volume sender that is acceptable. For a sender at 100k-500k volume with brand sensitivity it is a problem. The shared IP can have its reputation degraded by another customer who got aggressive with their list and the receiver does not separate per-customer reputation cleanly within shared IP space.

The numbers we have measured. New SES IPs in the EU-Frankfurt region show median Microsoft SmartScreen rating of 78 percent at start, against the 95 percent rating typical of a properly warmed dedicated IP. Gmail engagement classifier weights the new IP somewhere in the middle 60s for the first three weeks. Yahoo is harshest — new SES IPs in EU-Frankfurt routinely hit Yahoo deferral rates of 8 to 12 percent in the first 14 days, against the 1 to 2 percent typical of a managed warmup. The recovery happens. SES IPs reach steady-state reputation within 4 to 6 weeks of consistent sending. The cost is the lost placement during those 4 to 6 weeks. For a sender doing 200,000 monthly messages at 70 percent placement instead of 95 percent, the gap translates to roughly 50,000 messages going to spam during the warmup window. That is the part the price page does not show.

SES does offer dedicated IPs as an upgrade. The cost is €25 per IP per month plus the standard send fees, which is genuinely good value. The catch is that the dedicated IP comes from AWS's pool with no warmup history of its own, and the warmup is the customer's responsibility. SES provides automated warmup tooling that ramps the IP slowly over the first month, but the tooling does not have feedback loops the way a hand-managed warmup does — it sends to a fixed schedule regardless of whether the receivers are pushing back. We have audited senders who used SES dedicated IPs with the automated warmup, hit a Yahoo wall on day 11, and the SES tooling kept ramping the volume because it has no signal that something went wrong. The dedicated IP option fixes the shared-reputation problem. It does not fix the lack of operational feedback.

The application change is small. SES exposes both an SMTP endpoint and an HTTP API; both have direct equivalents on our side. For SES SDK users, the AWS SDK calls have to be replaced with HTTP requests — there is no compatibility shim because the AWS SDK is bound to AWS-specific signing logic. The replacement is usually trivial (10-50 lines of code per send-path) but it is more work than the SendGrid or Mailgun cutover.

The reputation transfer follows the standard pattern. Your domain reputation goes with you; the SES IP-level reputation does not. The new dedicated IPs warm on a 4-6 week curve. SES-specific note: if you were using SES Managed dedicated IPs (the auto-warmed tier), your IPs were never named to your DNS — they were SES's IPs, with their reputation. The warmup on our new IPs starts cleaner than from a SES-Standard configuration, but it still needs the full ramp.

The suppression list transfer requires SES API access. SES's account-level suppression list and per-configuration-set suppression are both pullable through the API; we extract both lists, deduplicate the union, and load the deduped set into our infrastructure before traffic flows. SES bounce and complaint events flowing through SNS for the last 90 days get pulled and reconciled — anyone who hard-bounced or complained on SES gets added to our suppression even if they were not in the SES suppression list (sometimes they were not, depending on how you configured the auto-suppression).

The traffic cutover is the standard 10%-increment parallel run with daily per-domain placement monitoring. The SES-specific risk we watch for is the SES sending quota reset behaviour — if you cut over too aggressively and your SES account goes to zero traffic for 30+ days, the SES sending quota resets and re-warming SES later would be expensive. Most clients keep a thin layer of low-volume traffic on SES through the migration window in case rollback is needed; we coordinate that with you explicitly.

The honest framing of SES is that it is not an email service. It is an infrastructure component. You wire it into an email service you build yourself. The list below is what a production-grade email delivery operation requires beyond what SES ships out of the box, the things every sender at scale ends up building or buying separately and rarely accounts for in their first SES budget projection. Some items are AWS services you can compose into a workable equivalent. Some are external tools. Some are internal engineering effort that does not exist as a product anywhere on the market. All of them are line items that show up on your team's roadmap whether you anticipate them or not. Often at the worst time. The buyers who build their TCO model from this list arrive at the comparison with us already done.

Eighteen items above. Some take a week to wire up. Some take quarters of engineering effort, particularly the reputation tooling and the suppression list infrastructure that nobody warns you about until you are already running at 5 million messages per month and the bounce rate starts mattering for real. The total accumulates to the engineer-hour cost in section 01b — that is where the 25 hours per month estimate comes from, distributed across these tasks at the cadence each one demands. We are not arguing that SES is wrong. We are arguing that SES is wrong if you do not have the team to build everything above it. For senders who have that team, SES wins. For senders who do not, the math is what we showed in the chart. None of this is hidden. It is rarely surfaced in the comparison conversation, and when we do surface it the buyer has already half-decided.