Amazon SES at scale: deliverability and DMARC

7 June 2026 · 14 min read

Amazon SES is deceptively easy to start with and deceptively hard to run well at volume. Verifying a domain, adding three DNS records and firing your first message takes an afternoon. Sending two million transactional and marketing messages a week, through dedicated IPs, with a bounce rate under control, complaints near zero and DMARC passing on every single one of them, is a different discipline entirely. The platform gives you the raw sending capacity and a generous set of levers. What it does not give you is the operational judgement to pull them in the right order, or the warning that a misconfigured MAIL FROM subdomain will quietly leave half your mail unauthenticated while every dashboard you look at says "delivered".

This article is about everything that comes after the setup tutorial. It assumes you already have SES out of the sandbox, a verified domain, Easy DKIM enabled and a basic DMARC record published. The focus is reputation at scale: how dedicated IP pools actually behave, how the configuration set ties your sending together, how to handle bounces and complaints before they handle you, and, running through all of it, how to keep SPF and DKIM aligned so that p=reject does not start eating your own mail. If you are still at the setup stage, start with our email authentication for beginners primer and the five records that protect email, then come back.

Why scale changes the rules

At low volume on the SES shared IP pool, your reputation is mostly somebody else's problem. You inherit the aggregate behaviour of thousands of other senders sharing those IP addresses. That is usually fine, occasionally not, and almost entirely out of your hands. The trade-off is simple: low effort, low control.

The moment your volume justifies dedicated IPs, the deal inverts. Reputation becomes entirely yours. A receiving mailbox provider such as Gmail, Outlook or Yahoo now judges your IPs and your sending domain on your recent behaviour, with no crowd to hide in. One bad campaign to a stale list, one compromised API key blasting spam, one week of ignoring a rising complaint rate, and you can damage an asset that took weeks to build. Scale does not just multiply your throughput; it multiplies the consequences of every mistake and shortens the time you have to react.

Three things become non-negotiable at this point:

Segmentation. Transactional mail (password resets, receipts, alerts) and marketing mail (newsletters, promotions) must not share reputation. Transactional mail has to arrive; it is often security-relevant. Marketing mail is where complaints come from. Mixing them means a bad campaign can delay password resets.
Measurement. You cannot manage a bounce rate you are not capturing in real time. The SES console figures are rolling averages and lag reality. You need event-level data flowing somewhere you can query.
Authentication discipline. Every IP you warm and every domain you send from has to produce mail that passes DMARC with an aligned identity. Otherwise you are building reputation on a foundation that mailbox providers increasingly distrust.

Dedicated IPs: standard versus managed

SES offers two routes to dedicated IPs, and the choice shapes how much warming work you do by hand.

Standard dedicated IPs give you specific IP addresses that you lease, organise into pools and warm up yourself. SES publishes a warmup schedule, but you are responsible for ramping volume gradually so that mailbox providers learn to trust each address. You assign pools to configuration sets, so you can route, say, transactional mail through one pool of well-warmed addresses and marketing through another. This is the maximum-control option and the one large senders with their own deliverability teams tend to prefer, because pool topology is explicit and predictable.

Managed dedicated IPs are the newer, more automated path. You create a managed pool and SES decides how many IP addresses you need based on your sending patterns, scaling the count up or down as your volume moves. Crucially, it runs an adaptive, per-ISP warmup: each address is warmed in conjunction with the shared pool, and the warmup percentage for a given mailbox provider tracks your actual sending volume to that provider. Send more to Gmail, the Gmail warmup advances; let volume to a provider drop, and the warmup percentage for that provider eases back so you are not pushing cold volume through a half-trusted address. Managed pools also surface effective reputation data at the top ISPs as CloudWatch metrics and built-in dashboards.

