Building Email Outreach on AWS SES: The Hidden Engineering Scope

What SES actually gives you

AWS SES is bait for indie hackers. A fraction of a cent per email, AWS-grade uptime, no per-seat licensing-it looks like the perfect cold-email infrastructure. Then you ship your first campaign and realize SES is a sending pipe, not an outreach system. Everything the product doesn't do has to live in your code.

SES is a transactional mail service that also handles bulk volume. You get:

• SMTP + REST API sending
• SPF/DKIM/MAIL FROM authentication
• SNS webhooks for delivery events (bounces, complaints, opens)
• Shared IP pools (cheap) or dedicated IPs (isolates your reputation)

What you don't get: contact management, sequences, bounce suppression, reply detection, domain warmup, unsubscribe handling, or any logic that treats message #5000 differently from message #1.

The reputation trap

AWS protects its shared IP pools aggressively. Two metrics kill accounts:

• Bounce rate - stay under ~5% sustained or face account review
• Complaint rate - one spam flag per thousand messages (0.1%) puts you on thin ice

For transactional mail (receipts, password resets) those thresholds are laughably easy. For cold outreach they're knife-edge tight. A B2B email list with normal decay bounces 10-20% unverified. One angry prospect hitting "spam" scales across hundreds of sends. You're gambling with your AWS account on every campaign.

Dedicated IPs exist to solve this-your reputation is yours alone-but now you own the warmup burden: you need steady volume to build IP history, and a cold drip of 30 emails/day never builds meaningful reputation.

The engineering bill

Before your first cold campaign, budget for:

• Bounce & complaint handling - SES pushes events via SNS; you must consume those webhooks, classify bounce types (hard vs. soft), and write results to a suppression store. Every send checks that store before firing. This is non-negotiable; miss it and your bounce rate compounds until AWS pauses the account.
• Reply capture - SES is send-only. Handling replies requires either SES Receiving (SNS/S3/Lambda routing), or syncing an external inbox via IMAP. Then build reply classification, out-of-office detection, and sequence-stop-on-reply logic. Cold outreach without replies is just noise; replies are the data you're optimizing for.
• Warmup & pacing - gradual daily volume growth, per-domain send intervals, randomized timing to avoid detection patterns. This is a scheduler you live with.
• Compliance layer - one-click unsubscribe headers (Gmail/Yahoo now expect these from bulk senders), same-day opt-out processing, GDPR/CAN-SPAM audit trails.
• Monitoring dashboard - bounce, complaint, reply rates per campaign, per domain. Without visibility, you're blind to decay until AWS warns you.

That's not a weekend project. It's several weeks of engineering plus permanent ops overhead.

When SES makes sense

SES is the right choice if you're building that entire stack as the product - a small outreach platform where email sending is one subsystem under a larger campaign engine. It scales cheaply and stays under your control.

SES is the wrong choice if you're a founder trying to run one cold campaign, or an indie hacker who just needs to reach 500 prospects responsibly. The time-to-campaign is months, not weeks. You'll spend more hours on bounce processing and reply routing than on message copy.

Pull that apart: the engineering is real. The DIY path works, but only if you're willing to treat email infrastructure as a multi-week build, monitor it forever, and accept the risk that AWS can pause your account with little notice if metrics drift.

Full breakdown with sample funnel and selection parameters in the original: Amazon SES for Cold Email: Cheap Sending, Missing Pieces .

AWS SES is bait for indie hackers. A fraction of a cent per email, AWS-grade uptime, no per-seat licensing-it looks like the perfect cold-email infrastructure. Then you ship your first campaign and realize SES is a sending pipe, not an outreach system. Everything the product doesn't do has to live in your code.

SES is a transactional mail service that also handles bulk volume. You get:

• SMTP + REST API sending
• SPF/DKIM/MAIL FROM authentication
• SNS webhooks for delivery events (bounces, complaints, opens)
• Shared IP pools (cheap) or dedicated IPs (isolates your reputation)

What you don't get: contact management, sequences, bounce suppression, reply detection, domain warmup, unsubscribe handling, or any logic that treats message #5000 differently from message #1.

The reputation trap

AWS protects its shared IP pools aggressively. Two metrics kill accounts:

• Bounce rate - stay under ~5% sustained or face account review
• Complaint rate - one spam flag per thousand messages (0.1%) puts you on thin ice

For transactional mail (receipts, password resets) those thresholds are laughably easy. For cold outreach they're knife-edge tight. A B2B email list with normal decay bounces 10-20% unverified. One angry prospect hitting "spam" scales across hundreds of sends. You're gambling with your AWS account on every campaign.

Dedicated IPs exist to solve this-your reputation is yours alone-but now you own the warmup burden: you need steady volume to build IP history, and a cold drip of 30 emails/day never builds meaningful reputation.

The engineering bill

Before your first cold campaign, budget for:

• Bounce & complaint handling - SES pushes events via SNS; you must consume those webhooks, classify bounce types (hard vs. soft), and write results to a suppression store. Every send checks that store before firing. This is non-negotiable; miss it and your bounce rate compounds until AWS pauses the account.
• Reply capture - SES is send-only. Handling replies requires either SES Receiving (SNS/S3/Lambda routing), or syncing an external inbox via IMAP. Then build reply classification, out-of-office detection, and sequence-stop-on-reply logic. Cold outreach without replies is just noise; replies are the data you're optimizing for.
• Warmup & pacing - gradual daily volume growth, per-domain send intervals, randomized timing to avoid detection patterns. This is a scheduler you live with.
• Compliance layer - one-click unsubscribe headers (Gmail/Yahoo now expect these from bulk senders), same-day opt-out processing, GDPR/CAN-SPAM audit trails.
• Monitoring dashboard - bounce, complaint, reply rates per campaign, per domain. Without visibility, you're blind to decay until AWS warns you.

That's not a weekend project. It's several weeks of engineering plus permanent ops overhead.

When SES makes sense

SES is the right choice if you're building that entire stack as the product - a small outreach platform where email sending is one subsystem under a larger campaign engine. It scales cheaply and stays under your control.

SES is the wrong choice if you're a founder trying to run one cold campaign, or an indie hacker who just needs to reach 500 prospects responsibly. The time-to-campaign is months, not weeks. You'll spend more hours on bounce processing and reply routing than on message copy.

Pull that apart: the engineering is real. The DIY path works, but only if you're willing to treat email infrastructure as a multi-week build, monitor it forever, and accept the risk that AWS can pause your account with little notice if metrics drift.

Full breakdown with sample funnel and selection parameters in the original: Amazon SES for Cold Email: Cheap Sending, Missing Pieces .

Top comments (0)