Guide
Amazon SES deliverability: stop landing in spam.
How SES reputation actually works, why DMARC fails on SES and how to fix it, what Gmail and Yahoo now demand from bulk senders, and the monitoring routine that keeps your mail in the inbox — and your account off AWS's review list.
Updated July 14, 2026 · 18 min read
Reputation
How SES reputation actually works
Deliverability on SES is two reputations stacked on top of each other. The first is the one mailbox providers hold about your domain and sending IPs — that's what decides inbox versus spam folder. The second is the one AWS holds about your account — that's what decides whether you get to keep sending at all. Most SES deliverability advice ignores the second one until an "account under review" email arrives. Don't be that sender.
AWS tracks two account-level metrics continuously: your bounce rate (hard bounces as a percentage of sends) and your complaint rate (recipients who click "mark as spam", as a percentage of sends to providers that report complaints). Both are computed over a rolling window of your recent sending and shown on the SES reputation dashboard (Account dashboard in the console). If you use configuration sets, SES also tracks these metrics per configuration set — which is exactly why you should route different mail streams (transactional, marketing, notifications) through different sets: one misbehaving campaign stays visible and contained instead of blending into your account average.
As of July 2026, the thresholds work roughly like this:
| Metric | Healthy | Account review | Sending pause risk |
|---|---|---|---|
| Bounce rate | Under 2% | Approaching ~5% | ~10% and beyond |
| Complaint rate | Under 0.05% | Approaching ~0.1% | ~0.5% and beyond |
"Under review" means AWS is watching and expects you to find and fix the cause; keep climbing and they can pause your account's sending entirely. The exact numbers are guidance, not a published contract — AWS evaluates accounts individually — but the practical rule is simple: alert yourself at half the review thresholds (2.5% bounces, 0.05% complaints) so you're fixing problems while they're still yours to fix.
SES also offers Virtual Deliverability Manager (VDM) — an add-on ($0.07 per 1,000 outbound messages as of July 2026) with two halves: a metrics view that breaks delivery, open, and complaint data down by ISP and sending identity, and an advisor that flags concrete problems like missing DMARC or DKIM misconfiguration on your identities. It's genuinely useful if you'd rather not build the same views from raw events; the data underneath is the same configuration-set event stream either way.
One more thing reputation depends on that isn't a metric: your sending quota. Reputation problems and quota problems compound each other — a paused or throttled account backs up mail, and blasting the backlog when you resume makes the metrics worse. See our guide to SES sending limits for how quotas grow and shrink with behavior.
Authentication
DKIM, SPF alignment, and DMARC — and why DMARC fails on SES
Authentication is the price of admission. Gmail, Yahoo, and Microsoft treat unauthenticated mail as presumptively suspicious, and since 2024 the big providers require it from bulk senders. On SES there are three pieces, and the order matters. (If you're setting up from scratch, our SES setup guide walks each step with the exact console clicks.)
DKIM: three CNAMEs, managed keys
Easy DKIM is enabled when you verify a domain identity: SES generates three CNAME records that delegate DKIM key publication to Amazon, which signs every message and rotates keys automatically. This is the single most important record set you'll publish — DKIM is the signature that survives forwarding and the one mechanism that can carry DMARC on its own. Verify the same domain you put in the From address; a signature for a different domain authenticates the mail but doesn't align (more on that in a moment).
SPF alignment: the custom MAIL FROM domain
By default SES sends with an amazonses.com MAIL FROM (envelope sender). SPF passes — but for Amazon's
domain, not yours. DMARC doesn't care whether SPF passed; it cares whether
SPF passed for a domain that matches your From domain. To get that, configure a custom MAIL FROM subdomain on your
identity (convention: mail.yourdomain.com) and publish the two records SES gives you:
mail.yourdomain.com MX 10 feedback-smtp.us-east-1.amazonses.com
mail.yourdomain.com TXT "v=spf1 include:amazonses.com ~all"DMARC: publish, monitor, tighten
DMARC ties the other two together: it tells receivers what to do
with mail from your domain that fails aligned authentication, and it
gets you aggregate reports on everything sending as you. Publish a
TXT record at _dmarc.yourdomain.com:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
Start at p=none (monitor only),
read the rua aggregate reports
for a few weeks to confirm all legitimate mail passes, then graduate to
p=quarantine and finally p=reject. A domain parked at p=none forever
satisfies the bulk-sender checkbox but protects nobody from spoofing.
Why "DMARC fail" happens on SES — and the fix for each cause
DMARC passes if either SPF or DKIM passes with alignment. When it fails on SES, it's almost always one of these three:
- 1 No custom MAIL FROM, so SPF never aligns. The default
amazonses.comenvelope sender means SPF passes for Amazon, not you — and if DKIM then hiccups or is misconfigured, DMARC has nothing aligned left and fails. Fix: set the custom MAIL FROM domain (MX + TXT above). Your mail then passes DMARC two independent ways. - 2 DKIM signs a different domain than your From address. Common when you verified
notifications.yourdomain.combut send Fromyourdomain.com, or send through a verified email-address identity on a domain you never verified. The signature is valid but unaligned. Fix: verify the exact From domain as a domain identity with Easy DKIM and send from it. (Subdomains align under DMARC's default relaxed mode — the failure case is signing with an entirely different domain, likeamazonses.com's own signature being the only one present.) - 3 Forwarding. When a recipient's server forwards mail (university addresses, distribution lists, alias services), the new hop sends from its own IP, so SPF breaks in transit — nothing you can do prevents it. Fix: make sure aligned DKIM is solid, because the DKIM signature travels with the message and survives most forwarding. This is why DKIM-only DMARC passes are normal in your reports and why you should never rely on SPF alone.
Diagnose a specific failure by opening the message in Gmail ("Show
original") or reading your DMARC aggregate reports: they show
exactly which mechanism passed, which failed, and for which domain.
If you see dkim=pass with a domain
that isn't yours and spf=pass for
amazonses.com, you're looking
at causes 1 and 2 at the same time.
The New Rules
Gmail and Yahoo bulk-sender requirements
In 2024, Gmail and Yahoo turned long-standing best practices into enforced requirements for bulk senders — roughly, anyone sending 5,000 or more messages a day to Gmail addresses, though the safe assumption is that the rules apply to any meaningful sender. Mail that misses them gets throttled, rejected with authentication errors, or quietly filed as spam, no matter how healthy your SES account metrics look. As of July 2026 the requirements are:
- Authenticate with both SPF and DKIM — and publish a DMARC record (at least
p=none) with a From domain that aligns with SPF or DKIM. On SES that means Easy DKIM plus the custom MAIL FROM domain, exactly as above. - One-click unsubscribe for marketing and promotional mail:
List-UnsubscribeandList-Unsubscribe-Postheaders per RFC 8058, honored within two days. A footer link alone no longer qualifies. SES passes headers through — your sending code or platform has to add them. - Spam rate below 0.3% as measured in Google Postmaster Tools — and Google advises staying under 0.1% to avoid any impact. Note this is Gmail's measurement of Gmail users marking you as spam; it's related to, but not the same as, your SES complaint rate.
- Infrastructure basics: valid forward and reverse DNS for sending IPs (Amazon handles this on shared IPs) and no impersonating Gmail From addresses.
Yahoo enforces materially identical rules. The practical takeaway for SES senders: authentication is table stakes, the unsubscribe headers are your job because SES won't add them for you, and Postmaster Tools is a required monitoring surface, not an optional one.
Diagnosis
Why SES mail lands in spam — and the fixes that actually work
"Amazon SES goes to spam" is the complaint; the cause is almost never Amazon. Work through these in order — they're ranked by how often they're the real problem.
1. Incomplete authentication
Missing custom MAIL FROM, missing DMARC, or DKIM on the wrong
domain. This is the most common cause and the cheapest to fix —
six DNS records, covered in the section above. Verify with
Gmail's "Show original": you want spf=pass, dkim=pass, and dmarc=pass, with SPF passing on your MAIL FROM domain.
2. Your domain reputation, not the shared IPs
On SES shared IPs, the IP reputation is Amazon's problem and it's generally fine — occasionally a pool takes a hit from a bad neighbor, but it recovers, and modern filtering weighs domain reputation far more heavily anyway. Your domain's history is yours alone: a brand-new domain has none (warm it up gradually), and a domain that's been blasting stale lists has a bad one (only time and consistently good behavior repair it). Check where you actually stand in Google Postmaster Tools before assuming the IPs are at fault.
3. List hygiene
Old addresses, purchased lists, and signup forms without confirmation all produce bounces (which burn your SES metrics) and spam-trap hits (which burn your domain at the ISPs, silently). Fixes: double opt-in at capture, validate syntax at entry, never import a list you can't trace to explicit consent, and re-permission rather than resume when a list has gone cold for months.
4. Engagement
Gmail's filtering is heavily behavioral: opens, replies, and "move to inbox" help; deletion-without-reading and ignoring hurt. Sending less mail to people who want it beats sending more mail to people who tolerate it. Segment by engagement, send your best content to your most engaged users, and apply a sunset policy (below) to the rest.
5. Content signals
Content matters less than reputation, but it still matters at the margin: link shorteners and mismatched link text, image-only emails, ALL-CAPS urgency, sloppy HTML, and From names that don't match the domain all add suspicion. Plain, honest email that looks like what it is consistently outperforms clever email that looks like spam.
One structural fix worth calling out: separate your mail streams. Send marketing from a subdomain (e.g. news.yourdomain.com) and transactional from another (e.g. mail.yourdomain.com), each with its own configuration set. If a campaign damages the
marketing subdomain's reputation, your password resets keep landing.
Feedback Loops
Bounces, complaints, and suppression
Every bounce and complaint is SES telling you something; the senders who get in trouble are the ones who don't listen. The mechanics: attach a configuration set to your sends with an event destination — SNS for simple fan-out or EventBridge for routing to Lambda and beyond — delivering bounce and complaint events in near real time. Consume them, record them, and act on them:
- Hard bounce (permanent — address doesn't exist): suppress immediately and permanently. Retrying a hard bounce is pure reputation damage.
- Soft bounce (transient — full mailbox, greylisting): retry within reason, but suppress addresses that soft-bounce persistently across sends.
- Complaint (recipient marked you as spam): suppress immediately, permanently, everywhere. A complainer who keeps getting mail is how complaint rates spiral.
SES also maintains an account-level suppression list that automatically catches hard bounces and complaints — confirm it's enabled for both reasons in your account settings (it is by default on newer accounts). It's a safety net, not a substitute: it only stops SES from re-sending, it doesn't inform your application, sync to your marketing segments, or protect you if you later send the same list through another provider. Keep your own suppression records too.
Two policies prevent most bounce disasters before they start. First: never mail a stale list. Addresses decay at roughly 20–30% per year as people change jobs and abandon inboxes; a list untouched for a year is a bounce bomb, and "warming it back up" without re-permissioning is how accounts end up under review in a single afternoon. Second: run a sunset policy — after a defined stretch of no engagement (say, 90–180 days and several ignored sends), send a re-engagement message, and if it too is ignored, stop mailing that address. It feels like shrinking your list; it's actually concentrating your reputation on the people who count.
Infrastructure
Dedicated IPs: when they help, when they hurt
The instinct when deliverability dips is to buy a dedicated IP and "control your own reputation." Usually that's solving the wrong problem. On shared IPs, Amazon curates the pool's reputation and your deliverability rides on your domain reputation — which is where your problem almost certainly lives, and which follows you to a dedicated IP anyway.
A dedicated IP helps when…
- You send sustained, steady volume — typically hundreds of thousands of emails per month, every month
- Your hygiene is already excellent and you want full isolation from pool neighbors
- You need IP allow-listing with enterprise recipients, or a compliance regime demands attributable IPs
A dedicated IP hurts when…
- Your volume is low or bursty — ISPs distrust IPs without a consistent history, so quiet weeks reset your standing
- You skip warm-up — a cold IP sending full volume on day one looks exactly like a spammer's fresh IP
- You're buying it to escape a domain-reputation problem — the problem transfers with the domain
If you do go dedicated: SES offers standard dedicated IPs (roughly $25/month per IP as of July 2026, with a warm-up you manage or SES's automatic warm-up over several weeks) and dedicated IPs (managed), which handle warm-up and scaling for you at a usage-based price. Warm-up means ramping volume gradually — start with your most engaged recipients, increase steadily over 2–6 weeks, and keep the shared pool as overflow until the IP carries your full volume. For everyone else: stay on shared IPs, spend the money on list hygiene, and revisit the question when volume justifies it.
Operations
The monitoring routine that catches problems early
Deliverability problems are cheap to fix on day one and expensive on day ten. A workable routine, in increasing order of effort:
- Daily Bounce rate, complaint rate, delivery rate — broken down by sending domain and recipient ISP, not just the account total. Problems start in a segment: one template misfiring, one domain's DNS broken, Gmail alone deferring you. An account-level average hides all of these until they're big. Source the data from your configuration-set events, VDM metrics, or CloudWatch.
- Daily Alerts, not dashboards, for the thresholds. Alarm at half of AWS's review levels — 2.5% bounces, 0.05% complaints — plus a delivery-rate drop alarm per ISP. If your first notification about a bounce spike comes from AWS, your monitoring failed.
- Weekly Google Postmaster Tools: spam rate (keep it under 0.1%), domain reputation, and authentication success for each sending domain. This is Gmail's own scoreboard — it sees things your SES metrics can't, like spam-folder placement that generates no bounce and no complaint.
- Weekly DMARC aggregate reports — confirm alignment holds and nothing unauthorized is sending as your domain. A parser service (or a quiet mailbox you actually read) beats letting XML pile up.
- Per send Seed testing before large or changed sends: deliver to your own test accounts at Gmail, Outlook, and Yahoo (or a seed-list service) and check where the message lands and that all three authentication results pass. New template, new segment, new domain — seed it first.
None of this is glamorous, and all of it is the difference between senders who catch a bad import at 200 bounces and senders who explain themselves to AWS Trust & Safety at 20,000.
The Shortcut
Or: let SendOps run the routine for you
Everything in this guide is doable by hand — it's what SendOps is built from. The difference is that SendOps does it continuously, in your own AWS account, from the same SES event stream you'd wire up yourself.
Deliverability dashboards that segment
Bounce, complaint, and delivery rates broken down by domain, ISP, and template — so "Gmail started deferring the digest template on Tuesday" is a chart, not a forensic investigation. See SendOps observability.
Alerts at half the review thresholds
Notifications fire when bounce or complaint rates cross half of AWS's review levels — so you're fixing the cause while your account is still in good standing, not negotiating after a pause.
Suppression handled automatically
Hard bounces and complaints are suppressed the moment the event arrives — synced across transactional and marketing sends, visible and exportable, so no list in your system ever re-mails a known-bad address.
Consent and one-click unsubscribe, built in
Broadcasts through SendOps email marketing carry RFC 8058 one-click unsubscribe headers and respect consent state automatically — the Gmail and Yahoo requirements are the default, not a checklist.
It starts on the free plan, and because everything runs against your own SES account, nothing here locks you in — the reputation you build is attached to your domain and your AWS account, exactly as it should be.
FAQ
Amazon SES deliverability, answered
Why are my Amazon SES emails going to spam?
Almost never because of SES itself — Amazon's shared IPs are generally well maintained. The usual causes are incomplete authentication (no custom MAIL FROM, no DMARC record), a weak or brand-new domain reputation, stale lists generating bounces and complaints, and low engagement teaching Gmail your mail is ignorable. Fix authentication first, then list hygiene, then check Google Postmaster Tools to see how Gmail actually rates your domain.
What bounce rate gets you suspended on SES?
As of July 2026, AWS places an account under review when its bounce rate approaches roughly 5% or its complaint rate approaches roughly 0.1%, and can pause sending entirely if rates climb well beyond that (roughly 10% bounces or 0.5% complaints). These are account-level metrics computed over your recent sending, not per campaign. Healthy senders stay under 2% bounces and 0.05% complaints and alert themselves at those levels — half the review thresholds — so they act long before AWS does.
How do I fix DMARC failures on SES?
DMARC needs just one aligned pass — SPF or DKIM — so find which one is failing. The most common SES cause is the default amazonses.com MAIL FROM: SPF passes for Amazon's domain, not yours, so it never aligns. Fix it by configuring a custom MAIL FROM domain (an MX and a TXT record). Second: your DKIM signature is for a different domain than your From address — verify the From domain itself with Easy DKIM and send from it. Third: forwarded mail breaks SPF in transit — you can't prevent that, but an aligned DKIM signature survives forwarding and keeps DMARC passing.
Do I need a dedicated IP on SES?
Most senders don't. SES shared IPs are managed by Amazon and perform well for senders with good hygiene, and on shared IPs your deliverability rides mostly on your domain reputation, which you control. A dedicated IP only makes sense at sustained, steady volume — typically hundreds of thousands of emails per month — and it requires weeks of gradual warm-up before it helps. At low or bursty volume a dedicated IP actively hurts: too little consistent mail means the IP never builds a reputation at all.
What are Gmail's bulk sender requirements?
Since 2024, senders of roughly 5,000+ messages per day to Gmail must authenticate with both SPF and DKIM, publish a DMARC record (p=none is enough to start) with an aligned From domain, include one-click unsubscribe (RFC 8058 List-Unsubscribe headers) in marketing mail and honor it within two days, and keep the spam rate reported in Google Postmaster Tools below 0.3% — ideally under 0.1%. Yahoo enforces materially the same rules. Miss them and Gmail throttles or rejects your mail regardless of how clean your SES account looks.
How do I monitor SES deliverability?
Watch three numbers daily: bounce rate, complaint rate, and delivery rate — broken down by sending domain and recipient ISP, because problems almost always start in one segment before they show account-wide. Get the data from configuration-set event destinations or Virtual Deliverability Manager, check the SES reputation dashboard for account status, and register your domains in Google Postmaster Tools for Gmail's view of your spam rate and reputation. Set alerts at half of AWS's review thresholds (2.5% bounces, 0.05% complaints) and run seed tests before large sends.
Get Started
Keep your SES mail in the inbox
Deliverability dashboards by domain, ISP, and template. Alerts before AWS notices. Automatic suppression and one-click unsubscribe built in. Free plan, your AWS account, your reputation.