What Is Amazon SES & Why It Keeps Your Emails Out of Spam

If you’re a small business, freelancer, or agency, you probably don’t actually care about Amazon SES as a brand, but you surely care about one thing:

“Do my emails land in the inbox, and can I trust the infrastructure behind them?”

Amazon Simple Email Service (SES) is one of the cheapest and most powerful email-delivery engines on the market, but it’s often misunderstood. Used correctly, it gives you enterprise-grade deliverability, encryption, and compliance at commodity pricing. Used casually, it will happily deliver your emails into spam, or get your domain throttled.

This article goes deeper into what SES really does, how it works with other reputation providers, how it compares to alternatives, and why we build Greenmor Mail on SES even though there are cheaper ways to move raw SMTP packets from A to B.


Amazon SES is a cloud-based email delivery service that lets you send and receive emails using your own domains via SMTP or API. It’s infrastructure, not a client.

In practical terms:

  • You plug SES into your app, CRM, or website.
  • SES signs and transmits your email using its infrastructure and IP space.
  • Mailbox providers (Gmail, Outlook, etc.) then decide whether to place your message in inbox, promotions, or spam.

Key capabilities that matter to a small business:

  • Support for SPF, DKIM, and DMARC so your emails are properly authenticated.
  • Feedback on bounces, complaints, and delivery, so you can see when something is off.
  • Scalable sending limits that can grow from a few hundred emails per day to very high daily volumes with approvals.

Amazon SES constantly evaluates what you send, how recipients react, and how its IPs and domains are perceived across the wider email ecosystem. The goal is simple: keep abusive senders out so legitimate senders have a better chance of inbox placement.

Reputation is essentially a confidence score that your IPs and domains are not sources of spam or abuse. To manage this, AWS SES:

  • Tracks bounce rate and marks accounts unhealthy when this creeps up.
  • Tracks complaint rate (people hitting “Report spam”) and treats this as a critical signal.
  • Detects sending to spam-trap addresses and other abuse patterns.​

You can see this in the Reputation metrics page inside AWS SES, which surfaces:

  • 24-hour sending volume and remaining quota.
  • Current bounce and complaint rates.
  • Notifications when SES detects spam-trap hits or content patterns associated with unsolicited mail.

AWS SES applies concrete thresholds and takes automated action when you cross them. While AWS doesn’t publish a single global “kill switch” number for every case, public docs and community experience suggest:

  • Complaint rate
    • Healthy: below roughly 0.1% (1 spam complaint per 1,000 emails).​
    • Under review / at risk: consistently above that, especially if it approaches or exceeds 1% on representative volumes.
  • Bounce rate
    • AWS SES expects you to keep hard bounces low; repeatedly sending to invalid addresses is taken as a sign of poor list hygiene or abuse.

When these metrics degrade, AWS SES can:

  • Throttle your sending by effectively reducing the practical send rate or keeping you from raising quotas.
  • Place the account under review, requiring remediation before sending volume can grow.
  • In serious or persistent cases, suspend sending for a domain, a dedicated IP, or the entire account, especially when patterns look like spam rather than mistakes.

The net effect: AWS SES actively forces high-risk senders to slow down, clean lists, or leave the platform, which protects the broader IP pool.

By default, new AWS SES customers send over shared IP pools. These are continuously curated based on ongoing sender behavior: good senders benefit from the pool; bad senders are pushed out or constrained.​

For higher-volume or more sensitive use cases, AWS SES offers dedicated IPs and managed warm-up:

  • Dedicated IPs let you own your IP reputation instead of sharing it.​
  • AWS SES’ warm-up logic gradually ramps mail per ISP (Gmail, Outlook, etc.) so that providers don’t see sudden spikes, which are a classic spam signal.​

If a dedicated IP starts seeing poor engagement, high bounces, or complaints, SES can flag that IP and require corrective action before you keep scaling, again to prevent a single customer from poisoning a large slice of its address space.

On top of internal metrics, SES uses external reputation providers to validate that its own view of “good” and “bad” matches how the rest of the ecosystem sees its IPs and domains.​

Spamhaus is one of those providers. AWS SES has worked with Spamhaus for years to:

  • Cross-check SES IPs and domains against Spamhaus’ IP and domain reputation datasets.
  • Detect and remediate suspicious ranges or customers before they impact inboxing for everyone.

You don’t have to care about the specifics of Spamhaus; what matters is that SES isn’t judging reputation in a vacuum. It combines internal telemetry (bounces, complaints, spam-traps) with third-party intelligence to keep its IP ranges as clean as possible.


If you’re building on any cloud provider, you need an honest view of how your data is handled. With SES, there are three main layers to keep in mind.

SES supports TLS for SMTP and for delivering email to recipient mail servers:

  • When you connect to SES via SMTP or API, you can use TLS to encrypt the channel.
  • When SES hands off mail to another mail server, it uses opportunistic TLS by default and can be configured not to deliver if TLS is unavailable, in some scenarios.​

This means your email content is encrypted while moving between systems that support TLS, but not end-to-end encrypted like PGP.

Within AWS, SES can store message data and logs in other AWS services (like S3 or CloudWatch) that support encryption at rest using AWS-managed or customer-managed keys.​

