DEV Community

Nilesh M
Nilesh M

Posted on

Using AWS SES for Cold Email: What Breaks and How to Actually Make It Work

Every founder who has looked at their email tool bill has had the same thought.

Wait, I can send through Amazon SES for ten cents per thousand emails? Why am I paying $99 a month for a sequencing tool?

The math is real. SES is the cheapest sending option out there. If you're a founder watching every dollar, an agency running email for a dozen clients, or an SDR team trying to scale outreach without scaling the budget, SES looks like the obvious move.

Then you try to set it up, and you hit a wall.

What nobody tells you before you start

Amazon built SES for developers sending transactional email. Order confirmations. Password resets. Receipts. It was never meant for a founder or a sales team who wants to send outreach and get replies.

That mismatch shows up fast.

To send your first cold email through raw SES, you file a request to exit the sandbox and wait for approval that isn't guaranteed. You create access credentials with the right permissions. You set up a system to catch bounces and complaints, because if you don't track those, AWS pauses your account the moment your numbers climb. You configure your own authentication records. And you build some way to actually see what's happening, because SES gives you raw metrics and nothing that looks like a campaign dashboard.

None of that has anything to do with writing a good email or booking a meeting. It's plumbing. And most founders, SDRs, and agency owners are not plumbers.

The part that actually hurts

Here's the failure that catches people off guard.

The risk with SES isn't whether it can send your email. It can. The risk is what happens after you send.

Cold outreach naturally produces some bounces and some complaints. That's normal. But AWS watches those numbers closely, and if your complaint rate crosses a threshold, they can pause your entire account with little warning. Your pipeline goes silent. The campaign you spent a week building stops mid-send. And because raw SES gives you almost no early warning, you often find out only after the damage is done.

This is the quiet reason so many teams try SES, get burned once, and go back to paying for a tool that shields them from all of it.

The frustrating part is that the shield isn't complicated. You need warmup running so your sending reputation stays healthy. You need a check before each campaign that catches problems before they go out. You need bounce and complaint handling that runs automatically instead of something you build by hand. That's it. Raw SES gives you none of it, which is why almost everyone ends up putting a layer on top.

But isn't SES worse for deliverability than Gmail?

This is where people get confused, so it's worth clearing up.

On day one, yes, Gmail is easier. Google lends you some of its own sending reputation, so a fresh Gmail account can start landing in inboxes faster than a fresh SES setup. SES starts your reputation from zero, which means a real warmup period before you send at volume.

But that early convenience has a catch. On Gmail, the reputation underneath is Google's, not yours. If Google has an infrastructure problem affecting your account, you have no visibility and no recourse. You're also boxed in by Gmail's sending limits, which sit well below what serious outbound needs. On SES, once you build the reputation, it belongs entirely to your account and no other sender can touch it, and your volume ceiling is whatever AWS approves.

The honest rule of thumb: Gmail or Outlook to test and get started, SES for owned, isolated infrastructure once you're serious about volume.

What actually keeps you in the inbox

Strip away the tooling debate and the fundamentals are identical no matter what you send through. These decide whether your cold email lands, and most deliverability disasters trace back to one of them quietly breaking.

Authentication that actually passes, checked before every send. Your sender authentication is not set-and-forget. DNS records change and expire, and a record that verified three months ago can break with no warning. Confirm it before a real campaign, not once at setup.

A policy that enforces, not just monitors. A huge number of senders configure DMARC in monitoring mode, see no errors, and assume they're protected. Monitoring mode watches and does nothing. Filters can tell the difference between a domain that enforces and one that's just observing, and they treat them differently.

Content scanned before it goes out. Spam trigger words, too many links, a bad text-to-image ratio. Filters score all of this before a human ever opens the email. Catching it before a 2,000-contact send costs nothing. Catching it after costs you the whole list.

Blacklist status checked close to send time. A clean domain can get listed overnight. Checking once when you set up and never again is how teams get blindsided mid-campaign.

Bounce and complaint rates watched per campaign. The 90-day average looks fine right up until it doesn't. The rate on your most recent send is the one that predicts trouble, and on SES specifically it's the number that gets your account paused.

Warmup that runs continuously, not just at launch. Reputation isn't built once. Background warmup between active campaigns keeps your sending history healthy during the quiet gaps.

Follow-ups that stop the instant someone replies. Sending a scheduled follow-up to a person who already responded is one of the fastest ways to earn a spam complaint. If your sequencing doesn't pause automatically on reply, that's a risk hiding inside your own automation.

The setup most teams actually land on

After the burned-once cycle, most founders and agencies arrive at the same conclusion. They don't want raw SES, and they don't want a $99 tool that hides the fact they're overpaying to send. They want the cheap SES rate with the guardrails already handled.

That means connecting your own SES account, then letting a layer on top handle the authentication setup, the warmup, the bounce and complaint processing, and the pre-send checks. You pay AWS directly for what you send, and a flat predictable rate for the software that keeps you out of trouble. A handful of tools now do exactly this. EmailQo is one built specifically around connecting your own AWS SES account for cold email, which is worth a look if you want the ten-cents-per-thousand economics without becoming your own deliverability engineer.

The reason this shape wins for the people reading this is simple. A founder gets SES economics without needing an engineer. An agency runs each client on isolated, owned infrastructure instead of a shared pool where one bad client tanks everyone. An SDR team sends at volume without one paused account killing the quarter.

The takeaway

SES being cheap was never the hard part. Ten cents per thousand emails is real, and for founders, agencies, and outbound teams it's a genuinely good deal on paper.

The hard part is everything around the sending. The setup that has nothing to do with your actual job. The account pause that hits without warning. The reputation you have to build and then protect. Whether you run raw SES, put a tool on top, or stay on Gmail and Outlook for now, the checklist above is what keeps you in the inbox.

Sort that out first. Then the cheap sending rate finally starts to mean something.

Top comments (0)