For password resets, login codes, receipts, and account notifications, a working Amazon SES setup is smaller than the AWS console suggests. The minimum is one Region, a verified sending identity, authentication records, production access when the account is still in the sandbox, send-only authorization, feedback handling, basic monitoring, and either the SES API or SMTP interface.
The goal is not to configure every SES feature. It is to establish a sending path that is authenticated, environment-aware, observable, and safe to operate.
Minimum checklist
- Choose one SES Region and configure the application there.
- Verify a sending domain or individual sender identity.
- Enable Easy DKIM for a domain identity and publish the DNS records.
- Publish a practical DMARC policy for the visible From domain.
- Request production access for that Region if the account remains in the sandbox.
- Give the runtime only the send actions it needs.
- Receive and process bounce and complaint events.
- Record provider message IDs and monitor rejection, quota, bounce, and complaint signals.
- Keep development, staging, and production recipients and credentials separate.
Start with one Region
SES configuration is regional. Sending identities, sandbox status, quotas, configuration sets, event destinations, and SMTP endpoints can differ between Regions. Choose one Region for a small application, keep the identity and runtime there, and record the choice in deployment configuration rather than allowing each developer to select a different Region.
A second Region is not automatically redundancy. It requires another verified identity, DNS and event configuration, quotas, monitoring, credentials, and a deliberate failover policy. Add one when continuity or geographic requirements justify the operating cost. AWS documents the relationship between Regions and SES in its Regions guide.
Write the Region into the application’s deployment configuration and into the operational runbook. Verify that the identity, configuration set, SNS topic, SMTP endpoint, and IAM policy all refer to that same Region. A common small-application failure is a verified identity in one Region and a runtime client silently configured for another, where the account is still in the sandbox or the sender is unverified.
SES quotas are also regional. The account has a daily sending quota and a maximum sending rate in the selected Region. A request rejected because the quota or rate is exceeded is not a promise that SES will send it later. Queue and back-pressure work belongs in the application or mail service.
Choose a domain or address identity
A verified identity tells SES which domain or email address the account may use as a sender. Verifying one individual address is quick for a small experiment. Verify the domain when the application will send from several addresses such as no-reply, billing, support, and security.
Domain verification does not move DNS hosting or mailbox hosting to SES. It proves that the account is authorized to send using the identity. Subdomains can be separate identities when the application needs to isolate sending reputation or ownership.
Use the identity verification guide, and keep production and test identities distinguishable. A test identity or separate domain helps prevent a local experiment from using the visible sender associated with customer mail.
DKIM, SPF, and DMARC in practical terms
Easy DKIM is the normal production setup. SES gives you DNS records, usually CNAMEs, and signs messages after the identity is verified. Publish the records exactly and wait for SES to report verification. DKIM authentication can provide alignment with the visible From domain, which is important for DMARC.
DMARC is strongly recommended because it tells receiving systems how to evaluate messages that claim to be from your domain and where to send aggregate or forensic reports. It is not literally required by SES merely to submit an email. Start with a policy that matches the other systems sending mail for the domain, often p=none while you inspect alignment, then tighten it deliberately.
The default SES MAIL FROM behavior can pass SPF using an amazonses.com domain, but that does not provide SPF alignment with the visible From domain. A custom MAIL FROM domain can provide aligned SPF when its DNS records are correct, but it is not required when aligned DKIM already satisfies DMARC. Do not add custom MAIL FROM solely because a checklist says SPF must be aligned; choose it when the domain’s mail policy or operational requirements justify it.
See AWS’s Easy DKIM documentation, DMARC guidance, and custom MAIL FROM guide.
Sandbox and production access
The SES sandbox is useful for proving authentication, sender configuration, application errors, and feedback handling. It restricts recipients and sending volume, so it is not a public transactional-email configuration. Request production access in the selected Region with the real website, use case, and explanation of bounce and complaint handling.
The account’s production-access decision is AWS’s. It may ask for more information, reject the request, or impose conditions. Production access does not verify DNS, remove quotas, or decide how the application processes failed delivery. See Request production access.
For test and staging, use the SES sandbox or a separate test identity and recipient policy. Never use a live customer recipient list merely because the application is “only running staging.”
Give the runtime only sending permission
The application does not need administrator access to send mail. On AWS compute, prefer a workload role with the required SES actions. Outside AWS, a narrowly scoped access key may be appropriate when protected by the deployment platform or secret manager.
The exact actions depend on the sending path. Structured sending commonly needs ses:SendEmail. A library that submits raw MIME may also need ses:SendRawEmail. Restrict permissions to the selected Region and verified identity where practical, and keep IAM administration, identity creation, DNS changes, and production-access requests out of the request-time role.
AWS documents SES permissions in its IAM guide. A temporary workload credential is generally preferable to a long-lived access key in a source checkout. If SMTP is used, remember that SES SMTP credentials are a distinct credential type derived for SMTP use; they are not ordinary console passwords or interchangeable with an application’s AWS access key.
API or SMTP?
Use the SES API when the application already uses an AWS SDK, needs structured request validation, or wants native provider response handling. The API supports simple, raw, and templated message forms.
Use SMTP when the framework already has a reliable SMTP transport and changing mail configuration is simpler than adding an SDK. SMTP credentials, endpoints, TLS requirements, and connection limits still need careful deployment configuration. Neither API nor SMTP changes identity verification, production access, feedback, or quota responsibilities.
Read AWS’s email sending API guide and SMTP guide.
Sending identities and From behavior
Decide whether the application may choose the visible From address. A direct SES integration can enforce a configured identity through IAM conditions or application validation. Do not let an untrusted user submit arbitrary From values merely because SES accepts the request shape. Sender ownership is part of abuse prevention and reputation.
Keep reply-to behavior separate from the sender identity. Validate addresses, reject header injection, and make display names and line endings safe. Store the application’s message intent and the SES MessageId returned when SES accepts the request. That ID is evidence of provider acceptance, not evidence that a recipient mailbox accepted or displayed the message.
Accepted by SES is not delivered
SES can accept a message and later report delivery, delay, bounce, complaint, reject, or rendering failure. A successful API response should therefore move the application message to an accepted state, not delivered.
At minimum, receive bounce and complaint notifications, make event handling idempotent, associate events with the application message, and suppress permanent bounces. Do not keep sending to addresses that generate hard bounces or complaints. Keep consent, unsubscribe, sender policy, and customer communication responsibilities in the application.
For a small setup, SNS feedback notifications may be enough. Configuration sets and event publishing are useful when you need structured metrics, delivery events, message tags, or multiple destinations. AWS can publish sending events to SNS, EventBridge, Firehose, CloudWatch, and other services. The configuration set must be applied to the messages whose events you expect to publish.
See SES event notifications, configuration sets, and event publishing.
Basic monitoring and rate handling
Monitor:
- accepted sends and provider rejects;
- daily quota and maximum sending rate;
- bounce, complaint, and delivery-delay rates;
- notification or event-publishing failures;
- queue age and worker failures;
- missing configuration or identity verification;
- SMTP/API timeouts and throttling.
Set alerts below provider account-review thresholds so the team has time to act. When SES throttles, use bounded retry and back-pressure. Do not start an unbounded retry loop from a web request. For uncertain network outcomes, record the send intent and decide whether a retry can create a duplicate.
What you do not need on day one
A minimum transactional setup usually does not need:
- dedicated IPs;
- multiple Regions;
- a custom MAIL FROM domain when aligned DKIM is sufficient;
- a VPC endpoint;
- Amazon WorkMail;
- SES inbound receiving;
- a large configuration-set hierarchy;
- custom templates before message content is stable;
- a general AWS administration role in the application.
Add those features for a concrete requirement: volume, compliance, continuity, inbound processing, organizational separation, or a measured deliverability problem.
Where Gateman fits
Gateman’s Premium SES provisioning is a supported setup boundary, not a replacement for AWS or email operations. The current workflow can verify or configure the supported AWS setup identity, SES domain identity, Easy DKIM and DNS records, DMARC, configuration set and SNS event destination, runtime sending identity and credential, and the event-tracking path.
The application later uses email.send with the documented request route POST /send/ses. Gateman controls the configured sender identity and runtime provider credential. Development and staging capture locally; production contacts SES. Premium tracking can receive SES/SNS events and maintain Gateman’s email status and suppression behavior.
AWS still owns the production-access decision. Gateman cannot approve an account, remove provider quotas, or guarantee that AWS will grant production access. The customer remains responsible for consent, sender policy, reputation, bounce and complaint consequences, recipient data, and AWS account administration. Standard sending can use an existing SES setup without managed provisioning or tracking.
Read the SES provisioning capability and email capability for the current boundaries. Gateman reduces setup and credential plumbing; it does not make poor email practice safe.
The practical minimum
Choose one Region. Verify a domain or sender address. Enable Easy DKIM and publish a sensible DMARC policy. Request production access when necessary. Use a send-only workload identity. Record provider message IDs. Receive and process bounce and complaint events. Monitor quotas, rate limits, queue health, and notification failures. Keep environments separate.
Once those pieces work, add complexity only when a real operational requirement calls for it.