AWS SES Deliverability:
Lowest Cost, Highest Monitoring Responsibility

What Makes AWS SES Different

AWS SES (Simple Email Service) occupies a unique position in the ESP landscape. It's not an email marketing platform — it's email infrastructure. The distinction matters: where Klaviyo, Mailchimp, and Constant Contact give you list management, campaign builders, automation flows, and analytics, SES gives you an SMTP endpoint and an API. Everything else is your responsibility.

What SES provides:

• SMTP and HTTP API sending endpoints
• Bounce and complaint notifications via Amazon SNS (Simple Notification Service)
• Dedicated IP addresses at $24.95/IP/month
• Configurable sending rate limits
• CloudWatch metrics for delivery rates and bounce rates
• Email templates (basic, not visual)
• Virtual Deliverability Manager (paid add-on)

What SES does not provide:

• Email template visual editor or drag-and-drop builder
• Marketing automation or flow builder
• A/B testing for campaigns
• Audience segmentation tools
• Unsubscribe list management UI (you build and maintain this)
• Integrated analytics beyond delivery events
• Built-in inbox placement data (requires VDM add-on or third-party tool)

The pricing makes this trade-off worthwhile at scale: $0.10 per 1,000 emails when sending from an EC2 instance, or $0.12 per 1,000 emails otherwise. At 1 million sends per month, SES costs approximately $100-120. Comparable volume on Klaviyo would cost $3,000-5,000+.

SES Enforcement Thresholds (The Ones That Will Get You Paused)

AWS enforces sending reputation thresholds more aggressively than most managed ESPs. The consequences are also more severe: a threshold breach can result in your account being paused — meaning zero email sends until AWS manually reviews and reinstates you.

The figures below are from Amazon's sending review process FAQ, checked 26 September 2026. They are account-review rules, not Gmail's spam-rate rules. A separate SES page, reputation metrics messages, tells you to keep the bounce rate below 5% for best results, while the FAQ says below 2%. Both pages agree on what happens next: review at 5% or greater, and a possible pause at 10% or greater. Where the "best results" line disagrees, this page follows the FAQ for the review and pause actions and reports both recommendations.

Bounce Rate

The bounce rate in that FAQ counts hard bounces to domains you have not verified. Temporary failures, and bounces from a blocked IP, are excluded. AWS does not calculate it over a fixed number of days. It uses a representative volume that changes with how you send.

Complaint Rate

That complaint rate is the percentage of complaints on mail sent to domains that provide feedback to SES, again on a representative volume, not on every email and not on a calendar week. Gmail's guideline (stay under 0.10%, avoid 0.30%) is a different system. Crossing 0.1% in SES puts the AWS account under review. It is not the same event as Gmail filing mail in spam, and it is not, by itself, the pause line. The pause line AWS publishes for complaints is 0.5% or greater, and even then the FAQ says "might."

Why Account Pausing Is a Five-Alarm Event

When AWS pauses your SES account, further sending stops. If marketing campaigns and order or password mail share that account, both stop. The enforcement FAQ says AWS notifies the account email address and that you reply on the support case they opened. It does not publish a reinstatement time. Do not plan a launch around an assumed 24-hour restore.

The solution is proactive monitoring: watch your complaint rate and bounce rate continuously, not reactively. Google Postmaster Tools shows your Gmail spam rate in near-real-time. Yahoo Sender Hub shows Yahoo complaint rates. These signals often appear before AWS's own metrics cross a review line, which gives you a window to act.

When SES Sends the Store's Mail

A store that uses SES for receipts and a marketing tool for campaigns has two reputations and one unpleasant shared case: if both streams use the same SES account, a bad promotional import can pause the order email too. Split them on purpose.

• Separate identities. Verify the domain you actually put in the From header. DKIM must sign that domain if you want DMARC to align. A signature on an SES-owned domain does not align with store.com.
• Configuration sets. Put marketing and transactional traffic in different configuration sets so bounce and complaint events are not one undifferentiated log. The events are how you suppress. AWS says to remove hard bounces and complainers immediately, including by processing SNS notifications if volume is high.
• Account-level suppression. SES can keep its own suppression list for hard bounces and complaints. That protects the account rate. It also means a customer who opts in again stays blocked until you remove the address. Audit it. Do not assume your application database and the SES list match.
• A pause is an outage. Treat a review notice as the moment to stop the stream that caused it (usually a cold campaign), not as a reason to switch domains the same day. The first-24-hours recovery applies here, with one extra constraint: AWS may stop all sending on the account.

InboxEagle's SES integration reads identity health and delivery metrics from the account. It does not replace SNS processing, and it does not lift a pause. Authentication failures on SES mail have short paths at DKIM failing, SPF hard fail, and email not delivering. Moving a store onto SES, or off it, is an ESP migration, not a DNS toggle.

Getting Out of the SES Sandbox

Every new AWS SES account starts in the Sandbox environment. In Sandbox mode, you can only send email to verified email addresses — addresses that you've explicitly confirmed through the AWS console. You cannot send to any arbitrary recipient, which makes the Sandbox useless for real email programs. You need Production Access to send to unverified recipients at scale.

The Production Access Request

To exit the Sandbox, submit a Production Access request through the AWS SES console. AWS reviews these manually and publishes no turnaround time. Your request needs to include:

