How to Set Up Transactional Email with Amazon SES

A new Amazon SES account starts in the sandbox, where you can send at most 200 messages per 24-hour period and only to verified addresses and domains or the mailbox simulator. Knowing how to set up transactional email with Amazon SES helps you plan identity verification, testing, production access, and recipient-counted quotas before a release depends on email.

To set up transactional email with Amazon SES, choose an AWS Region and verify the domain or address you will send from. Test with verified recipients in the sandbox, request production access for the Region when you need to reach unverified recipients, then send through the SES API or SMTP interface. Track the account’s quota and rate, and test retries so a temporary failure does not trigger duplicate messages.

1. Choose a Region and sending identity

Start by choosing the AWS Region your application will use to send. Amazon SES maintains identity verification, sandbox status, and sending quotas separately for each Region. If you plan to send from two Regions, treat them as two configurations rather than assuming setup in one applies to the other. AWS’s regional guidance describes these regional differences.

Next, choose the address or domain that will appear as the sender. For example, a product might use receipts@example.com for order confirmations and security@example.com for password resets. A verified domain permits sending from addresses and subdomains in that domain without verifying each address individually; an email-address identity authorizes that address alone. See Amazon SES identity guidance for the distinction.

There is one feature-related wrinkle: an email address that inherits verification from its domain is limited to straightforward sending. If you need advanced sending features for that address, SES requires you to verify the email address identity explicitly as well. Decide which identity your application needs before wiring the sender into production code.

Before creating an identity, identify who can change the domain’s DNS. SES domain verification depends on publishing records, and DNS changes can take up to 72 hours to propagate. If a platform team or outside administrator controls DNS, arrange the handoff early and provide the records generated for your identity instead of asking them to create records from memory.

2. Verify the domain and understand email authentication

In the SES console, create a domain identity and publish the verification and DKIM records SES generates. The exact records depend on the identity and Region. For Easy DKIM, AWS says to generate records in each Region where you will send and use that Region’s generated values; its regional guidance also identifies SigningHostedZone as an API value used to construct CNAME records.

Domain verification and email authentication solve related but different problems. Verification establishes that you control the sending identity in SES. DKIM adds a cryptographic signature to outgoing mail. SPF is a DNS TXT record that identifies which sending sources a receiving system may accept for a domain, while DMARC tells receiving systems how to evaluate mail using SPF and DKIM alignment and what policy to apply to failures.

A DNS zone might contain a provider-specific SPF record at the domain and a DMARC TXT record at _dmarc.example.com. As a shape-only illustration, a DMARC value may include fields such as v=DMARC1; p=<policy>; rua=mailto:<reports@example.com>; the angle-bracket values are placeholders, not records to publish. Amazon SES does not publish a universal SPF or DMARC record value for every sender configuration, so obtain the correct SPF authorization from the sending setup you use and choose a DMARC policy appropriate to your domain.

Do not copy a record from another domain simply because it appears to work. A record can authorize the wrong sender, conflict with an existing mail service, or apply a policy before you are ready. Coordinate changes with whoever manages the DNS zone, and check the resulting records in that zone after publication.

3. Test in the SES sandbox

Amazon SES puts new accounts in the sandbox in each Region. In that state, you can send only to verified email addresses and domains or to the SES mailbox simulator, with a limit of 200 messages per 24-hour period and 1 message per second. Use this stage to validate your integration, not to estimate the capacity of a live application.

A useful sandbox test follows a real application event. For example, trigger a test purchase, confirm the order event produces a receipt for the intended recipient, and inspect the sender, content, links, and application response. The mailbox simulator is useful for exercising SES sending behavior without sending to an ordinary recipient, but it does not prove how a real recipient’s mailbox will display your message.

Make the test cover failure handling as well as the successful send. If a request times out after SES accepts it, a blind retry could send a second receipt. Attach an application event ID to your send workflow and make the retry path safe for that event; this is especially important when a queue or webhook can deliver the same event more than once.

A concise pre-launch test list is more useful than a generic “send a test email” check:

