skip to content

An application can reach Amazon SES either through the SESv2 API or through the SES SMTP endpoint. What decides which one you use, and how do SES SMTP credentials relate to IAM credentials?

level: middleimportance: should knowfreq 48%

answer

  1. one path stores a secret, one does not
  2. role credentials versus a config file
  3. username is a key id, password is derived
  4. derived per Region, not portable
  5. SMTP is for software you cannot change

basics

~20 s

Use the SESv2 API when you control the code: the SDK signs with the IAM role's temporary credentials, so no secret is stored. Use the SMTP endpoint for off-the-shelf software that only speaks SMTP. SES SMTP credentials are derived from an IAM secret key and are Region-specific — they are not the IAM secret itself.

solid answer

~60 s

The SESv2 API is the default for code you own. The AWS SDK signs each call with whatever credentials the environment provides, so on EC2, ECS or Lambda that is the instance or task role's short-lived credentials — nothing long-lived is stored, and you get structured responses like the message ID and per-entry results. The **SMTP endpoint** (`email-smtp.<region>.amazonaws.com`, usually port 587 with STARTTLS or 465 with implicit TLS) exists for software that only knows how to talk SMTP: a Postfix relay, a vendor appliance, a legacy application. Its credentials are the sharp edge. SES SMTP credentials are *not* your IAM access key and secret pasted in: the username is an access key ID, but the password is derived from the IAM secret access key using a Region-specific derivation, so a password generated for one Region will not authenticate in another. That derived password is a long-lived secret in a config file, which is exactly what the API path avoids — so choose SMTP only when the client leaves you no option.

code

bash · 4 lines
bash
# SMTP submission to SES: STARTTLS on 587, AUTH with a derived password
# username = an IAM access key ID; password = derived from the IAM secret + Region
openssl s_client -starttls smtp -crlf -quiet \
  -connect email-smtp.us-east-1.amazonaws.com:587

go deeper

for a junior

Know that SES can be reached through an AWS SDK or through a normal SMTP endpoint, and that the SMTP password is a special generated credential rather than your AWS secret access key.

for a middle

Explain the credential derivation — username is an access key ID, password is derived from the secret plus the Region — and why the API path on AWS compute needs no stored secret at all.

for a senior

Show the operational judgment: pick SMTP only for software you cannot change, keep the derived password in a secret store with a rotation plan, and recognise the Region-mismatch auth failure on sight.

for a principal

Frame it as a credential-surface decision across the estate — how many long-lived SMTP secrets exist, who can send as the corporate domain through them, and what the migration path onto role-based API sending looks like.

## Two front doors to the same service SES accepts mail two ways, and both end up in the same sending pipeline with the same identities, quotas, configuration sets and event stream. The choice is about how your client authenticates and what the interface gives you back. ## The SESv2 API You call `SendEmail` (or `SendBulkEmail`) through an AWS SDK. Authentication is SigV4 over whatever credentials the default provider chain finds. On AWS compute that is a role: an EC2 instance profile, an ECS task role, a Lambda execution role. The credentials are temporary and rotated by AWS, so **there is no secret in your configuration at all**. What else you get: - A structured response — the SES message ID, which is the join key back to bounce and delivery events. - Real error types you can branch on, such as throttling versus a rejected message versus an unverified identity. - Access to the bulk and templated sending operations, which have no SMTP equivalent. - Per-call knobs like attaching a configuration set by name. ## The SMTP endpoint SES also runs a standards-compliant SMTP submission service at `email-smtp.<region>.amazonaws.com`. Ports: 587 with STARTTLS and 465 with implicit TLS are the ones to use; 25 also listens but is a bad idea on AWS, because **EC2 throttles outbound port 25 by default** and you must ask AWS to lift that. The alternate ports 2587 and 2465 exist for environments that block the standard ones. SMTP's reason to exist is integration. Enormous amounts of software — mail relays, monitoring appliances, ERP systems, off-the-shelf web applications — can be pointed at an SMTP host and nothing else. For those, SMTP turns SES into a drop-in replacement for a mail server you no longer want to run. ## The credential question interviewers actually probe The common wrong answer is "you use your AWS access key and secret as the SMTP username and password." You do not. - The SMTP **username** is an IAM access key ID. - The SMTP **password** is *derived* from the corresponding IAM secret access key together with the Region, using a documented SigV4-style derivation. The console can generate the pair for you, and there is a published algorithm to derive the password yourself from an existing key. Two consequences follow, and both are real incidents: 1. **The derived password is Region-specific.** Copy a working SMTP password from `us-east-1` to `eu-west-1` and authentication fails. People chase firewall rules for hours over this. 2. **The underlying IAM principal must be allowed to send.** SMTP submission maps onto the SES send permission (`ses:SendRawEmail`), so an identity without it authenticates conceptually but cannot send. And the security consequence: the SMTP password is a **long-lived static secret** that has to live somewhere your application can read it. That is precisely the class of secret that role-based API access eliminates. If you must use SMTP, store the password in a secret store rather than a config file or image layer, and have a rotation plan — rotating means generating a new credential and cutting over, because the password is bound to the IAM key it was derived from. ## Choosing - **Code you own, running on AWS** → API. Role credentials, no secret, structured results, bulk and template operations available. - **Software you cannot change** → SMTP, with the password in a secret store, on port 587 or 465, and the Region-specific derivation understood. - **Migrating off a self-hosted mail server** → SMTP is the zero-code first step; moving the applications you own onto the API afterwards is a sensible second phase. One thing that does *not* differ: identities, sandbox status, sending quota and the max send rate apply identically to both paths. SMTP is not a way around a quota, and a throttled SMTP session simply gets a transient failure reply instead of an API exception.

  • A team copies a working SES SMTP password from us-east-1 into a service deployed in eu-west-1 and authentication fails. Why?
    The SMTP password is derived from the IAM secret access key together with the Region, so it is only valid for the Region it was generated for. Generate a new SMTP credential in eu-west-1 (or derive one for that Region from the same IAM key). It looks like a network or firewall problem, which is why teams lose hours to it.
  • Why is the API path considered more secure than SMTP on AWS compute?
    Because it stores no secret. The SDK signs each request with the instance profile, ECS task role or Lambda execution role credentials, which AWS issues short-lived and rotates automatically. SMTP needs a long-lived derived password sitting in configuration, which must be stored in a secret manager, kept out of images and logs, and rotated deliberately.
  • Does using SMTP let you bypass the SES sending quota?
    No. Identities, sandbox status, the 24-hour cap and the maximum send rate are properties of the account and Region, not of the interface. SMTP hits the same limits; you just see them as transient SMTP failure replies instead of an API exception, which makes them easier to miss if the client silently retries.

saying these in an interview costs you the question

  • Pasting the IAM secret access key as the SMTP password
  • Assuming SMTP credentials work in any Region
  • Thinking SMTP avoids the SES sending quota
  • Using port 25 from EC2 without knowing it is throttled
  • Storing the SMTP password in the container image

context

resolving links…