Amazon SES deliverability: why your emails go to spam and how to fix it

You send through Amazon SES, the API returns a 202, and the event notification says "delivered." But the recipient never sees it. It is in spam, or it is not there at all. This is the most common complaint from teams sending through SES, and it is almost never SES's fault. SES is doing exactly what you told it to do. The problem is upstream: the sending domain, the authentication records, the IP reputation, or the list you are sending to. Here are the five reasons SES deliverability drops, in order of likelihood, and the exact fix for each one.

1. Your SPF record points to the wrong SES region

SES is regional, and your SPF record must include the SES endpoint for the region you send from. If you send from us-east-1, your SPF record needs include:ses.us-east-1.amazonaws.com. If you include the wrong region, or no region at all, the SPF check fails and mailboxes treat your mail as unauthenticated. Open your SES console, confirm the region your sending identity is in, and update your SPF record to match. If you send from more than one region, include each one, but keep the total number of SPF lookups under ten, because exceeding that limit makes the whole record fail.

2. Your DKIM CNAME record is missing or mismatched

SES signs your mail with DKIM, but only if you add the CNAME record it generates. In the SES console, open your verified sending domain, go to DKIM signing, and copy the CNAME record it shows. Add it to your DNS exactly as shown. The record points to a ses.<region>.amazonaws.com address, so it must match the region you send from. If the record is missing, expired, or points to the wrong region, SES cannot sign your mail, and every message you send goes out unsigned. Unsigned mail is one of the strongest spam signals a mailbox sees. If you recently switched DNS providers, this record is the first thing to re-add.

3. You are sending from an identity you have not verified

SES will not send production mail from an unverified identity. While your account is in the sandbox, it can only deliver to verified email addresses. To send to anyone, you request production access and verify the domain or address you send from. If the identity is not verified, SES rejects the send before it ever reaches the recipient, and your application sees a hard error rather than a delivery. Verify the exact domain you send from, not a subdomain, unless you intend to send from that subdomain. A common mistake is verifying mail.example.com and then sending from example.com, which SES treats as a different, unverified identity.

4. Your shared IP pool has a bad reputation

By default, SES sends your mail from a pool of shared IPs. Other senders on that pool affect your reputation. If a neighbor is sending spam or has a high complaint rate, your mail can suffer even if your own sending is clean. You have two levers. First, request a dedicated IP, which is available at higher sending volume, and warm it up gradually instead of jumping to full volume. Second, keep your own sending behavior clean so the shared pool stays healthy. You can watch your sending statistics in the SES console, but the console only tells you what happened after the fact. Inboxproof monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed, so a reputation drop never catches you blind.

5. Your bounce and complaint rates are too high

SES tracks bounces and complaints per sending domain. If your bounce rate climbs above 5 percent or your complaint rate climbs above 0.1 percent, SES degrades your reputation and can suppress your sends. Clean your list before you send, validate addresses, and honor unsubscribes the same day. SES maintains a suppression list of addresses that have bounced or complained. If you keep sending to those addresses, you hurt your reputation and waste sends. Remove hard bounces from your list, stop sending to suppressed addresses, and keep your engagement healthy so the addresses you do send to actually open the mail.