AWS SES emails not reaching your business inbox?

I invested some time in figuring out why my app running on AWS, using SES for sending emails was not working correctly. The strange behaviour was that for Gmail, it was working fine, for my work domain it was not delivered and I wasn't able to see any logs related to this on my corporate email server.

So I started to check the standard stuff like:

• SES in prod mode?


• SES config, do I have a from address, am I using the correct region


• DKIM enabled?


• Custom "mail from" domain configured and valid


• No errors on the app side


• Checked the SES status for bounces and rejects


• Destination email address not being on the suppression list

Everything seemed fine but the test emails were not reaching my business email address. So if Gmail gets the test email, it must be "them", right? The next step was to look into the SPF records, which is a DNS record that tells receiving mail servers "these are the only servers allowed to send email on behalf of our domain." If a server isn't on the list, the email gets flagged or rejected.

The parent domain had a strict policy:

v=spf1 mx ip4:x.x.x.x include:corporate-spf.example.com include:spf.protection.outlook.com -all

That -all at the end means "reject everything not on this list." And SES wasn't on the list, there was no include:amazonses.com anywhere. The sending subdomain didn't have its own SPF record either, so it inherited the parent's strict rules.

I added an SPF record for the subdomain to explicitly allow SES:

v=spf1 include:amazonses.com ~all

But emails still didn't arrive. SPF was part of the problem, but not the root cause.

I needed more visibility to what was happening so I decided to create a SNS topic for SES send & delivery events.

After the next test, the SNS notification came back with this:

{

  "notificationType": "Bounce",

  "bounce": {

    "bounceType": "Transient",

    "bounceSubType": "General",

    "bouncedRecipients": [{

      "emailAddress": "[recipient]",

      "status": "5.3.0",

      "diagnosticCode": "smtp; 553 #5.1.8 Domain of sender address <[email protected]> does not exist"

    }]

  }

}

It turns out that the corporate mail gateway is rejecting the email because the MAIL FROM domain "does not exist."

So I went back to checking the it's always the DNS:

$ dig MX mail.mydomain.com @8.8.8.8 +short

10 feedback-smtp.eu-central-1.amazonses.com



$ dig TXT mail.mydomain.com @8.8.8.8 +short

"v=spf1 include:amazonses.com ~all"



$ dig A mail.mydomain.com @8.8.8.8 +short

# (empty - no A record)

The issue was that I configured my SES to use MAIL FROM with mail.mydomain.com but that didn't exist, it had no A record. Apparently RFC 5321 says if there's no A record, the domain "doesn't exist" for my corporate mail gateway and the email gets rejected.

The easy fix

I removed the MAIL FROM domain configured in SES so it defaulted to amazonses.com, this way my corporate mail gateway was able to resolve it and emails started to get delivered as expected.

The strange part

The strange part to investigate was the fact that SES was reporting successful deliveries for my test corporate emails.

Here's what actually happens:

1. SES sends the email to the corporate mail gateway


2. The gateway accepts the connection (SMTP 250 OK)


3. Then it runs additional checks: domain existence, SPF, DKIM


4. It quietly rejects the email with a 553 error

Without delivery notifications, these bounces are invisible. SES counts that initial 250 OK as success. Only when you add SNS notifications does the real story surface.

Lessons learned the hard way

SES stats can be misleading. A gateway can accept an email and then silently discard it. Always enable delivery notifications when debugging. Don't trust the dashboard alone.

RFC 5321 says the MAIL FROM domain must be resolvable. Some strict gateways check for A/AAAA records, not just MX. If you're using a custom MAIL FROM domain with SES, make sure it has an A record. That's the one that I missed...