--- title: "Amazon SES: What Application Teams Need to Operate | SendHQ" description: Understand Amazon SES identities, regions, APIs, quotas, events, suppressions, and the application controls a production email system still needs. canonical: https://sendhq.cc/guides/amazon-ses last-updated: 2026-08-24 --- # What is Amazon SES, and how does it affect application email? Amazon Simple Email Service, or Amazon SES, is AWS infrastructure for sending email through an API or SMTP interface and receiving email. For an application team, choosing SES means owning more than the send call: verified identities, regional configuration, IAM permissions, quota handling, message composition, event ingestion, bounce and complaint response, suppression, and operational monitoring. SES acceptance means AWS will attempt delivery; it does not prove inbox placement. Treat SES as a transport and feedback layer inside a larger application-email system. ## Understand the boundary of the service SES accepts application email through AWS APIs or an SMTP endpoint and can assemble a MIME message from structured fields or accept a message the sender assembled. That makes it infrastructure, not a complete product workflow. Your application still decides who may send, which tenant owns a domain, how templates and recipient data are handled, when retries are safe, and what users see after a request succeeds. A useful architecture separates three states. The application accepted a job, SES accepted a message, and a receiving mail server accepted or rejected the message. These states occur at different times and require different identifiers. Store your own immutable job ID beside the SES message identifier so webhook retries and support investigations can be reconciled without guessing from subject lines or recipient data. ## Verify identities before sending AWS defines a verified identity as a domain or email address used with SES. Before sending, the From, Source, Sender, or Return-Path identity must meet SES verification rules. Domain verification is usually the durable choice for an application because it can authorize addresses beneath that domain and supports domain-level authentication. Verification is not a one-time checkbox that can be copied across every deployment. Identity status and Easy DKIM setup are regional, so a domain verified in one AWS Region is not automatically ready in another. Build onboarding as a state machine: request the identity, show the exact DNS records, poll the authoritative provider status, and permit production sending only after the chosen Region reports success. Keep existing SPF and DMARC policy intact when DNS is shared with another sender, and never create a second SPF record for convenience. ## Make Region part of the email configuration SES resources and operating limits are regional. Verified identities, sandbox status, daily quota, maximum sending rate, Easy DKIM setup, suppression configuration, and feedback destinations can differ between Regions. A credential that is valid in AWS does not make an identity portable to another SES endpoint. Put the Region beside the provider account and identity in configuration, rather than hiding it in a generic environment default. For failover, prepare the secondary Region before an incident: verify the identity, publish its DKIM records, obtain production access and suitable quotas, configure event destinations, test message identifiers and webhook processing, and confirm that suppression behavior is understood. Switching only the endpoint during an outage can otherwise replace one incident with verification failures, throttling, or missing feedback. ## Choose API or SMTP deliberately AWS supports production sending through the SES API and SMTP interface. The API fits applications already using AWS authentication and SDKs, and it exposes structured and raw-message operations. SMTP fits software that already speaks SMTP, but SES SMTP credentials are distinct from ordinary AWS access keys and remain regional. The choice does not remove the need for queues, idempotency, timeout handling, or safe retry rules. If a connection fails before your application receives a response, the provider may still have accepted the message. Avoid blindly retrying a user-facing request with a new application identifier. Enqueue once, retain the provider response when available, and make workers retry a stable job. Use a raw-message operation only when you need exact MIME control, and validate headers and line lengths before handing the message to SES. ## Treat sandbox and quotas as runtime constraints New SES account-Region combinations can be in the sandbox. AWS currently documents sandbox limits of 200 recipient deliveries per 24 hours and one email per second, with sending restricted to verified recipients except for the mailbox simulator. Production quotas vary by account, Region, and approved use case. Quotas count recipients rather than API requests, so one request addressed to ten recipients consumes ten units. Read the actual quota for every active Region and design backpressure around both the rolling daily allowance and sending rate. A provider throttle should delay a queued job, not create duplicate sends or surface as an unexplained success. Request production access and realistic limits before launch, then load-test with controlled recipients. Do not describe the sandbox as a free tier, and do not assume approval in one Region applies to another. ## Build delivery state from events A successful SES send operation means the request was accepted and SES will attempt delivery. It does not mean the recipient opened the message, saw it in the inbox, or even that the receiving server accepted it. SES event publishing can report sends, deliveries, bounces, complaints, rejections, rendering failures, delays, subscriptions, opens, and clicks through configured AWS destinations. The operationally important distinction is that a delivery event represents acceptance by the recipient's mail server, while bounce and complaint events require policy responses. Ingest events idempotently because delivery systems can retry notifications. Preserve the provider message identifier and event time, reject malformed webhook payloads, and make state transitions monotonic where possible. Open and click observations are optional engagement signals with privacy and client limitations; they should not redefine whether transport delivery occurred. ## Handle bounces, complaints, and suppression Suppressing known bad or unwilling recipients protects both users and the sending account. AWS provides global, account-level, configuration-set-level, and newer tenant-level suppression behavior, but the exact scope depends on configuration and Region. Your application still needs a clear recipient policy. Permanently bounced addresses should stop receiving routine retries, complaints should trigger immediate suppression, and removal should require evidence that the address is valid and the recipient expects the mail. In a multi-tenant product, decide whether suppression is account-wide or isolated before onboarding customers, because shared suppression can cause one tenant's outcome to affect another tenant's send. Keep raw addresses out of general analytics and logs. Operational systems may need the address to enforce suppression, but dashboards and experiments should use aggregate or pseudonymous measures. ## Apply least privilege and isolate tenants IAM policies can restrict which SES operations a principal may call and can constrain From, recipient, or Return-Path addresses for sending actions. Sending authorization policies solve a different problem: they let an identity owner delegate use of a verified identity and can be revoked independently. For a single application, prefer a principal with only the send and monitoring actions the workload actually needs. Do not give a web browser AWS credentials. A multi-tenant email product also needs application-layer authorization because one shared SES account does not automatically understand your workspace model. Check that the authenticated tenant owns a verified From domain before submitting to SES, scope API keys and message records to that tenant, and make cross-tenant identifiers return no data. Provider IAM and application authorization are complementary controls, not substitutes. ## Use a production readiness checklist Before launch, record the AWS account, Region, identity ARN, verification status, DKIM status, sandbox state, daily quota, maximum send rate, event destination, suppression scope, and credential owner. Exercise a normal delivery, a mailbox-simulator bounce, a complaint test where supported, a throttle response, an event retry, and a provider timeout after submission. Confirm that queue workers do not duplicate a stable job, that a delivery event updates the correct message, and that a permanent bounce prevents another routine send. Set alarms for rejected requests, throttling, event-ingestion failures, bounce and complaint changes, and quota headroom. Review the configuration whenever a new Region, domain, tenant type, or message class is introduced. This checklist turns SES from a hidden dependency into an explicit subsystem with owners and observable failure modes. ## Decide where SendHQ fits Teams can integrate SES directly when they want AWS-native control and are prepared to build the surrounding application layer. SendHQ offers a narrower, workspace-scoped email contract with verified sending domains, scoped API keys, single and batch sends, inbound inboxes, delivery-event access, and suppression workflows. Its public API requires the From domain to belong to the workspace and be verified, and it records accepted messages for later inspection. That product layer does not replace SES identity, quota, reputation, or recipient-side filtering rules. Evaluate the two layers separately: the provider transports and reports on mail, while the application layer enforces tenant ownership, exposes stable resources, and presents operational state. Neither direct SES nor SendHQ establishes inbox placement, so assess both on controls, observability, ownership, and fit for your application's workflow. ## Frequently asked questions **Is Amazon SES an email API or an SMTP server?** It provides both an HTTPS API and an SMTP interface. Choose based on your application's authentication and message-composition needs, while keeping queues, stable job identifiers, event processing, and suppression outside the transport call. **Do I have to verify a domain to use Amazon SES?** You must verify each identity used as a From, Source, Sender, or Return-Path address. An email-address identity can work for limited cases, while domain verification is generally more practical for application-controlled addresses and DKIM. **Does an SES success response mean the email was delivered?** No. It means SES accepted the request and will attempt delivery. A later delivery event means the recipient's mail server accepted the message, and neither state proves that the message reached the inbox folder. **Are Amazon SES quotas shared across Regions?** No. AWS documents sending quotas, sandbox status, verified identities, DKIM setup, and suppression configuration as regional. Prepare and test every Region that can receive production traffic rather than switching endpoints during an incident. **What should an application store after sending through SES?** Store a stable application job ID, the SES message identifier when accepted, provider and Region, current state, timestamps, and normalized delivery events. Keep message content and recipient data out of broad logs and analytics. **When should a team use SendHQ instead of direct SES?** Use direct SES when the team wants to own AWS integration and all surrounding controls. Consider SendHQ when workspace-scoped keys, domain ownership checks, inbound inboxes, message resources, delivery events, and suppression workflows are useful application primitives. ## Sources - [Amazon Simple Email Service documentation](https://docs.aws.amazon.com/ses/) — Amazon Web Services - [Verified identities in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html) — Amazon Web Services - [Regions and Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/regions.html) — Amazon Web Services - [Using the Amazon SES API to send email](https://docs.aws.amazon.com/ses/latest/dg/send-email-api.html) — Amazon Web Services - [Service quotas in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/quotas.html) — Amazon Web Services - [Monitor email sending using Amazon SES event publishing](https://docs.aws.amazon.com/ses/latest/dg/monitor-using-event-publishing.html) — Amazon Web Services - [Managing lists and subscriptions in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/lists-and-subscriptions.html) — Amazon Web Services - [Identity and access management in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html) — Amazon Web Services - [SendHQ OpenAPI contract](https://sendhq.cc/openapi.json) — SendHQ ## Continue learning - [Amazon SES Cost: A Product Team Pricing Model](https://sendhq.cc/guides/amazon-ses-cost.md): Model Amazon SES cost across recipients, data, pricing plans, dedicated IPs, event infrastructure, quotas, and the engineering layer around delivery.