The honest trade-off: standard pools give you deterministic control and the ability to physically isolate streams onto named addresses, at the cost of doing your own warmup maths and babysitting the ramp. Managed pools remove most of that labour and handle the awkward problem of warming an address whose volume is uneven across providers, at the cost of some transparency about exactly which address sent what. For most teams scaling past the shared pool for the first time, managed pools are the lower-risk starting point. Teams with strict isolation requirements, or who want to migrate pre-warmed IPs in from another provider, usually want standard.

Warming is a volume curve, not a date

Whichever route you take, the principle of warming does not change: mailbox providers distrust sudden volume from a new address. A dedicated IP that has never sent before, suddenly emitting 500,000 messages, looks exactly like a compromised host or a spam cannon. The fix is to ramp: start in the low thousands per day per provider, increase gradually over two to several weeks, and watch the response. If deferrals (4xx soft bounces) or complaints climb, you are pushing too hard and need to hold or back off, not press on to hit a calendar target.

Two warming mistakes recur at scale. The first is warming the IP but forgetting the domain also has a reputation: a brand-new sending domain on a warm IP still needs its own ramp. The second is warming to an average instead of to a distribution. If 70% of your volume goes to Gmail, Gmail needs 70% of the warming attention; warming uniformly across providers wastes the ramp on mailboxes you barely send to and under-warms the one that matters most. This is precisely the uneven problem managed pools are built to handle automatically.

The configuration set is the control plane

If there is one SES object worth treating as central infrastructure, it is the configuration set. A configuration set is a named bundle of rules applied to every message that references it, and at scale it is how you make sending observable and governable rather than a black box.

A configuration set lets you:

Route through a specific IP pool, so transactional mail uses your trusted addresses and marketing uses a separately warmed pool.
Attach event destinations, publishing per-message events (sends, deliveries, bounces, complaints, opens, clicks, rejects, rendering failures) to CloudWatch, Kinesis Data Firehose, SNS or EventBridge. This is the firehose of truth you build monitoring on.
Set a TLS policy, requiring (rather than merely preferring) TLS on outbound connections for streams where in-transit confidentiality is non-negotiable.
Enable reputation and suppression options, including account-level suppression list behaviour scoped to that stream.

The operational rule is simple: send everything through a configuration set, and use a different one per stream. A transactional configuration set pointed at your trusted pool with strict TLS and full event logging; a marketing configuration set pointed at the marketing pool. The instant you split streams this way, a bad marketing campaign can no longer drag down the IPs that carry password resets, and your event data is already segmented by stream when you go to analyse it.

Event destinations are your real bounce data

Do not rely on the rolling rates in the SES console as your primary signal. They are smoothed and they lag. Instead, wire a configuration set event destination to something queryable: Firehose into S3 for cheap long-term storage and Athena queries, or SNS into a Lambda that writes to your own database for live dashboards. Capture, at minimum, every Bounce, Complaint, Delivery and Reject. With per-message events flowing, you can compute a true bounce rate by the hour, by campaign, by recipient domain, and catch a Gmail-specific problem (which an account-wide average would hide) while it is still small.

Bounces and complaints: the metrics that pause accounts

SES watches two numbers above all others, and so should you. Exceeding either can get your account placed under review or paused, which at scale is an outage.

Bounce rate. A hard bounce means a permanent failure: the address does not exist, the domain does not resolve, the mailbox is closed. AWS guidance is to keep your bounce rate below 5%, and treats 10% as the level at which your account may be paused. Practically, you want to run well under 5%; a healthy list to engaged recipients sits in low single digits or below. Soft bounces (4xx) are temporary, signalling things like a full mailbox or transient deferral, and SES retries them; persistent soft bounces still indicate a problem worth investigating, especially if one provider is deferring you (a reputation warning).

Complaint rate. A complaint is a recipient hitting "report spam", reported back to SES through feedback loops with participating providers. AWS guidance is to keep complaints below 0.1%, and treats 0.5% as the danger zone. These are tiny numbers: at 0.1%, just one complaint per thousand delivered messages is your ceiling. Complaints are the single most damaging signal to reputation because they are an explicit human "this is unwanted", and Gmail in particular weighs them heavily.

