Amazon SES Review: What You Own When You Run It

Amazon SES is excellent at the job it defines for itself and silent about everything outside that boundary. It will authenticate your identities, accept your messages, publish your reputation metrics and hold your suppression list. It will not schedule a campaign, show a non-technical colleague what was sent, retain your event history, or tell anyone when a metric starts moving. Whether SES is the right sending layer comes down to whether your organisation has a named person who will supply the rest, and that question belongs in the review long before the rate card does.

Start with the sandbox, because everything else waits on it

Every new SES account begins restricted. The production access documentation states that a sandboxed account can send only to verified email addresses and domains or to the SES mailbox simulator, with a maximum of 200 messages per 24 hour period and a maximum of 1 message per second. Bulk actions and API calls for account-level suppression management are disabled while sandboxed.

AWS states that the Support team provides an initial response to a production access request within 24 hours, and that additional information may extend the timeline. The request asks you to classify your mail as marketing or transactional, supply a website URL, and acknowledge that you send only to people who explicitly requested it and that you have a process for handling bounce and complaint notifications.

The documentation is direct that sandbox status is unique per AWS Region. A team that later adds a second region for latency or data residency repeats the exercise there.

Our view: the acknowledgement checkbox is the part of the review that matters commercially. It is a written statement about your list practice, made by your organisation, attached to the account. Decide whether it is true before you tick it, because it is the document AWS will reference if the account is later reviewed.

Identity setup is the part SES does well

Verifying a domain and publishing DKIM records is straightforward, and SES handles the mechanics cleanly. Verify the domain rather than individual addresses wherever possible, because domain verification is what lets you send from any address on it and what carries reputation forward if you change platforms later.

Confirm all three authentication layers before production sending. SPF must include the SES sending infrastructure, DKIM must be published and verified, and DMARC must be aligned with the domain in the visible From header. Alignment is the requirement that trips teams up, since a message can pass DKIM and still fail DMARC if the signing domain does not align.

Configuration sets are the control worth setting up on day one. The configuration sets documentation covers how they group sending rules and publish events. Without them, event data goes nowhere and the reputation picture stays at account level, which is too coarse to isolate a problem to a single campaign or domain.

Suppression works, and it needs a policy above it

SES provides an account-level suppression list that holds addresses which have bounced or complained, and it can be enabled at the configuration-set level as well. Addresses can be added individually or in bulk, viewed, and removed.

The mechanism is sound. What SES does not supply is the policy that decides what belongs on the list, who may remove an entry, and how a suppression captured in one system reaches another. An unsubscribe recorded in your CRM is an obligation whether or not it reached SES, and nothing in the platform will reconcile the two for you.

Build the suppression record outside SES and push to it, rather than treating the SES list as the source of truth. That arrangement survives a platform change and keeps the obligation in a system your organisation controls.

Watch the reputation metrics yourself

SES publishes bounce and complaint rates through its reputation metrics and states the thresholds that trigger action. The reputation metrics messages documentation is explicit: AWS advises maintaining a bounce rate below 5 percent, automatically places an account under review at 5 percent or greater, and may pause sending at 10 percent or greater. For complaints, it advises staying below 0.1 percent, places an account under review at 0.1 percent or greater, and may pause sending at 0.5 percent or greater.

Those are account-level consequences, which is the detail that changes how SES should be operated. A single careless import can put every program on the account under review, so the isolation that configuration sets provide is a risk control rather than a reporting nicety.

The metrics are visible in the console. Nobody is watching them on your behalf. Set a CloudWatch alarm against the bounce and complaint rate, route it to a human with authority to pause a campaign, and document what that person is expected to do when it fires. Our Amazon SES deliverability guide sets out the runbook in full.

The console is not a product for your colleagues

The SES console is an operations surface for a technical user. There is no campaign builder, no scheduling interface, no template library a marketer would recognise, and no view that answers what was sent to a named person last month.

Everything a non-technical colleague needs has to be built. That build is legitimate work with a maintenance obligation, and the decisive question is whether it has an owner who will still be in the role in eighteen months. A sending stack understood by exactly one person is a business risk that appears nowhere on the AWS bill.

Event history has the same shape. SES publishes events through configuration sets, and where those events land is your decision. If nobody has built the destination, the delivery evidence does not exist.

Score the review against your own capacity

SES earns a strong recommendation for teams with engineering capacity, a named technical owner and volume high enough that the per-message saving is material. For teams without that owner, a managed platform is the cheaper option once the missing layer is priced at what it actually costs.

LeadHaste orchestrates 35+ tools for client programs and selects the sending layer against the team that has to operate it. Our outbound lead generation services explain how domains, mailboxes and sending infrastructure are built so the client owns each piece.

Approve SES with the owner named

Amazon SES is a capable, well documented sending layer with a clearly drawn boundary. The review passes when you can name the person who owns everything outside that boundary, point at the alarms that watch the reputation metrics, and show where the event history lands.

LeadHaste can run the acceptance sequence with you, from sandbox exit and identity setup through configuration sets, suppression policy and the monitoring that has to sit on top. Book your free ICP and campaign-fit discovery call →