1. Your use case — Describe what you're sending (transactional notifications, marketing campaigns, etc.)
2. Expected daily send volume — Be accurate; understating volume and then exceeding it can raise flags
3. How you handle bounces — Explain that you've configured SNS notifications for bounce events and that you suppress bounced addresses immediately
4. How you handle complaints — Explain your complaint notification setup and suppression process
5. How subscribers opted in — Describe your list acquisition method

AWS approves the vast majority of legitimate business requests. Denials typically happen when the description is vague, when there's no clear suppression mechanism, or when the request appears to be for high-volume unsolicited email. If denied, address the specific feedback in your denial response and reapply.

Authentication and DNS Setup in SES

AWS SES requires domain verification before you can send from a domain, and DKIM setup is the primary authentication mechanism. Here's the complete authentication setup:

Domain Verification and DKIM

1. In the SES console, go to Configuration → Verified Identities → Create Identity
2. Choose Domain and enter your sending domain
3. SES generates 3 CNAME records for DKIM — add these to your DNS provider
4. SES automatically verifies the domain once DNS propagates (usually within an hour)
5. Optionally enable DKIM signing — this should always be enabled
6. Choose Easy DKIM (2048-bit RSA, recommended) or Bring Your Own DKIM

SPF Configuration

SES automatically handles SPF alignment through its sending infrastructure. You do not need to add a custom SPF record for SES — the MAIL FROM domain SES uses is configured to pass SPF checks by default. However, if you configure a custom MAIL FROM domain (optional but recommended), you'll need to add an MX record and SPF record for that subdomain. Use InboxEagle's SPF Record Generator to create the correct record.

DMARC

After setting up DKIM, publish a DMARC record for your sending domain. Use InboxEagle's DMARC Record Generator to create the TXT record. Add it to your DNS as a TXT record for _dmarc.yourdomain.com.

SNS Notifications for Bounces and Complaints (Critical)

Configuring SNS notifications for bounces and complaints is mandatory for SES at production scale. This is not optional — if you don't process bounce and complaint notifications programmatically, you will hit SES's enforcement thresholds.

1. In SES, go to your verified identity → Notifications
2. Set up SNS topics for bounces, complaints, and deliveries
3. Subscribe an HTTPS endpoint (your application server) or an SQS queue to the SNS topics
4. Process each notification to suppress bounced addresses and complaint senders from future sends
5. Remove those addresses from your own mailing list. SES can also add hard bounces and complaints to the account-level suppression list, which is not the same as updating your store's customer record. A later opt-in stays blocked in SES until you remove it there.

Virtual Deliverability Manager vs. What InboxEagle Adds

AWS introduced Virtual Deliverability Manager (VDM) as a paid add-on to SES in 2022. At $0.0001 per email processed, it provides some deliverability visibility that SES's base offering lacks. Understanding what VDM covers and where it falls short helps you plan your monitoring stack.

What Virtual Deliverability Manager Provides

• Inbox placement data — VDM uses a seed list approach similar to InboxEagle's seed list testing to estimate inbox placement rates across major ISPs
• Engagement dashboard — Open rates, click rates, and unsubscribe rates with ISP-level breakdown
• Deliverability advisor — Automated recommendations based on your sending patterns (authentication, list hygiene, etc.)
• Predictive insights — Machine learning-based predictions about deliverability changes

VDM Gaps That InboxEagle Fills

• Google Postmaster reputation data — VDM's inbox placement estimates don't include your Gmail domain reputation score or Gmail spam rate from Postmaster Tools. InboxEagle's Postmaster integration surfaces these directly.
• Yahoo and AOL placement — VDM doesn't test placement at Yahoo or AOL. InboxEagle's Yahoo and AOL seed mailboxes show where each send lands (it does not read Yahoo Sender Hub complaint data).
• DMARC record monitoring — VDM doesn't watch your DMARC DNS record. InboxEagle's DMARC monitoring checks it every 24 hours and alerts you on any change. Processing DMARC aggregate reports is a separate product, DMARC Processing.
• Bot click detection — VDM's engagement data includes bot clicks from security scanners. InboxEagle's Bot Finder separates automated clicks from human engagement.
• Blacklist monitoring — VDM doesn't monitor blacklist status for your sending IPs or domains. InboxEagle's blacklist checker does.

SES vs. Managed ESP: The Real Cost Comparison

The headline cost comparison between SES and managed ESPs is dramatic — but the total cost of operating an SES-based email program includes infrastructure and labor costs that need to be factored in.

Cost at 500,000 Emails per Month

SES wins significantly at high volume — but the developer cost line item is real. If you don't have engineering resources to implement bounce/complaint processing, build suppression management, and maintain the SNS pipeline, SES's operational complexity can cost more than the platform savings.

When SES Is the Right Choice

• You have engineering resources to implement bounce/complaint handling
• You send over 250,000 emails per month consistently
• You need maximum infrastructure control (custom IP pools, custom MAIL FROM)
• You're building a multi-tenant application where each customer has separate sending identity
• Your email program is primarily transactional or notification-driven

When a Managed ESP Is the Right Choice

• Your team doesn't have dedicated email engineering resources
• You need marketing automation, campaign builders, or segmentation tools
• You send under 100,000 emails per month (managed ESPs are cost-competitive here)
• The operational risk of an account pause is not acceptable for your business