Cloud / Amazon Simple Email Service (Amazon SES) Interview questions

Amazon Simple Email Service (Amazon SES) is a managed, cloud-based email platform from AWS that lets applications send and receive email at scale without running mail servers. It's built on the same sending infrastructure Amazon uses for its own customer communications.

Developers reach it through three main paths: the SES API (v1 or v2), an SMTP interface for existing mail libraries, and the AWS SDKs, so it fits both new cloud-native apps and legacy systems that only speak SMTP.

It's commonly used for transactional mail (password resets, receipts, OTPs), marketing and bulk campaigns, and inbound mail processing through Mail Manager, with pay-as-you-go pricing and no servers to patch or scale.

Amazon SES is used anywhere an application needs to send or process email programmatically rather than through a human-operated mailbox.

• Transactional email: order confirmations, password resets, one-time passcodes, shipping updates.
• Marketing and bulk email: newsletters, promotions, and product announcements sent to opted-in lists.
• System and application alerts: monitoring notifications, invoice delivery, account activity summaries.
• Inbound email processing: parsing support replies, ticket creation, or automated auto-responders through Mail Manager.
• Embedded sending for SaaS platforms: letting a multi-tenant product send email on behalf of its own customers.

Because pricing is per email rather than per seat, it scales cleanly from a handful of emails a day to hundreds of millions a month.

A verified identity is a domain or an individual email address that you've proven you control, and it's the only kind of address SES will let you send mail from.

For a domain, verification is done by publishing specific DNS records SES gives you; once SES finds those records, every address under that domain (like billing@example.com or support@example.com) can send. For a single email address, SES sends a verification link to that inbox and waits for it to be clicked.

While an account is still in the SES sandbox, identities also matter on the receiving side: you can only send to addresses that are themselves verified, in addition to sending only from a verified identity.

SES supports two identity types, each verified differently.

• Domain verification: add a TXT record (or the three Easy DKIM CNAME records) that SES provides to your domain's DNS zone; once SES resolves them, the whole domain is verified and every sender address on it can be used.
• Email address verification: SES sends a link to the exact address; clicking it verifies only that single address, not the domain.

Domain verification is generally preferred for production because it also sets up DKIM signing at the same time and doesn't need re-verifying every time a new sender address is added under that domain.

The sandbox is the restricted mode every new SES account starts in, in every AWS Region, meant to stop the service from being used for spam before AWS has any sending history to evaluate.

While sandboxed, an account can send at most 200 emails per 24-hour period at a rate of 1 email per second, and only to recipients that are themselves verified identities (plus the SES mailbox simulator).

None of SES's other features are blocked in the sandbox, templates, configuration sets, DKIM, event publishing all work, so it's a fully usable environment for development and testing. Moving to production requires a formal request describing your use case and bounce/complaint handling plan.

A configuration set is a named group of sending rules that you attach to an outgoing message, either via an API parameter or an SMTP header, to control how that message is handled and tracked.

Through a configuration set you can assign a dedicated IP pool, attach event destinations (Amazon SNS, CloudWatch, or Kinesis Data Firehose) for send, delivery, bounce, complaint, open, and click events, set a custom open/click tracking domain, enforce a TLS delivery policy, and enable Virtual Deliverability Manager metrics.

Different configuration sets are commonly used to separate traffic types, for example one for transactional mail and another for marketing mail, so each gets its own event pipeline and reputation visibility.

Sending statistics are the account-level metrics SES exposes so you can see how your outgoing mail is performing without building your own tracking pipeline.

They cover send volume, delivery rate, bounce rate, complaint rate, and rejects, viewable on the SES console's Reputation or Sending Statistics pages, or pulled programmatically through CloudWatch metrics for dashboards and alarms.

These numbers matter beyond curiosity: sustained high bounce or complaint rates are exactly what AWS reviews when deciding whether to keep an account's sending privileges, so watching them is part of normal SES operations, not just reporting.

The SMTP interface is a regional SMTP endpoint (for example email-smtp.us-east-1.amazonaws.com) that lets any SMTP-capable application, mail server, or library send through SES without touching the AWS SDK.

It authenticates with SMTP credentials, which are a username/password pair derived from an IAM user's access keys specifically for SMTP use, not the raw access key itself. Connections use STARTTLS on ports 587, 25, 2587, or 2465.