Handling bounces and complaints in practice

Capturing the events is half the job; acting on them is the other half, and it is mandatory at scale.

Suppress hard bounces immediately and permanently. Never send to an address that hard-bounced. SES maintains an account-level suppression list that can auto-add bounces and complaints, and you should also keep your own copy so the suppression travels with you if you ever migrate providers. Re-sending to known-dead addresses is the fastest way to inflate your bounce rate into the danger zone.
Suppress every complainer, no exceptions. If someone reports your mail as spam, stop sending to them entirely, including transactional mail where you can, and certainly all marketing. Continuing to mail a complainer manufactures more complaints.
Validate addresses before you send, not after. Syntax checks, MX existence checks and rejecting obvious role and spam-trap patterns at signup prevent bad addresses entering your list in the first place. A bounce you never generate is the cheapest bounce to handle.
Practise list hygiene. Re-engagement campaigns and sunsetting policies (stop mailing recipients who have not opened in N months) keep your active list engaged, which lifts opens, lowers complaints and protects the reputation of the IPs carrying the mail people actually want.
Alarm on the leading edge. Set CloudWatch alarms on bounce and complaint rates well below the AWS thresholds, for example a complaint-rate alarm at 0.08% and a bounce alarm at 3%, so you are paged before SES intervenes, not after.

A subtle scale trap: a single misbehaving code path, a broken signup form letting bots inject fake addresses, a retry loop hammering a dead domain, can spike these rates fast. Per-stream configuration sets and per-domain event analysis are what let you find the offending source in minutes rather than discovering it when AWS emails you about a review.

Keeping DMARC aligned at high volume

Here is where many otherwise-careful SES deployments quietly fail. SES makes it trivially easy to send mail that "passes" SPF and DKIM in isolation while failing DMARC, because DMARC does not care that SPF or DKIM passed. It cares that at least one of them passed and is aligned with the domain in the visible From: header. Volume does not change the rule, but it changes the blast radius: a misalignment that loses a few messages at low volume loses thousands once you are at scale and at p=reject.

If alignment is unfamiliar, read DMARC alignment explained before going further. The short version follows.

SPF alignment needs a custom MAIL FROM domain

By default, SES sets the envelope sender (the MAIL FROM, also called the return-path) to a subdomain of amazonses.com. SPF will pass, because that envelope domain is authorised, but it passes for amazonses.com, not for your From: domain. That is an SPF pass with no alignment, and DMARC ignores it.

The fix is the custom MAIL FROM domain feature. You configure a subdomain you control, for example mail.example.com or bounce.example.com, as the SES MAIL FROM for your verified identity. SES then uses that subdomain in the envelope sender, and you publish the MX and SPF records SES specifies for it. Now SPF passes for a subdomain of your organisational domain, which under relaxed alignment (the DMARC default) is aligned with a From: of example.com. Two things to get right:

Use the relaxed SPF alignment mode (aspf=r, the default) so that a MAIL FROM of mail.example.com aligns with a From: of example.com. Strict mode (aspf=s) would require an exact match and break this setup.
Make sure the SPF record on the custom MAIL FROM subdomain authorises SES with the correct include (include:amazonses.com) and that you have not blown the SPF ten-lookup limit. If your root SPF is already crowded with other senders, automatic SPF flattening keeps you inside the limit without manual record surgery.

You can confirm both the envelope-level pass and alignment with our SPF checker, and verify the custom MAIL FROM subdomain resolves correctly with the DNS record checker.

DKIM alignment is your durable identity

Easy DKIM in SES signs your mail with keys SES manages, using a d= domain of your own (your verified domain), not amazonses.com. That gives you an aligned DKIM signature out of the box, which is the more robust of the two authentication methods because, unlike SPF, DKIM survives most forwarding hops intact. This matters enormously at scale, where a meaningful slice of your mail will be forwarded, run through mailing lists or relayed, all of which break SPF. For why forwarding is so corrosive to SPF and how DKIM rescues alignment, see why forwarding breaks authentication and aliases, forwarding and DMARC.

