SES accepts my send, says success, but the email never actually goes out
The SES API returns a clean success, yet the message never arrives and later shows as a Permanent bounce with subtype Suppressed. The address was on a suppression list from an earlier hard bounce (yours or another SES customer's), so SES silently drops it instead of attempting delivery, even for a valid, active mailbox.
The fix
Confirm the cause: a Permanent bounce with bounceSubType Suppressed after a clean API success means the address was suppressed. Check your account-level list with GetSuppressedDestination (or ListSuppressedDestinations, or the Suppression list page under Configuration), and if a known-good address is there, remove it with DeleteSuppressedDestination. The address may instead be on SES's global list, which you cannot query or edit; those entries expire on their own within up to 14 days. Since your account-level list supersedes the global list, ensure the address is not on your account-level list and resend, but do not disable suppression wholesale or turn off complaint suppression, because re-mailing complainers damages reputation faster than bounces.
One bad marketing blast got our account paused and now our password resets and receipts are down too
SES tracks bounce and complaint reputation at the whole-account level, so one low-quality marketing campaign that spikes complaints can put the account Under review or Paused. That stops transactional mail like password resets, receipts, and 2FA riding on the same account.
The fix
Isolate the reputation, not just the IP. Separate dedicated IP pools in one account do not protect you, because the Under review and Paused state is triggered by account-wide bounce and complaint rates, so a marketing spike still pauses transactional mail on the same account. To truly isolate the pause trigger, use Tenant Management (GA August 2025), which tracks reputation per tenant and can auto-pause only the offending tenant, or run marketing and transactional in separate AWS accounts. Give each stream its own configuration set with bounce and complaint event destinations so you can see which stream is degrading before AWS pauses anything.
Gmail still shows 'via amazonses.com' next to our name even after we set up the custom MAIL FROM
Senders expect a custom MAIL FROM domain to remove Gmail's "via amazonses.com" label, but it stays. Gmail hides that line based on the DKIM d= domain matching the From domain, not on the Return-Path, so a custom MAIL FROM alone does not remove it, and since February 2024 the visible "via" also signals that your From domain is not DKIM-aligned.
The fix
Enable Easy DKIM on the domain identity and publish the 3 CNAME records so the message carries a d=yourbrand.com signature that aligns with the From header; Gmail then drops the "via amazonses.com" label. A custom MAIL FROM domain fixes SPF alignment and changes the "mailed-by" line, but does not remove the "via" label on its own. In Gmail's show-details view, "mailed-by" reflects the Return-Path and reads amazonses.com until you also set a custom MAIL FROM like mail.yourbrand.com, while "signed-by" should read yourbrand.com once Easy DKIM aligns. Treat the "via" line as a symptom of DKIM non-alignment: fixing alignment protects placement, and the label disappearing confirms it.
Our mail is fine everywhere except corporate recipients on Proofpoint and Mimecast, who bounce us
On the shared SES IP pool your reputation is bundled with every other tenant on that IP, and enterprise gateways like Proofpoint and Mimecast quickly throttle or reject the whole SES shared range when any tenant misbehaves or the range is blocklisted. You see clean Gmail and Yahoo delivery but bounces or spam-foldering specifically at business domains, and AWS delists shared IPs on its own timeline.
The fix
For B2B or corporate-heavy lists, move onto SES dedicated IPs so your reputation is your own. Managed dedicated IPs warm automatically per ISP, but a fresh IP still has to build reputation, so give it a few weeks of steady, engaged sending before corporate gateways trust it. Meanwhile work the gateways directly: for Proofpoint, request a review or delisting for the specific IP (from the "554 Blocked" bounce) at ipcheck.proofpoint.com; for Mimecast, ask the recipient or their admin to add your region's SES IP ranges as a Permitted Senders policy, since only they can allowlist you. First confirm SPF, DKIM, and DMARC all align, because these gateways weight authentication heavily and will keep filtering an unaligned sender on any IP.
SES deliverability collapsed on a shared IP sitting next to dating and adult sites, despite spotless metrics
A sender pushing 70,000 newsletters a day watched shared IP reputation crater in Google Postmaster Tools even with a complaint rate at or below 0.05%, bounces under 0.5%, SPF, DKIM, and DMARC all passing, and one-click unsubscribe enabled. Looking up the neighbors on the same SES IPs revealed mostly dating and pornographic domains dragging the pool's reputation down.
The fix
When your own sending metrics are clean but shared IP reputation is falling, the problem is the neighbors, not your list. Move to a dedicated IP so no other sender can drag your reputation, and use SES managed dedicated IPs so AWS handles the roughly 45-day warmup by gradually shifting volume onto the new IP instead of you ramping it by hand. A managed dedicated IP typically costs about 50% more than shared and resolves the reputation and deliverability drop. Reserve shared IPs for low-volume transactional mail and keep bulk marketing on the dedicated IP.