Mail sent this way is still bound by the same rules as API sending: identities must be verified, sandbox restrictions apply, and the same 24-hour quota and rate limit are enforced, since the SMTP interface is just an alternate front door onto the same sending engine.

A bounce is the receiving mail server's rejection of a message SES tried to deliver, reported back to SES as a bounce notification rather than a successful delivery.

SES classifies bounces as either permanent (a hard bounce, such as a non-existent address) or transient (a soft bounce, such as a full mailbox), and can forward the notification through Amazon SNS or a configuration set event destination so an application can react to it.

Bounce rate is one of the two reputation metrics AWS watches most closely, alongside complaint rate, because repeatedly sending to addresses that reliably bounce is a strong spam signal to mailbox providers.

A complaint is a signal that a recipient explicitly marked a message as spam or junk in their mail client, which their mailbox provider then reports back to SES through an ISP feedback loop.

Unlike a bounce, the message was actually delivered, the recipient just didn't want it, so a complaint is a stronger negative signal about content or list quality than a bounce is about address validity.

SES surfaces complaints the same way it surfaces bounces, through SNS notifications or configuration set events, and a high complaint rate (AWS publishes a guideline threshold well under 1%) can trigger account review or suspension, so applications should suppress complaining addresses immediately rather than retrying them.

SES offers several equivalent front doors onto the same underlying sending engine, so teams can pick whichever fits their stack.

• The SES API (SendEmail/SendRawEmail on v1, or the consolidated SendEmail on the v2 API).
• The SMTP interface, for any SMTP-compatible application or library.
• AWS SDKs (Python, Java, Node.js, .NET, Go, and others), which wrap the API.
• The SES console's built-in "Send test email" tool, mainly for verification and debugging.

For example, a minimal v2 API call in Python looks like:

client.send_email(
    FromEmailAddress="support@example.com",
    Destination={"ToAddresses": ["user@example.com"]},
    Content={"Simple": {
        "Subject": {"Data": "Welcome"},
        "Body": {"Text": {"Data": "Thanks for signing up."}}
    }}
)

DKIM (DomainKeys Identified Mail) is an email authentication standard where the sending domain cryptographically signs a message, and the receiving server verifies that signature against a public key published in DNS.

SES offers two ways to add DKIM signatures: Easy DKIM, where SES generates and rotates a 2048-bit (or 1024-bit) key pair for you and you publish three CNAME records it gives you, and BYODKIM, where you supply your own key pair and selector as a TXT record.

A valid DKIM signature proves the message wasn't altered in transit and that it genuinely came from the claimed domain, which materially improves inbox placement and is one of the three checks (alongside SPF and DMARC) mailbox providers use to authenticate mail.

SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are authorized to send on a domain's behalf; a receiving server checks the connecting server's IP against that list.

By default, SES sends using its own MAIL FROM domain (something like amazonses.com), so SPF passes against Amazon's SPF record rather than yours, and the visible alignment with your own domain is weaker. Configuring a custom MAIL FROM subdomain and adding an SPF record such as v=spf1 include:amazonses.com ~all to it lets SPF pass under your own domain instead.

SPF alone only validates the envelope sender (Return-Path), not the visible From header, which is why it's paired with DKIM and rolled up under a DMARC policy for full alignment.

The account-level suppression list is a global list SES itself maintains of addresses that produced a hard bounce or a complaint; any address on it is automatically blocked from receiving further mail from that account, region-wide, without SES even attempting the send.

This protects your reputation from repeated mistakes, like an application retrying a dead address, without you having to build your own suppression database from scratch.

Addresses can also be added or removed manually through the console or API, and suppression can instead be scoped per configuration set if you want finer control than an all-or-nothing account-wide block.

Email templates are named, reusable message definitions stored in SES that hold a subject line and an HTML and/or text body containing placeholders like {{name}} or {{orderId}}.

Instead of assembling full HTML in application code for every send, you create the template once and send it with SendTemplatedEmail (single recipient) or SendBulkEmail/SendBulkTemplatedEmail (many recipients, each with their own substitution data) so SES fills in the placeholders per message.

Templates are managed through the console or API (create, update, delete, list), which keeps message design consistent and makes it easy for non-developers to update copy without a code deployment.

SES generates a bounce or complaint event the moment a receiving server rejects a message or a recipient reports it as spam, and it needs somewhere to deliver that event since the original send call has long since returned.

