Setting Up AWS SES: Why Emails Land in Spam
An email that lands in spam means a password reset that never arrived, a lost registration, and a customer who never learned about an invoice. Sending formally works: the request goes out, the server responds, and delivery reports show zero errors. What breaks is not the code but the domain reputation and the message signature.
A typical cause is that the domain is not signed with DKIM, there is no selector in DNS, and SPF ends with a softfail. The provider receives an email without a cryptographic signature and without sender domain alignment, so it goes to spam or quarantine.
This is not fixed by editing a template but by configuring AWS SES: domain verification, publishing selectors, enabling signing, and a DMARC policy at least in monitoring mode with reports.
The second source is complaints and rejected emails. An address that no longer exists produces a hard bounce on every send; while bounces are not processed, the error rate grows and the account is moved to a restricted mode with reduced sending speed.
Manual sending from the console or a script without subscribing to delivery, bounce, and complaint notifications means we do not know who exactly dropped off and continue spending reputation on the same list.
Email deliverability is built on logic, not luck: a retry queue for temporary bounces, immediate removal of an address on a hard bounce, and unsubscribe on complaint. For transactional emails, this is the mandatory minimum — otherwise metrics depend on chance. We break down how to build this step by step.
What Correct AWS Setup Delivers: Deliverability and Domain Reputation
Correctly configured DKIM signatures and a DMARC policy are not a formality: recipients stop marking the stream as suspicious, and the share of emails that reach the inbox stops jumping from campaign to campaign.
Domain reputation becomes a predictable metric rather than a result of luck, and it shows the effect of each configuration change.
Sender warm-up removes the main cause of failures at launch: sending volume is increased gradually, and reputation does not collapse from a sudden spike.
Separately, the share of emails going to spam among major recipients is monitored — with steady warm-up, it stays within tenths of a percent.
Email delivery time is reduced to minutes and levels out across all segments of the list; if the queue stalls, it is clear at which stage.
Bounce handling works automatically: hard bounces remove an address from the active list, soft bounces are retried with increasing delay, so manual list cleaning disappears as a recurring task.
The spam complaint rate remains below the threshold at which the provider starts cutting the entire stream. For each campaign, it is visible which segment causes a spike — it is disabled before all sending for the domain drops.
Sending Modes: Shared Gateway, Your Own Domain, or Dedicated Channel
Before launching campaigns, AWS SES offers three modes, and the choice between them determines how much work will fall on the infrastructure later. By default, the account is in the test sending mode: emails are sent only to verified addresses, and sending limits are minimal. Production mode opens after domain verification and authentication setup — SPF, DKIM, and DMARC.
| Option | When It Fits | Limitations |
|---|---|---|
| Shared sending gateway | Pilot, small volume of transactional emails | Address reputation is shared with other senders, limits are shared — deliverability depends not only on you |
| Your own domain with verification and DKIM | Regular emails from your brand, reputation control needed | DNS record setup and warm-up; an error in DKIM or a mismatch with the DMARC policy stops sending |
| Dedicated sending channel | Large volumes, strict deliverability requirements | Warm-up and a constant email stream are needed; a pause in sending drops address reputation |
What you pay for each mode: the shared gateway saves warm-up time but blurs responsibility for reputation; your own domain gives predictability while requiring DNS discipline; the dedicated channel removes dependence on neighbors but does not forgive downtime and volume spikes.
In all modes, bounce handling and complaint processing are configured separately — without them, sending limits are cut automatically, and the campaign stops midway.
Implementation Stages: From DNS Record Audit to Handover of Policies
The order of work is fixed: we assess the email infrastructure, then configure sending and signing, and only then enable strict policies. A skipped audit results in record conflicts and spam.
- DNS and current email audit. We check SPF against all third-party senders, MX, existing DKIM selectors, TTL, and subdomains. We record who else sends emails on behalf of the domain.
- Domain scheme and sending configuration. In AWS SES, we set a subdomain for campaigns, the region, the daily sending limit, and behavior when it is exceeded. We separate transactional and marketing streams so that the reputation of one does not sink the other.
- DKIM signing. We publish the public key as a CNAME record, enable signing, and immediately prepare a second selector for rotation — switching without downtime.
- SPF, MAIL FROM, draft DMARC. We configure a dedicated subdomain for sender alignment, publish DMARC in monitoring mode with reports: first we collect statistics rather than block.
- Bounce and complaint handling. Hard bounces go straight to the stop list, soft bounces — with retries. Otherwise, sends to nonexistent addresses quickly eat up reputation.
- Signature verification and delivery monitoring. Test emails to external mailboxes, parsing headers for DKIM and SPF alignment, alerts on bounce and complaint rates.
- Handover of policies. Documentation: key rotation, adding senders to SPF, the procedure for tightening DMARC, and incident handling.
After that, the team adds senders itself and tightens the policy based on report data.
What You Keep After Handover: Records, Configurations, Policies
Handover is not the moment when "emails go out." You are left with a set of artifacts that the team can use to change the domain, add new email streams, and handle incidents without us.
Every document is tied to the actual configuration in the sending service, not written "inspired by" it, so there are no discrepancies between the description and production.
- A set of mail records for the domain: SPF values, DKIM public keys, and the DMARC policy with an explanation of what each tag is responsible for and in what order to change them when switching providers.
- Routing scheme: which streams go through the main domain, which through a subdomain, how transactional and service emails are separated, and where replies are returned.
- Signing policy: key owner, rotation period, and the procedure for reissuing without a delivery outage window.
- Bounce handling policy: handling of hard and soft errors, thresholds after which an address goes to the suppression list, and the procedure for removal.
- Reputation management rules: sending limits, warm-up of new streams, and what to do when deliverability drops.
- Support instructions: how to determine the cause of non-delivery from email headers and which log to check.
- Access matrix: where keys are stored, who has the right to edit records, how to transfer this when the responsible person changes — plus an acceptance checklist from test scenarios.
Case Study: Transactional Emails Stopped Going to Spam
The client came with transactional emails: registration confirmation, password reset, receipts.
About 62% of sends reached the Inbox, the rest settled in spam and on the Promotions tab, and the bounce rate stayed at 8% — the address list had not been cleaned for years, and support handled every bounce manually.
What We Changed in the Stream
We separated transactional and promotional streams into different subdomains: promotional campaigns no longer dragged down the reputation of receipts.
On sending via Amazon SES, we enabled DKIM signing and a DMARC policy with reports, and put bounces and complaints into automation — an address with a hard bounce immediately goes to the exclusion list, and a complaint raises a notification for the on-call person. Outgoing volume was increased gradually so that reputation did not sag under load.
A month later, 98–99% of emails reach the Inbox, bounces are 0.8%, manual reviews dropped from about fifty requests per week to three or four, and complaint response went from two days to an hour.
Complaints used to arrive in a shared mailbox and get lost; now they are automatically tied to the stream and address.
The hidden cost was repeat contacts: a password reset that did not arrive meant a support ticket and a customer who did not return. Now such failures are visible in deliverability metrics before they turn into a stream of complaints.
What to Do If the Domain Is Already Deployed and Some Emails Are Rejected?
Partial delivery almost always means not a broken email system but incomplete signature configuration.
DKIM may be enabled only on one stream — for example, on emails from the CRM — while registration and billing notifications go through another relay with no signature at all, and those are the ones that end up rejected.
The first step is not to change settings but to break bounces down by sending stream and look at the Authentication-Results headers at recipients.
Next, we check alignment: the domain in the From field must match the domain in the DKIM signature and in the SPF record. If the signature is from a technical subdomain and the email is sent from the main address, a strict DMARC policy will reject it even with a valid signature.
Second is the policy itself: in monitoring mode it only collects reports, while in quarantine and reject modes it starts filtering out everything unaligned, and this happens suddenly if the domain is already deployed and no one has read the statistics.
Bounces and spam complaints are the second cause of partial delivery. Without processing them, addresses with errors remain in the list, retries accumulate bounces, and providers start cutting the entire domain rather than individual addresses.
Amazon SES delivers bounce and complaint events as a separate stream, so the list is cleaned automatically rather than manually from logs.
The transition to full signing is done without stopping sending.
First we sign all streams and configure a separate subdomain for bulk campaigns, then for several weeks we accumulate reports, and only after that do we tighten the policy in stages — from monitoring to quarantine and beyond. At each step, it is visible which sources are not yet aligned.
While the policy is being tightened, new emails go out with full signing and a cleaned list. Ultimately, the rejected share is determined by list quality, not by domain settings.
Technical Concerns: Reputation, Limits, and Bounce Handling
Limits in Amazon SES are not static: the daily quota and sending rate grow along with reputation, and at the start they are minimal. Domain warm-up, a retry queue, and notification when approaching the quota keep campaign peaks from hitting a rejection.
Reputation rests on three indicators: bounce rate, complaint rate, and email authenticity. DKIM signing, aligned SPF, and a DMARC policy are not a formality but a condition under which major email providers accept emails into the Inbox.
Emails Hit the Sending Limit — What Happens?
Exceeding the rate limit is returned by the service as a throttling error, and exhausting the daily quota is returned as a rejection. The queue with increasing delay retries such emails rather than losing them; a notification arrives before the campaign starts to slow down.
How Do You Know an Address Has Been Blacklisted?
We monitor public lists and delivery reports: growth in bounces of a particular class and a drop in open rate are visible before the provider starts rejecting the entire stream.
If it happens — a delisting request, a pause on the problem stream, and investigation of the complaint source.
Recipients Complain About Spam — How Critical Is That?
A complaint weighs noticeably more than a regular bounce. That is why confirmed opt-in only, a visible unsubscribe link in every email, and separate streams for transactional and marketing sends — complaints about a campaign do not drag down confirmation emails.
Who Maintains Authentication Records After Handover?
DKIM keys are rotated, the DMARC policy moves from monitoring to quarantine and reject, and aggregate reports are reviewed — this shows who else sends email from your domain.
We hand over the record scheme, notification settings, and rotation policy: the team manages this itself or remains on support.
Let's Discuss Your Task: We'll Come Back with an Estimate and Implementation Plan
To come back with an estimate of the work rather than general wording, we need enough source data on the domain and email streams. All of this is collected in one pass through the DNS zone and sending panel, without stopping current campaigns.
- domains and subdomains for sending, current records in the zone — SPF, DKIM, DMARC, and the modes set for them;
- volumes: emails per day and per month, peak spikes, share of transactional and bulk campaigns;
- current sender and reasons for migration — spam placement, complaints, blocking of recipient addresses;
- how bounces are currently handled: who reviews hard and soft bounces, whether there is a delivery log and event notifications;
- requirements for consent and storage of recipient data, audience geography, restrictions on email content;
- templates, signatures, click tracking links, and branding rules in the email body;
- access to the account or readiness to grant a limited-privilege role for the duration of the work.
Based on this data, we assemble an implementation plan: the sequence of stages, what is required from your side at each one, and which checks confirm the result — from domain verification to reviewing the first bounces and complaints.
Discuss your task with engineers who run Amazon SES in production: describe the context, volumes, and current problems — we will come back with an estimate and plan.