Why transactional emails don't reach recipients
An "order placed" email goes into the queue in milliseconds, but email deliverability is decided in a completely different place — on the side of email providers.
The typical picture: the application reliably calls the API, the logs are clean, but some transactional emails end up in spam or bounce on entry.
The reasons are almost always the same — sending from a shared IP, no established sender reputation, no domain authentication records, links to non-existent pages, and sending to addresses that haven't opened email in a long time.
A separate category is the growth of complaints. One user clicked "this is spam" instead of unsubscribing, and the provider lowers trust in the entire domain, not just a specific address.
If such signals aren't tracked, the share of emails landing in spam filters grows unnoticed, until emails with confirmation codes and receipts start disappearing for half the base.
Blocks pile on top: some providers silently drop traffic without returning an explicit error, and in the application it looks like "email sent."
Amazon SES removes some of these problems at the infrastructure level, but it doesn't eliminate the work on reputation.
The service provides dedicated IPs, separation of streams by email type, feedback on bounces and complaints, but the configuration for a specific domain and sending scenarios needs to be built: confirm domain ownership, set up authentication, separate transactional and marketing traffic, and enable notifications about delivery events. Without this, even correctly working code doesn't guarantee that the email will arrive.
We break down how this is covered: from auditing current sends and setting up the domain to monitoring deliverability and handling complaints, so that emails reach the recipient instead of ending up in spam.
What turnkey Amazon SES setup delivers
We configure Amazon SES as the transport layer for transactional emails: order confirmations, password resets, invoices, delivery statuses.
The work is not with email templates, but with the sending infrastructure — domain records, reputation policies, and bounce handling — so the effect is measurable in numbers, not in feelings.
Deliverability and domain reputation
The key layer is sender authentication: SPF, DKIM, and DMARC policy are structured so that email providers unambiguously associate the email with the customer's domain.
We separately handle domain warm-up and separate the streams: transactional emails should not share reputation with bulk mailings.
In practice, the share of emails delivered to the "Inbox" grows from a typical 70-80% to 95%+, and spam complaints drop, because emails go only to those who are actually expecting a confirmation or an invoice.
Peak loads and monitoring
Sending goes through multiple availability zones with automatic retry on temporary failures — during a sale or mass registration, the queue does not lose emails, but processes it at a specified rate.
We separate bounce handling: hard addresses go to a blocklist, soft ones are retried on a schedule. Monitoring tracks the delivery rate, complaints, and delays for each type of email, so degradation is visible before the client notices it.
Sending methods: SMTP, API, and dedicated IPs
Connecting to Amazon SES is possible via two transports — the SMTP interface and the HTTPS API — as well as the option of dedicated IP addresses for outbound traffic.
The choice affects sending speed, integration complexity, and how quickly you hit limits as your email volume grows.
SMTP is convenient when the application already knows how to send mail and you don't want to touch the code: you plug in the host, port, and credentials, and from there it works like a regular mail server.
The API gives more control — individual responses for each email, attachments, headers, delivery statistics — but requires explicit integration into the application or a service layer.
| Option | When it fits | Limitations |
|---|---|---|
| SMTP | Quick setup, ready-made libraries, moderate volume | Harder to track the status of each email precisely |
| API | High volume, need detailed statistics and header management | Requires integration into the application code |
| Dedicated IP | Large mailings, sender reputation matters | Requires warming up addresses and consistent traffic volume |
Dedicated IPs make sense when volume is stable and address reputation is critical: other senders don't affect your deliverability. With irregular sending, the address "cools down," and emails more often land in spam — in that case, a shared pool is more reliable.
We select the option to match your load profile and configure the connection so that limits and reputation don't become a bottleneck as you grow.
How we implement Amazon SES: stages of work
Implementation starts with an audit, not with configuration.
It is important for us to understand where emails are coming from now: which service is used for sending, how templates are structured, where access keys are stored, which domains and subdomains are involved in correspondence.
At this same stage, we capture current metrics — the share of delivered emails, the frequency of landing in spam, the volume of complaints and unsubscribes. Without this baseline, it is impossible to prove that things got better after the migration.
Next comes the design of the sending scheme. We separate the streams: transactional emails (registration confirmation, access recovery, receipts) and bulk mailings go through different paths so that problems with one do not affect the other.
We configure the sending domain, add authentication records to DNS, and create separate credentials for each service — this way, if one key is compromised, the others remain secure.
- Audit of the current infrastructure. We analyze what is already working, collect delivery metrics and a list of problem areas.
- Design of the sending scheme. We determine which email streams exist, how they are separated and who is responsible for each.
- Domain and authentication setup. We add records to DNS, confirm domain ownership, and enable email signing.
- Preparation of templates and sending logic. We migrate existing emails, configure personalization and delivery error handling.
- Testing. We check delivery to real mailboxes of different providers, and observe how emails behave when the recipient is unavailable.
- Going live. We switch traffic gradually, monitor delivery and complaint metrics, and roll back to the previous path if there are deviations.
- Documentation handover. We provide regulations, the stream diagram, instructions for adding new templates and handling incidents.
After the handover, the client is left not with a "black box" but with a clear system: it is visible where each email goes, how to check delivery and what to do if the provider starts rejecting sending. Let's discuss your task — we will come back with an estimate and a work plan.
What the client receives at handover
Work with Amazon SES ends not with launching a campaign, but with handing over to the client's team a set of artifacts that allow the system to be operated, extended, and transferred to another contractor without losing context. Below is what exactly remains with you after delivery.
- Sending configurations — domains and subdomains verified in SES, production access settings instead of the sandbox, configuration sets with event routing rules (delivery, bounce, complaint, delay).
- Flow diagrams — where an email comes from (application, CRM, queue), which checks it passes through, where the result is recorded, how retries and undeliverable addresses are handled.
- Access policies — roles and keys with the minimum necessary permissions, separation of sending by environment, restrictions on direct API calls from the frontend, credential rotation.
- Domain authentication settings — SPF, DKIM, and DMARC records aligned with the sending domain so that emails don't go to spam and aren't forged in your name.
- Bounce handling procedures — address suppression rules, response to complaints, thresholds at which sending automatically stops so as not to lose domain reputation.
- Operations instructions — how to check an email's status, how to investigate an incident, what to do when deliverability drops, where to look first.
- Integration documentation — a description of connection points, request formats, email templates, and variables so that your developers can add new types of notifications on their own.
Each artifact is tied to a real task: configurations and policies — to the security and predictability of sending, diagrams and procedures — to the speed of incident investigation, documentation — to independence from the contractor.
Describe your task — we'll come back with an estimate and a plan for what will be included in the handover in your specific case.
Case study: how deliverability grew after setting up Amazon SES
The client is a service with a personal account and notifications: registration confirmation, access recovery, order statuses. Emails were sent directly from the application server, and by the time of contact, roughly every third one was not reaching the recipient.
Worse, some were landing in spam at popular email providers, and a spike in complaints after a mailing to an old base put the entire domain reputation at risk — even correct transactional emails stopped being accepted.
What it was like before implementation
Diagnostics revealed three causes. Sending happened synchronously in the request thread: a slow response from the mail server slowed down checkout, and timeouts turned into lost emails.
There was no separation of streams — marketing mailings and transactional notifications went from the same domain and damaged each other's reputation. And bounces were not tracked: the team learned about undelivered emails from the users themselves.
What was done
Sending was moved to Amazon SES and the streams were separated: transactional emails went through a separate subdomain with a dedicated reputation, mailings — through another.
An asynchronous queue was set up: the application submits a task and does not wait for the mail server, and retries during temporary failures are performed automatically.
Deliverability feedback was connected — hard bounces and spam complaints automatically go into the exclusion list so that the address no longer receives emails.
Result in metrics
| Metric | Before | After |
|---|---|---|
| Share of delivered emails | ~68% | 99%+ |
| Emails in spam at major providers | regularly | isolated cases |
| Response time during checkout | depends on the mail server | does not depend |
| Bounce handling | manually, based on complaints | automatically |
Monitoring was set up separately: if the share of bounces or complaints exceeds a threshold, the team receives a signal before the domain reputation suffers.
Rolling back to the previous sending scheme remains possible — the configuration is stored in the repository and is deployed with a single command.
How is Amazon SES different from other email services?
Amazon SES is a construction kit, not a ready-made email service. Most alternatives sell a convenient panel: templates, an editor, ready-made scenarios. SES provides a programmatic interface and delivery infrastructure, and you build the logic yourself.
Hence the difference in flexibility: with ready-made platforms you work within their model of subscribers and campaigns, while in SES you work within your own.
For transactional emails this is an advantage: an order confirmation, access recovery, or receipt goes out from your system directly, without an intermediary layer that imposes its own data structure.
The cost of ownership is structured differently. Ready-made services charge for volume and for features you may not use. SES bills for delivery and related services, and everything else is on your side.
At volumes of tens of thousands of emails per month, the difference in expenses becomes noticeable, but engineering work appears: warming up domain reputation, monitoring complaints and unsubscribes, analyzing the causes of non-delivery. At the same time, storage and forwarding costs stop growing linearly with the number of emails.
Control is the main difference. You own the sending domain, configure email authentication, see every delivery event, and decide for yourself what to do with bounces. In closed services, part of this logic is hidden, and data about subscriber behavior remains with the platform. In SES, delivery events come to you, and you build analytics on your own data.
There is also a cost: SES doesn't "get set up in an evening." You need domain verification, configuration of authentication records, and separate work on reputation and error handling.
If you need to send to a database with ready-made scenarios and support, a ready-made platform is more convenient. If you need transactional emails tailored to your product with full control over delivery, SES wins on flexibility and cost of ownership.
Common technical questions about Amazon SES
Let's go through the questions that most often come up before the start: they concern not "turn it on and send," but how the service behaves under load and what happens when a recipient complains.
How quickly are sending limits lifted?
An account starts in the sandbox with a hard ceiling and the ability to write only to verified addresses. We immediately file a request to move into production mode with a description of the scenario: types of emails, expected volumes, how we build the list.
After that, the limit grows based on actual quality — a low bounce and complaint rate opens the next threshold faster.
In parallel, we add handling in the code for the service's response when the quota is exceeded, so that emails aren't silently lost but go into a queue and are re-sent.
Why warm up IPs and how long does it take?
A new address with no reputation, when suddenly starting at full volume, is almost guaranteed to land in spam. Warming up is a controlled curve: we start with a small share of the total flow and increase it day by day, monitoring the spam placement and complaint rate.
For transactional emails (confirmations, receipts, access recovery) the curve is shorter, for bulk mailings it's longer. If you already have dedicated addresses with history, we migrate them and there's no need to warm up from scratch.
What to do about complaints and unsubscribes?
A complaint is a signal that the service factors into reputation, so it needs to be handled automatically. We set up receiving notifications about complaints and unsubscribes, adding addresses to a stop list, and blocking repeat sends to them.
Separately, we distinguish hard bounces (non-existent address — we clean the list) and soft bounces (temporary unavailability — we retry with a delay). This way the complaint rate stays within a safe corridor, and the list doesn't get polluted.
How does this fit into the current infrastructure?
Integration doesn't require rewriting the application: we connect the service as a separate sending channel, and migrate the existing templates and email logic.
We configure the domain, verify ownership, set up authentication records so that emails pass authenticity checks, and create separate streams for transactional and bulk sends.
We consolidate delivery, bounce, and complaint logs in one place so that an email's status is visible without manual digging.
Describe your sending scenario — we'll come back with an estimate and an integration plan.
Let's discuss your Amazon SES integration task
Amazon SES integration is rarely just "connect the API": almost always, verified domains and senders, DMARC policies and signature alignment, dedicated IP pool warm-up, and bounce handling via SNS come up.
The sooner we review your sending setup, the more accurately we can estimate the scope of work — with no surprises at launch.
To come back with an estimate and a plan, we need a minimum of input:
- what types of emails you send: transactional (confirmations, receipts, password resets) or bulk mailings;
- current volume and peak load — how many emails per day and how fast it's growing;
- which domains and addresses are already verified in Amazon SES, whether there is a dedicated pool;
- where sending comes from now: your own server, a third-party service, an application queue;
- how the domain's DNS records are configured — SPF, DKIM, DMARC;
- what happens to undelivered emails: whether there is bounce and complaint handling;
- logging and reporting requirements — whether you need statistics exported to your system.
Based on this data, we build a plan: Amazon SES configuration for your sending profile, a warm-up strategy, delivery event handling, and the procedure for switching from your current channel.
We send the estimate and timeline after a short review — describe your task, and we'll come back with a concrete proposal.