You wire this up either the legacy way, by attaching an Amazon SNS topic directly to an identity's notification settings, or the recommended way, by attaching one or more event destinations (SNS, CloudWatch, or Kinesis Data Firehose) to a configuration set and assigning that set to your sends.

Each notification arrives as a JSON payload containing the event type, bounce or complaint sub-type, diagnostic details, the affected recipients, and a timestamp. A typical pipeline subscribes SNS with an SQS queue or Lambda function, which then updates the application's own suppression table so hard-bounced or complaining addresses stop being emailed immediately, rather than relying solely on SES's own account-level suppression list.

The sandbox caps sending at 200 emails per 24 hours to only verified recipients, which is fine for development but unusable for any real workload, whether that's a signup flow sending password resets to arbitrary users or a newsletter going to a real subscriber list.

Staying sandboxed in production isn't just a throughput problem: because you can only send to pre-verified addresses, most real customers simply couldn't receive mail from your application at all.

Moving out requires submitting a production access request through the console describing your use case, expected volume, how you'll collect consent, and how you'll handle bounces and complaints; AWS reviews it (typically within about a day) and grants a starting quota and rate, which then grows over time based on your actual sending quality.

Configuring Easy DKIM is mostly a DNS task once you know which records SES wants.

1. Create or select the domain identity in SES and enable Easy DKIM (2048-bit is the current recommended key length).
2. SES generates three unique DKIM tokens and returns them as CNAME record values.
3. Add all three CNAME records to the domain's DNS zone (automatic if you use Route 53 with the same account).

aws sesv2 put-email-identity-dkim-signing-attributes \
  --email-identity example.com \
  --signing-attributes-origin AWS_SES

SES polls DNS and flips the identity's DKIM status to SUCCESS once it finds all three records, usually within minutes but allow up to 72 hours for DNS propagation. You can confirm status at any time with GetEmailIdentity rather than guessing from send behavior.

Both sign outgoing mail with DKIM, but they differ in who owns the keys.

Most teams default to Easy DKIM since AWS manages rotation for them; BYODKIM matters mainly when a security or compliance policy requires controlling the private key directly, or when the same domain sends through more than one email provider and needs a consistent selector.

SES publishes sending-lifecycle events (send, delivery, bounce, complaint, reject, open, click, renderingFailure, deliveryDelay, and subscription) to an Amazon SNS topic you designate, either directly on an identity's notification settings or, more commonly today, through a configuration set's event destination.

Each event is a structured JSON message describing what happened and to which recipient. SNS then fans that message out to however many subscribers you've attached, an SQS queue for reliable async processing, a Lambda function for immediate reaction, or an email/HTTP endpoint for simpler alerting.

This decouples event handling from the send call itself: your application doesn't need to poll for status, it just reacts whenever SES has something to report, which is essential for real-time suppression list updates or click/open analytics.

By default, SES sends from a shared IP pool that AWS manages collectively, which works well for low-to-moderate, steady volume because reputation is pooled across many well-behaved senders.

Dedicated IPs make sense once you're sending consistently high volume and want your reputation isolated from every other SES customer, or when a receiving mailbox provider requires allowlisting a specific static IP for compliance or partnership reasons.

The tradeoff is responsibility: a dedicated IP starts with no reputation at all and needs a deliberate warm-up ramp before it can carry full volume, whereas Managed Dedicated IPs (available as part of the Pro and Enterprise pricing plans) let AWS handle that warm-up and pooling automatically instead of you managing it by hand.

A climbing bounce rate needs a systematic check rather than a guess, since several unrelated causes can produce the same symptom.

