How do I troubleshoot Amazon SES email deliverability and SPF/DKIM setup?

Hi! When SES says “sent” but recipients don’t see the message (or it’s in spam), the fastest way to debug is to (1) confirm the recipient’s mailbox actually accepted it, (2) confirm SPF/DKIM/DMARC are passing with your domain (alignment), and then (3) look at bounces/complaints and reputation signals inside SES so you’re not guessing.

Here’s a practical, “check this first” workflow that usually finds the root cause quickly:

1) Prove what happened to a specific message (not just “SES sent it”)

• Grab the raw message headers from a recipient who can find it in Spam/Junk (or from a mailbox you control on Gmail/Outlook/Yahoo). Look for:
  • Authentication-Results: (this will tell you whether SPF pass/fail, DKIM pass/fail, and DMARC pass/fail)
  • The DKIM d= domain (should be your domain, not only amazonses.com)
  • The Return-Path / MAIL FROM domain (important for SPF and DMARC alignment)
• In AWS, enable SES event publishing (or check what you already have) so you can see per-message events like delivery, bounce, complaint, reject. “Sent” from your app just means SES accepted the request; deliverability issues show up in these events.

2) Make sure you’re authenticating with the right identity (common SES gotcha)
A surprisingly common issue: you verified/configured DKIM for the domain, but you’re actually sending from a separately-verified email address identity (like no-reply@yourdomain.com) that doesn’t have DKIM enabled—so messages go out without the domain DKIM you expect.

What to check in SES:

• Under Identities, confirm you’re sending from a domain identity you control (recommended), and that DKIM status is “successful” for that same identity.
• If you see both the domain identity and individual email address identities, consider removing the email address identity if it’s causing SES to treat it separately.

Also double-check:

• Region matters: if you send from multiple AWS regions, DKIM/identity setup can be region-specific. Make sure the identity you configured matches where you’re sending from.

3) DKIM: confirm the DNS records are correct and publicly resolvable
If you’re using Easy DKIM, SES expects three CNAME records. Typical failure modes:

• DNS provider auto-appends the domain (record ends up duplicated)
• Wrong host/name formatting (especially around _domainkey)
• Records exist but aren’t publicly resolvable everywhere yet (DNS propagation)

If DKIM is “pending” or flips between working/not working, that’s a red flag—fix DKIM first because it’s one of the strongest deliverability signals for transactional email.

One more DKIM trap: if you recently switched from BYODKIM → Easy DKIM, there can be a window where SES won’t sign with your DKIM until verification completes, and that can temporarily tank inbox placement.

4) SPF: don’t over-focus on it unless you use a Custom MAIL FROM
In SES, SPF is a little nuanced:

• If you’re using SES’s default MAIL FROM (an amazonses.com subdomain), SPF for that MAIL FROM typically passes automatically.
• If you configured a Custom MAIL FROM domain (recommended for brand alignment), then you must publish the correct SPF TXT for that MAIL FROM subdomain and the required MX record for handling bounces/complaints routing.

So: check what domain appears in the message’s Return-Path. If it’s your custom subdomain and SPF is failing, fix the custom MAIL FROM DNS (SPF + MX). If Return-Path is still amazonses.com, SPF is less likely to be your main problem—DKIM/DMARC alignment usually is.

5) Add/verify DMARC (and check alignment, not just “pass”)
Even if SPF or DKIM “passes,” DMARC can still fail if they don’t align with your visible From domain.

• Publish a DMARC record for your From domain.
• Start with a monitoring policy if you’re not sure (so you can see reports and avoid accidental blocking).
• In your header check, verify DMARC=pass for the From domain you use for one-time codes/password resets.

6) Check SES account health: bounces, complaints, suppression, and limits
Deliverability drops often correlate with one of these:

• Bounce/complaint spikes (even with opt-in, password reset traffic can hit recycled addresses or typo domains)
• Account-level suppression (SES suppression list or your own list hygiene): you may be repeatedly attempting addresses that will never deliver
• Sending limits/throttling: if you spike volume (e.g., incident-triggered password resets), SES may throttle; that can look like “sent” in your app but create delays/failures downstream
• Sandbox vs production: if you’re in the sandbox, SES restricts where you can send; make sure your account is in production and you’re not mixing environments/regions.

7) Use SES’s deliverability tooling (if you have it enabled)
If you have Virtual Deliverability Manager (VDM) available/turned on, its Advisor is genuinely useful for catching malformed/missing SPF/DKIM/DMARC and other infrastructure issues without manual digging.

8) If authentication is clean, look at content + reputation signals
For transactional mail, even small changes can trigger spam placement:

• From name/domain consistency (don’t rotate From domains)
• Avoid URL shorteners and overly “marketing-ish” wording in security emails
• Make sure your one-time code templates are simple, don’t look like promotions, and render well in plain text
• Keep complaint rate low, and don’t send to unengaged or old addresses even if they “opted in” long ago

If you want, paste (remove any personal info) the Authentication-Results, From, Return-Path, and DKIM-Signature (d=) lines from one spammed message header, and tell me whether you’re using a custom MAIL FROM and which AWS region you send from—I can help you pinpoint exactly what’s misaligned.