• Confirm the intended Region, verified sender identity, and sandbox status.
• Trigger one purchase receipt and one password-reset message using test accounts.
• Confirm a failed or timed-out send is observable and does not create duplicate messages on retry.
• Test the mailbox simulator separately from a real test inbox.
• Verify that the application records the send result against the event that initiated it.

4. Request production access for the Region

To send to ordinary recipients whose addresses are not verified with your account, request that SES move the account out of the sandbox. In the console, open Account dashboard, choose View Get set up page, then select Request production access. Select Transactional if the main purpose is one-to-one email triggered by a user action, such as a purchase or password-reset request. AWS uses that type of example to distinguish transactional mail from other sending.

The request asks for a website URL and allows up to four additional contact email addresses. AWS says Support provides an initial response within 96 hours after submission, and account details cannot be edited while the request is under review. That is an initial response window, not a guarantee that every request will be approved in that time, so include the request and review in your launch plan.

After production access is granted, you can send to recipients without verifying each recipient’s address or domain. You still need to verify the identities used as From, Source, Sender, or Return-Path. Keep that distinction clear: production access changes who you may send to; it does not remove the sender identity requirement. The SES production-access instructions cover sandbox restrictions and the request process.

5. Choose the SES API or SMTP

Amazon SES supports sending through its API or SMTP interface. The API is a natural fit if your application already calls AWS services through an SDK or HTTPS client. SMTP can fit an existing mail library or application that exposes configurable mail transport settings. In either case, use the same Region in your sender configuration that you used for identity verification and production access.

Here is a working Python SMTP pattern with configuration supplied through environment variables. Set the host and port to the values for the SES Region and SMTP configuration you use; this example deliberately does not hard-code a regional endpoint.

import os
import smtplib
from email.message import EmailMessage

message = EmailMessage()
message["From"] = os.environ["MAIL_FROM"]
message["To"] = "test-recipient@example.net"
message["Subject"] = "Your order receipt"
message.set_content("Thanks for your order. Your receipt is ready.")

with smtplib.SMTP(os.environ["SES_SMTP_HOST"], int(os.environ["SES_SMTP_PORT"])) as smtp:
    smtp.starttls()
    smtp.login(os.environ["SES_SMTP_USER"], os.environ["SES_SMTP_PASSWORD"])
    smtp.send_message(message)

The SES SMTP documentation explains the interface, and SMTP credentials are Region-specific. Treat them as secrets: store them in a server-side secret manager or deployment environment, not in browser or mobile code. Restrict which application components can read them, and rotate them using your organization’s normal credential process. For an API integration, use the AWS SDK or signed API requests with appropriate server-side AWS credentials rather than embedding credentials in a client.

6. Calculate quota using recipients, not messages

SES has a sending quota—the maximum number of emails permitted in a rolling 24-hour period—and a sending rate, the number of emails it can accept per second. A short burst may exceed the rate, but sustained sending above it is not allowed. Quotas are regional, and limits can differ by Region. AWS describes the two limits in its sending-quota guidance.

SES counts recipients, not message objects. Suppose an application sends 120 order notifications, each addressed to the buyer and one additional recipient. That is 240 recipients against the sending quota, even though the application created 120 messages. If the same 120 messages each go to one recipient, they consume 120 recipients. This distinction matters when estimating volume, particularly if a billing system sends copies to both a customer and an accounts-payable contact.

Do not plan against an assumed universal production quota or sending rate: the exact defaults vary by account, and Amazon SES does not publish one figure that applies to every account. Use the account’s displayed limits when estimating capacity. You can request quota increases when requesting sandbox removal and later by opening a case in AWS Support Center.

For a burst such as a billing run, compare both the recipient count over the rolling 24-hour period and the rate at which your queue releases messages. If SES throttles a request, use a queue with controlled backoff rather than immediately replaying every failure. Record the originating event or use an idempotency mechanism so a retry does not turn one invoice or password reset into multiple emails.

7. Monitor bounces, complaints, and suppression

A successful API or SMTP submission confirms that SES accepted the request; it does not establish that a recipient received or wanted the email. Treat bounce and complaint outcomes as operational signals. A receipt sent to a mistyped address and a password reset sent to an abandoned mailbox need different product responses, but both should be visible to the team responsible for email health.