Two DKIM practices pay off at volume:

Use 2048-bit keys where your DNS provider supports the record length, for stronger signatures. Easy DKIM with BYODKIM (bring your own DKIM) lets you control key length and rotation if the managed option does not meet your policy.
Rotate keys on a schedule and confirm each new selector is live in DNS and signing before retiring the old one. Verify any selector with the DKIM checker.

Because DKIM gives you an aligned identity that forwarding does not destroy, it should be the authentication method you rely on for DMARC, with aligned SPF as a useful second pass rather than your only line of defence.

Multiple sending sources on one domain

At scale you rarely send only through SES. The same example.com might also send through a CRM, a help-desk tool, a billing platform and a corporate mail system. Each is a separate authentication source, and DMARC evaluates all of them. SES being perfectly configured does not save you if your billing provider is sending unauthenticated mail from the same domain, because your aggregate DMARC reports will show failures and you will hesitate to move to enforcement.

This is exactly what DMARC aggregate (RUA) reports are for: they tell you every IP and every source sending as your domain, and whether each one is passing aligned SPF or DKIM. Before and during your move to p=reject, feed those reports into our DMARC report analyzer so you can see SES sitting alongside every other sender and confirm that all of them, not just SES, are aligned. A common and recommended pattern is to give SES its own clearly identifiable sending subdomain (for example news.example.com for marketing), which isolates its reputation and makes its slice of the reports trivial to read.

A staged path to p=reject with SES at volume

Putting it together, the safe sequence for a high-volume SES deployment looks like this. Never jump straight to p=reject; enforce in stages and let the data confirm each step. Our done-for-you DMARC enforcement approach follows the same shape.

Authenticate fully. Easy DKIM enabled with an aligned d= domain; custom MAIL FROM configured for aligned SPF under relaxed mode. Confirm both with the DMARC checker and SPF checker.
Segment streams. Separate configuration sets for transactional and marketing, each on its own warmed pool, each with event destinations capturing bounces and complaints.
Publish p=none and collect reports. Start in monitoring mode, gather RUA data, and use the DMARC report analyzer to enumerate every source sending as your domain. Fix or remove any source that is not aligned.
Watch the operational metrics. Drive bounce and complaint rates down with suppression, validation and hygiene, and alarm below the AWS thresholds. Do not advance enforcement while either metric is trending the wrong way.
Move to p=quarantine, then p=reject, ideally with a pct ramp where appropriate, watching aggregate reports at each stage for any legitimate source you might still be missing. Once reports show 100% aligned pass across all sources and your bounce and complaint rates are healthy, full p=reject rejects spoofers without touching your real mail.

For the wider checklist of what mailbox providers now expect from bulk senders, including the one-click unsubscribe and rate requirements that sit alongside DMARC, see our requirements page, and keep the glossary handy for any term above that needs unpacking.

The honest summary

Amazon SES at scale rewards operational discipline and punishes neglect, fast. The platform will happily send millions of unauthenticated, poorly-segmented messages off a cold IP straight into the spam folder, and it will let your bounce rate climb until the account is paused. None of that is SES failing; it is SES doing exactly what you told it to.

The work that separates a deliverable SES estate from a struggling one is unglamorous and continuous: warm IPs to the right per-provider distribution, route every stream through its own configuration set, treat event-level bounce and complaint data as your real metrics, suppress dead and unhappy addresses ruthlessly, and, underneath all of it, hold SPF and DKIM in an aligned state so DMARC passes on every message before you ever reach for p=reject. Get those right and SES becomes what it is supposed to be: cheap, fast, reliable infrastructure that lands in the inbox. If you would rather not run the authentication and enforcement side by hand, that is precisely the part our DMARC product and hosted SPF flattening are built to take off your plate, so your team can concentrate on the mail itself.