You can also choose which AWS regions to use, which helps align with data residency policies (for example, keeping data within the EU for GDPR-sensitive workloads).

AWS lists SES as a HIPAA-eligible service and supports signing Business Associate Agreements (BAAs) for covered entities.

Two important caveats:

  • AWS provides the tools (TLS, encryption, logging, BAAs), but you are responsible for configuring them correctly and ensuring your specific use case complies with GDPR, HIPAA, or other regulations.
  • For highly sensitive content (e.g., medical data), many experts recommend layering additional encryption rather than relying solely on AWS SES’ transport-level protections.

From a small-business perspective: AWS SES is more than good enough for typical business email and transactional messages if you’re not handling regulated health or financial data, provided you follow basic security hygiene.


Founders usually compare SES against three buckets of alternatives:

  1. API-first email providers (SendGrid, Mailgun, Postmark, ZeptoMail, etc.).
  2. Full marketing/email platforms (Brevo, Mailchimp Transactional, etc.).
  3. Rolling your own SMTP or IPs (self-hosted mail servers, VPS providers, etc.).

Below is a high-level, directional table (pricing is simplified and can change, always check current docs):

Provider / optionTypical use caseIndicative pricing at low volumeStrengthsDownsides for small teams
Amazon SESTransactional + bulk via API/SMTPRoughly $0.10 per 1,000 emails beyond free tier ​Very cheap, highly scalable, strong infra Requires technical setup and monitoring ​
SendGridAPI + marketing platformEntry plans usually start at bundled monthly tiers Rich marketing tools, mature ecosystem More expensive per email than SES, more bloat if you only need delivery 
MailgunDeveloper-centric sendingPaid plans with buckets of monthly emails Good logs, analytics, developer UX Costs ramp faster than SES for pure volume ​
PostmarkHigh-reliability transactional emailFixed packages (e.g., small bundles per month) Excellent deliverability focus, great support ​Higher price per email vs SES if you send a lot 
Brevo / Mailchimp TransactionalCampaigns + transactional add-onsTiered per contact or per email Strong marketing UI and analytics ​Overkill if you only need SMTP/API and business mailboxes ​
Roll your own SMTP / IPsSelf-hosted or VPS-based mail serverServer cost + your time Maximum control, no per-email feeHard to keep clean IP reputation, high maintenance, easy to get blocked

A common pattern we see:

  • Teams that only care about email delivery cost often gravitate toward SES or self-hosting.
  • Teams that want marketing features, templates, journeys, and analytics gravitate toward SendGrid, Mailchimp, or similar, even if they pay more per email.

If there are even cheaper ways to send email (such as with own IPs), why would a service like Greenmor Mail build on AWS SES?

Two reasons: reliability and focus.

Greenmor Mail is positioned as white-label business email, not as a low-end SMTP relay. Using Amazon SES as our sending backend means:

  • We inherit AWS’ global infrastructure, IP reputation, and deliverability tooling instead of reinventing it.
  • We can focus on mailbox UX, domain setup, smart sending limits, and routing decisions rather than managing MTA clusters and blocklist negotiations.

This is why our own product pages describe Greenmor Mail as “powered by Amazon SES” for premium delivery and reliability.

Could we find or build something cheaper than SES on a pure “cost per 1,000 emails” basis? Yes, but in practice, this comes with trade offs:

  • Higher risk of IP blacklisting.
  • More time spent firefighting deliverability and abuse.
  • Less leverage with mailbox providers and anti-abuse orgs.

Greenmor Mail’s thesis is that small businesses don’t want the cheapest possible SMTP, they want stable, boring business email that doesn’t surprise them. AWS SES gives us that stability, and we add:

  • Simple, transparent pricing (e.g., around 1/5th of the big suites).
  • Opinionated per-mailbox sending limits to protect domain reputation.
  • Robust, yet super-simple domain setup and migration.
  • User-centric webmail features and UI/UX.

Across small businesses, agencies, and bootstrapped products, two prominent patterns show up with AWS SES use:

  • Transactional mail thrives, marketing mail struggles.
    Receipts, order updates, and password resets tend to have high engagement and clear intent, so they perform well when properly authenticated.
    Cold outreach, bulk announcements to stale lists, and spray and pray campaigns are the first to get filtered.
  • Misconfigured domains cause silent pain.
    SPF records that include multiple vendors incorrectly, missing or misaligned DKIM selectors, and absent DMARC policies regularly undermine deliverability.

When Greenmor Mail integrates SES on behalf of customers, we deliberately keep daily per-mailbox limits conservative and nudge senders toward permission-based, clean lists. This protects the shared reputation and, more importantly, the customer’s own domain long-term.

Amazon SES is just one piece of a professional-email stack, not the whole strategy. On its own, it won’t tell you how to structure domains, separate transactional from marketing traffic, or decide whether you’re better off with a managed mailbox service versus DIY infrastructure. That’s the gap this article is meant to fill: give you a clear, technical understanding of what SES is good at, where it needs help, and how it behaves from a deliverability and reputation perspective.

From here, the natural next step is a broader guide that ties everything together (domain setup, DNS and authentication, cost trade-offs, and when to use a service like Greenmor Mail on top of SES), so you can design an email setup that’s boringly reliable, affordable, and fit for how your business actually sends email.