SES has an account-level suppression list, and its behavior is tied to the sending account and Region. Review how your integration handles addresses that should not receive another message after a bounce or complaint. When a user changes an email address, update your application’s recipient record deliberately rather than repeatedly retrying a known-bad destination.

Connect sending outcomes to application events. For example, a payment event can carry an order ID, while the mail log stores the send attempt, timestamp, destination category, and result. Avoid logging credentials or unnecessary message contents. The goal is to answer concrete questions—whether a receipt was attempted, whether SES accepted it, and whether a later outcome requires suppressing that address—without exposing sensitive data.

8. Direct SES setup compared with Volanea

Direct SES gives a team control over its sending integration, but the team owns identity setup, production access, quota planning, authentication, and the surrounding application behavior. A managed layer can reduce the setup the application team must implement while retaining SES as the delivery infrastructure. Volanea is built on Amazon SES, so emails it sends go out over SES, while the platform combines transactional email, campaigns, and automations on one API.

The practical difference is the setup path. Direct SES requires you to configure the Region and sender identity, test within the sandbox, and request production access for sending to unverified recipients. Volanea requires domain verification before sending to real recipients, but its sending account does not require a customer SES production-access request. That removes the customer-side sandbox request and its review dependency, including the stated 96-hour initial-response window; domain verification and DNS propagation still apply.

For example, the Volanea quickstart shows a request with a bearer API key and JSON fields for to, subject, and html:

curl https://api.volanea.com/v1/send \
  -H "Authorization: Bearer $VOLANEA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":"buyer@example.net","subject":"Your receipt","html":"<p>Thanks for your order.</p>"}'

The send API reference documents up to 50 recipients, scheduled sending with sendAt, and safe retries using the Idempotency-Key header. Volanea also provides an SMTP relay for transactional sending, a reputation guard that slows sending before a poor list damages the domain, and bounce and complaint handling. These features matter when the team wants operational controls as well as a sending endpoint.

Pricing may also change how you plan recipient storage and monthly volume. Volanea’s pricing page lists Free at $0 with 1,000 email credits every month, unlimited contacts, one custom sending domain, and all 23 MCP tools, with no card required. Contact storage is unlimited and free on every plan. Starter is $5 per month for 7,500 emails, Growth is $20 per month for 50,000, and Scale is $149 per month for 200,000 emails with priority throughput.

The platform includes a full MCP server with 23 AI-agent tools on Free, Starter, Growth, and Scale, which can be useful when an AI coding agent is configuring email as part of an application build. Credits reset at the start of each billing month and do not roll over; one credit sends one email to one recipient, or two if the email has an attachment. When credits run out, sending pauses until the next month or an upgrade, with no overage billing. Those are meaningful trade-offs against managing SES quotas directly: the team gets a defined monthly allowance, while burst capacity and the credit rules need to fit the workload.

FAQ

What happens if an SES production-access request is still under review?

Until the account leaves the sandbox in that Region, sends remain limited to verified recipients and the mailbox simulator. Keep development tests pointed at verified addresses, and avoid making a release depend on sending to unverified customers before approval. If the timing is a blocker, a managed sending layer such as Volanea does not require a customer SES production-access request, though you still need to verify its sending domain.

How do I estimate SES usage for a message with CC or BCC recipients?

Count each recipient address, not each message submission. For example, a message addressed to one customer and two copied colleagues uses three recipients against the quota. Apply that calculation to the actual To, CC, and BCC recipient set your integration sends, then compare the total with the quota for the Region handling those requests.

When should I move from direct SES to a managed email platform?

Consider a managed platform when the team is spending more time assembling campaign, automation, contact, and delivery workflows than building product features. For a small application that only needs direct API sending, SES may be a good fit. If you also want campaigns, workflows, MCP tools, and a unified API, compare those needs with the platform’s monthly credit rules and supported sending setup.

Can an AI coding agent configure email through Volanea?

Volanea lists its MCP server with 23 AI-agent tools on Free, Starter, Growth, and Scale. That gives an agent a product interface for email configuration and operations rather than requiring it to construct every surrounding workflow from raw SES primitives. Keep API credentials and permission decisions under your team’s control even when an agent helps with setup.