1. Break bounces down by type in the console or VDM: hard bounces point to bad addresses, soft bounces point to temporary provider-side issues.
2. Read the diagnostic codes on individual bounce events, they usually name the exact provider-side reason (mailbox full, domain doesn't exist, policy rejection).
3. Audit list hygiene: check whether a recent import added stale or mistyped addresses instead of collecting them through confirmed opt-in.
4. Verify DNS authentication (SPF, DKIM, and any DMARC policy) hasn't broken, since some providers bounce unauthenticated mail outright.
5. Check for a recent spike in send volume or a new IP without proper warm-up, which providers can react to with blanket rejections.

Fixing the root cause and then removing chronically bad addresses (SES's own suppression list handles hard bounces automatically) is more effective than simply retrying failed sends.

The v2 API (SESv2) consolidates what used to be split across separate sending and identity/configuration management APIs into one unified interface, and it's the version AWS recommends for new development.

Practically, v2 raises the maximum message size to 40 MB (matching the SMTP interface) compared to 10 MB on v1, and it adds first-class support for contact lists, suppression list management, and multi-tenant features that v1 either lacked or handled through separate, less consistent calls.

v1 remains fully supported for backward compatibility, so existing integrations don't need to migrate urgently, but new projects generally start on v2 to avoid working around v1's older, more fragmented surface area.

Every SES account has two enforced numbers per AWS Region: a rolling 24-hour sending quota and a maximum sending rate (messages accepted per second), both counted by recipient rather than by message, so one email to five recipients counts as five against the quota.

In the sandbox these are fixed at 200 per day and 1 per second; in production they start at an AWS-assigned baseline and increase automatically as your sending history shows low bounce and complaint rates, or can be raised on request through the Service Quotas console.

Exceeding either limit doesn't queue the excess mail, it returns a throttling error to the caller (for example a MaxSendingRateExceeded response), so applications should catch that error and retry with backoff rather than treating it as a hard failure.

Mailbox providers track reputation at the domain level in addition to the IP level, based on signals like complaint rate, bounce rate, and recipient engagement (opens, replies, and deletes-without-reading) tied to your From domain.

Domain reputation follows you even if you switch IPs, dedicated or shared, which is why a poorly-performing legacy campaign on the same domain can drag down deliverability for unrelated, well-run transactional mail sent from that same domain later.

This is a core reason teams isolate different traffic types, for example using distinct subdomains for transactional versus marketing mail, so a marketing list's occasional complaints don't damage the reputation that password-reset emails depend on.

A custom MAIL FROM domain replaces SES's default amazonses.com envelope sender with a subdomain of your own, which improves SPF alignment and gives bounces a branded Return-Path instead of an Amazon one.

1. Pick a subdomain, for example mail.example.com, and set it as the identity's MAIL FROM domain via the console or PutEmailIdentityMailFromAttributes.
2. Add an MX record pointing that subdomain to feedback-smtp.<region>.amazonses.com with priority 10.

mail.example.com.  MX  10  feedback-smtp.us-east-1.amazonses.com
mail.example.com.  TXT "v=spf1 include:amazonses.com ~all"

SES then verifies both records and, once verified, uses that subdomain as the envelope sender for outgoing mail, so SPF checks pass under your own domain rather than Amazon's default one.

Both are delivery failures reported back to SES, but they mean different things and SES treats them differently.

Treating a soft bounce like a hard one (removing the address immediately) can lose a valid subscriber over a temporarily full mailbox, while treating a hard bounce like a soft one (retrying repeatedly) is exactly the pattern that damages sender reputation.

Event publishing lets a configuration set forward specific lifecycle events to one or more destinations as they happen, rather than requiring you to poll for status.

1. Create the configuration set and add an event destination: Amazon SNS for real-time notifications, CloudWatch for metrics and alarms, or Kinesis Data Firehose for bulk delivery into S3 or a data warehouse.
2. Choose which event types to publish (send, delivery, bounce, complaint, open, click, and others).
3. Reference the configuration set's name when sending the message, either as an API parameter or the X-SES-CONFIGURATION-SET SMTP header.

SES then publishes each matching event asynchronously as it's generated, so the original send call's return value only confirms acceptance, the actual delivery outcome arrives later through whichever destinations you've wired up.

Virtual Deliverability Manager (VDM) is worth turning on whenever you need proactive visibility into deliverability rather than waiting to infer problems from your own bounce and complaint metrics after the fact.

It runs inbox placement tests against major mailbox providers, tracks domain and IP reputation trends, and surfaces specific recommendations when something looks off, which is especially useful before scaling up sending volume, after switching to a new IP or domain, or when troubleshooting a deliverability drop that isn't obvious from bounce data alone.

SES deliverability metrics are included at every plan tier, while the broader Global deliverability tier (available with Pro and Enterprise, or as an a-la-carte add-on) extends testing beyond SES's own visibility for a fuller picture across more mailbox providers.

Inbound processing turns SES into an event source for Lambda so an application can react to received mail instead of just sending it.

1. Verify the receiving domain and point its MX record at inbound-smtp.<region>.amazonaws.com.
2. Create a Mail Manager rule set (or a classic receipt rule) with a condition matching the recipient, and an action that either invokes Lambda directly for small messages or writes the raw message to S3 first for larger ones, since a direct Lambda action has a payload size limit.
3. The Lambda function parses the raw MIME message (commonly with a library such as mailparser) and acts on it, creating a support ticket, auto-replying, or extracting an attachment.

event['Records'][0]['ses']['mail']['commonHeaders']['subject']

This pattern is common for support inboxes, inbound fax/document intake, and email-based automation where a reply itself is the trigger for the next step in a workflow.

SES itself doesn't technically enforce a hard split, any verified identity can send either kind of mail against the same quota, but the two traffic types carry very different expectations that matter for reputation and compliance.

AWS's own sandbox-exit review asks specifically about your use case for this reason: a bulk sender needs to show a documented opt-in and complaint-handling process that a purely transactional sender may not need to detail as heavily.

Mail Manager is SES's newer, more modular inbound architecture, built around ingress endpoints, traffic policies, and rule sets rather than a single flat list of receipt rules.

An ingress endpoint, either authenticated (only accepts mail from credentialed senders, included free) or open (accepts mail from the public internet, billed per endpoint), is where inbound SMTP connections land. A traffic policy can filter connections before they're even processed, based on TLS usage or sender IP.

Rule sets then evaluate conditions (recipient address, headers) and apply ordered actions: deliver to an archive, forward to S3 or another address, run an email add-on (virus or spam scanning), or drop the message. This layered model makes it easier to manage inbound routing across many domains from one place than the older single-rule-set model did.

A brand-new IP address has no sending history at all, and mailbox providers treat unfamiliar IPs suddenly sending high volume as a strong spam signal, regardless of how good the content or authentication is.

A warm-up plan gradually increases daily volume on that IP over roughly two to four weeks, following a provider-recommended ramp, while keeping bounce and complaint rates low, so receiving servers build up positive trust signals before the IP ever carries full production load.

SES supports automatic warm-up for standard dedicated IPs, and Managed Dedicated IPs (bundled into the Pro and Enterprise pricing plans) go further by handling the ramp and traffic distribution across a pool automatically, removing the manual scheduling burden entirely.

SES is pay-as-you-go with no contracts or upfront commitments, but since July 2026 it offers two ways to buy: three bundled pricing plans, or the original a-la-carte model.

Essentials includes deliverability insights out of the box; Pro adds Managed Dedicated IPs, email validation, and full Virtual Deliverability Manager access; Enterprise adds multi-region resilience and an annual expert deliverability assessment. The older a-la-carte model still exists at a lower base rate, currently $0.10 per 1,000 outbound emails, with dedicated IPs, VDM, and inbound processing billed separately as add-ons, which can be cheaper for low volume senders who don't need bundled deliverability tooling.

Amazon Pinpoint was never a separate email-sending engine; for the email channel specifically, it sat on top of Amazon SES and used SES's own infrastructure to actually deliver messages, while adding a multichannel orchestration layer on top: campaigns, journeys, audience segments, and analytics spanning email, SMS, and push notifications from one console.

SES, by contrast, is the lower-level sending and receiving primitive: an API and SMTP interface with no built-in campaign builder or journey editor, meant to be driven by your own application logic.

This distinction matters right now because AWS is ending support for Amazon Pinpoint on October 30, 2026. Teams that were using Pinpoint purely to send email are directed to call SES directly, while teams that relied on its campaigns, journeys, and segments are pointed toward Amazon Connect or a third-party engagement platform instead, since Pinpoint's orchestration layer, not SES, is what's actually going away.

A single send moves through several distinct stages between the API call and a final, observable outcome.

Your application calls the Send API or the SMTP interface, and SES first validates that the sending identity is verified, that the account isn't over its quota or rate limit, and that the recipient isn't on the suppression list. Accepted mail is then signed with DKIM, has any configuration-set rules applied (IP pool, tracking domain, TLS policy), and is queued for delivery.

SES then attempts delivery to the recipient's mail server. From there, three outcomes are possible: the receiving server accepts it (a delivery event), rejects it outright (a bounce event), or accepts it and the recipient later marks it as spam (a complaint event, arriving separately and afterward).

flowchart LR
  A["App calls Send API or SMTP"] --> B{Validation: identity, quota, suppression list}
  B -- Rejected --> C["Throttling / validation error returned"]
  B -- Accepted --> D["DKIM signing + configuration set rules applied"]
  D --> E["Queued for delivery"]
  E --> F["Attempt delivery to recipient MX"]
  F -- Accepted --> G["Delivery event"]
  F -- Rejected --> H["Bounce event"]
  G -.later.-> I["Recipient marks as spam: Complaint event"]
  H --> J["Event published via SNS / configuration set"]
  G --> J
  I --> J

Whichever outcome occurs, it's published as an event through SNS or a configuration set destination, which is how an application ultimately learns what actually happened to a message it sent.

Receiving mail is a sequence of checks and handoffs that happen before your application ever sees the message.

A remote sender's mail server first does a DNS MX lookup for your domain and finds it pointing at an SES ingress endpoint. It opens an SMTP connection to that endpoint, which SES evaluates against any traffic policy you've configured (for example, requiring TLS or blocking known-bad sender IPs) before accepting the message at all.

sequenceDiagram
    participant Sender as Remote MTA
    participant DNS as Your DNS (MX)
    participant Endpoint as SES Ingress Endpoint
    participant Rules as Mail Manager Rule Set
    participant Dest as Action (S3 / Lambda / Forward)

    Sender->>DNS: MX lookup for your domain
    DNS-->>Sender: Returns SES ingress endpoint
    Sender->>Endpoint: SMTP connection + message
    Endpoint->>Endpoint: Traffic policy check (TLS, sender IP)
    Endpoint->>Rules: Message passed to rule set
    Rules->>Rules: Evaluate conditions (recipient, headers)
    Rules->>Dest: Execute ordered actions
    Dest-->>Sender: Implicit SMTP accept/reject response

Once a connection is accepted, the message is handed to a Mail Manager rule set, which checks conditions like the recipient address or specific headers, then runs its configured actions in order, archiving, scanning through an add-on, writing to S3, forwarding, or invoking Lambda, any of which can trigger further application logic.

SES reputation isn't a single number, it's several layers of signal that get aggregated and then acted on.

At the base, receiving mailbox providers report bounce and complaint feedback for every message they process, that raw feedback is the actual source data. SES rolls this up at two levels simultaneously: the sending identity's domain reputation, which follows the domain regardless of which IP sent the mail, and IP reputation, tracked either across a shared pool or in isolation for a single dedicated IP.

flowchart TD
  A["Receiving mailbox providers report bounces/complaints"] --> B["SES aggregates by domain"]
  A --> C["SES aggregates by IP - shared pool or dedicated"]
  B --> D["Account-level reputation dashboard"]
  C --> D
  D --> E{Bounce/complaint rate crosses guideline threshold?}
  E -- Yes --> F["Sending paused / account flagged for review"]
  E -- No --> G["Normal sending continues; quota may grow over time"]
  D --> H["Virtual Deliverability Manager correlates with inbox placement tests"]

Those rolled-up numbers feed the account-level reputation dashboard, and if either bounce rate or complaint rate crosses AWS's published guideline thresholds, SES can pause a configuration set's sending or flag the account for manual review, rather than simply letting quality degrade silently. Virtual Deliverability Manager adds a further layer by correlating these internal numbers with actual inbox placement test results across major providers.

High-volume transactional deliverability comes down to authentication, isolation, and hygiene working together rather than any single setting.

• Fully authenticate the sending domain with DKIM, SPF via a custom MAIL FROM domain, and a DMARC policy, since misaligned authentication is one of the fastest ways to lose inbox placement.
• Warm dedicated IPs gradually rather than jumping straight to full volume.
• Isolate transactional traffic in its own configuration set (and ideally its own subdomain or IP pool) so marketing sends elsewhere don't drag its reputation down.
• Watch VDM and bounce/complaint metrics continuously rather than only after a problem appears.
• Suppress hard bounces and complaints immediately and keep lists clean, since sending to known-bad addresses is one of the strongest negative signals providers use.
• Keep sending patterns steady rather than spiky, and keep the From address consistent so recipients and providers build recognizable trust in it.

Because SES identities, configuration sets, and suppression lists are all scoped per AWS Region, a real failover design needs those pieces mirrored deliberately rather than assumed to exist everywhere.

Start by verifying the sending domain and its DKIM records in at least two Regions, since DNS-based verification isn't region-specific but SES's internal identity record is. Replicate configuration sets, templates, and event destination wiring across Regions with infrastructure-as-code so they stay in sync rather than drifting.

For actual failover, either use SES's Global Endpoints feature, which routes sending through a single multi-region endpoint and handles the region selection for you (available on the Enterprise plan or as an add-on), or implement it at the application layer: catch a regional throttling or outage error, retry against a secondary region's SES client, and centralize suppression data (for example in a DynamoDB global table) so a hard bounce recorded in one Region isn't blindly re-sent to from another, since SES's own suppression list doesn't replicate across Regions automatically.

Exceeding either the 24-hour sending quota or the per-second rate limit doesn't queue the extra mail for later, it returns an explicit throttling error to the caller (for example a MaxSendingRateExceeded or daily-quota-exceeded response), and that particular send simply isn't accepted.

Messages that were already accepted before the limit was hit continue through the normal delivery pipeline unaffected; only new calls made while over the limit are rejected. The 24-hour quota is a rolling window, so capacity frees up continuously rather than resetting all at once at midnight.

The recommended response is to catch the throttling error and retry with exponential backoff, monitor the account's quota usage via CloudWatch so you see it coming, and request a quota increase proactively through the Service Quotas console well before you expect to need it, rather than reactively after being throttled in production.

SPF, DKIM, and DMARC prove who sent a message and that it wasn't tampered with in transit, they establish identity, not content quality or sender reputation, and those are two very different problems.

Where a message actually lands, inbox versus spam folder versus rejected outright, is decided by each receiving mailbox provider's own proprietary filtering, which weighs recipient engagement history, domain and IP reputation built up over time, content and structure heuristics, and list quality signals that SES has no visibility into or control over.

SES's job ends at getting an authenticated, policy-compliant message successfully handed off to the receiving server; from that point, Gmail, Outlook, or any other provider's own algorithm makes the placement decision independently, which is exactly why deliverability work continues well past just enabling authentication, list hygiene, engagement, and sending consistency all keep mattering afterward.

A configuration set can set a delivery-options TLS policy of either Optional (the default) or Require for messages sent through it.

Under Optional, SES attempts an encrypted connection to the receiving mail server but falls back to plaintext delivery if that server doesn't support TLS, prioritizing successful delivery over guaranteed encryption. Under Require, SES will only deliver over an encrypted connection; if the recipient's server can't negotiate TLS, the message bounces rather than being sent in plaintext.

{
  "ConfigurationSetName": "secure-notifications",
  "DeliveryOptions": {
    "TlsPolicy": "REQUIRE"
  }
}

Require is the right choice for workloads carrying sensitive data, such as anything adjacent to healthcare or financial information, where transmitting in plaintext would be an unacceptable compliance risk even occasionally, at the cost of accepting some bounces to servers that genuinely can't support TLS.

Both categories ultimately relay mail to the same receiving mailbox providers, but they differ in how they're priced, packaged, and where they sit relative to the rest of your infrastructure.

Teams already deep in AWS often default to SES for cost and integration simplicity, especially for transactional volume, while teams wanting a more turnkey marketing/campaign experience out of the box sometimes prefer a dedicated ESP, occasionally even one built on top of SES itself.

At high volume, feedback processing needs to be asynchronous, idempotent, and fast to react, since a slow suppression pipeline means real money spent sending to addresses you already know are bad.

flowchart LR
  A["SES bounce/complaint events"] --> B["Configuration set event destination"]
  B --> C["SNS topic"]
  C --> D["SQS queue"]
  D --> E["Lambda consumer"]
  E --> F{Hard bounce or complaint?}
  F -- Yes --> G["Suppress address immediately in app DB"]
  F -- No, soft bounce --> H["Increment retry counter with backoff"]
  B --> I["Kinesis Data Firehose"]
  I --> J["S3 data lake for analytics/reconciliation"]
  E --> K["CloudWatch alarm on rate thresholds"]

Route events from a configuration set to both an SNS topic (for real-time reaction via SQS and a Lambda consumer) and a Kinesis Data Firehose stream (for bulk landing in an S3 data lake for later analytics). The Lambda consumer should dedupe by message ID to stay idempotent against redelivery, suppress hard bounces and complaints immediately in the application's own database rather than waiting on SES's own list, and apply a backoff counter to repeated soft bounces instead of suppressing on the first occurrence.

Finally, periodically reconcile the application's suppression table against SES's own account-level suppression list via the API, and alert on rate thresholds through CloudWatch so a reputation problem is caught within minutes, not discovered days later in a monthly report.

Delays are a different problem from bounces: the message isn't being rejected, it's taking longer than expected to land, and SES actually has a dedicated event type, deliveryDelay, for exactly this case.

Start by enabling deliveryDelay events on the relevant configuration set and reading the specific reason code SES reports, common causes include the receiving server being temporarily unavailable, greylisting (a deliberate provider-side "try again later" response to unfamiliar senders), or the recipient's provider rate-limiting SES's sending IP under a sudden volume increase.

Cross-check CloudWatch reputation and throttling metrics for the same window to see whether your own sending rate spiked, verify DNS resolution for the recipient's MX records hasn't broken, and rule out content that might be getting pulled aside for extra scanning by the receiving provider. Persistent delays to one specific provider, rather than delays spread evenly across many, usually point to a rate or reputation issue with that provider specifically rather than a general SES problem.

VDM's dashboard combines two distinct kinds of data rather than relying on either alone: real signals collected from your actual sends, and synthetic signals from deliberate testing.

On the real side, it aggregates the bounce, complaint, and delivery events your account is already generating, split out by domain and by IP, into reputation scores and trend lines over time. On the synthetic side, it runs seed-list-based inbox placement tests, sending probe messages to accounts at major mailbox providers to directly observe whether they land in the inbox, the spam folder, or nowhere at all, which the real-send data alone can't show you since you don't normally see the recipient's folder.

VDM correlates both against a historical baseline for your account and flags meaningful deviations with specific, actionable recommendations rather than raw numbers alone. Data refreshes on a periodic cycle rather than instantly, so it's suited to spotting trends and emerging problems, not to debugging a single message's exact fate in real time. The Global deliverability tier extends the inbox placement testing to broader mailbox provider coverage beyond what SES's own account-level view provides.

Neither is universally better, they suit different situations, so the right choice depends on what's driving the send.

For a new application built with an AWS SDK already in hand, the API is the more natural and slightly more efficient choice. For an off-the-shelf tool that only knows how to relay through SMTP, or a migration from another SMTP provider where minimizing code changes matters, the SMTP interface gets the same SES sending engine without requiring any AWS-specific integration work.

Cost optimization at scale is mostly about matching the pricing model to actual usage patterns rather than any single trick.

• Compare the a-la-carte rate against the bundled Essentials/Pro/Enterprise plans for your real projected volume; a-la-carte's lower base rate can win at low-to-moderate volume, while a plan's fixed monthly fee amortizes better once deliverability add-ons would otherwise be purchased separately at scale.
• Watch attachment data volume specifically, since it's billed per gigabyte on top of the per-email rate, and large attachments belong in a linked download rather than inline where possible.
• Use templates with SendBulkEmail rather than re-sending near-duplicate payloads per recipient, which reduces both request overhead and the chance of inconsistent content.
• Avoid enabling Global Endpoints or a second dedicated IP pool unless genuine multi-region failover is actually needed, since both carry their own ongoing charges.
• Keep lists clean: chronic bounces don't just risk reputation, they're also sends you paid for that never had a chance of landing.

An address's journey onto and off the suppression list follows a clear sequence, even though the trigger can come from either SES itself or a manual action.

flowchart LR
  A["Address sent to"] --> B{Outcome}
  B -- Hard bounce or complaint --> C["Address added to suppression list automatically"]
  B -- Manual action --> C
  B -- Clean delivery --> D["No suppression"]
  C --> E["Future sends to that address are blocked account-wide"]
  E --> F["SES reports a Suppressed event instead of attempting delivery"]
  F --> G{Manually removed later?}
  G -- Yes, after investigation --> H["Address can be sent to again"]
  G -- No --> E

An address is added automatically the moment SES records a hard bounce or a complaint against it, or it can be added manually through the console or API without waiting for either event. Once suppressed, SES blocks every future send attempt to it account-wide (across every identity in that account and Region) and reports a Suppressed event rather than actually attempting delivery, so the address doesn't quietly keep counting against your quota.

Suppression doesn't expire on a timer by default; it persists until someone removes it deliberately, typically after investigating whether the underlying issue (a mistyped address, a temporary mailbox provider problem, or a resolved complaint) has genuinely been resolved. Where an all-or-nothing account-wide block is too blunt, for example wanting to retry an address for one traffic type but not another, suppression can instead be scoped at the configuration set level so different sending contexts make independent decisions about the same address.