Troubleshooting Amazon AWS SES sending email via SMTP

I’m having trouble moving from SendGrid to Amazon SES.

Could someone kindly share their settings from app.yml or confirm mine are correct?

  ## TODO: The SMTP mail server used to validate new accounts and send notifications
  DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

Is the auth parameter correct here?

Have I missed something?

1 Like

The domain is verified at SES, you don’t need the SMTP auth parameter.

Additionally, you may have to get your ses account out of sandbox if not already done and request a limit increase. The sandbox condition applies per-region


Yes, confirmed the domain is verified and is in production mode and rate limits increased.

Everything else looks correct then? :thinking:

Yes, other settings look correct to me.

And the password is ok being wrapped in “marks”?

Yes, that should be fine too


Is there a way to test from command line?

I have rebuilt my app each time too.

Thanks for the quick replies :+1:t2:

And this also looks correct? (I commented out the auth line as you suggested)

I’m still at a loss as to why no emails are being sent via AWS SES.

When I send a test email via the admin page of our Discourse it simply says ‘sent’. Trying a lost password request also goes through the motions correctly but no email ever arrives.

I don’t think SES logs, so can I can’t check to see if it’s even receiving the emails.

The only thing which may cause a problem is that our reply-to address is using a account , rather than our site domain.

Has anyone run in to this combination / scenario before?

That’s the email address that will be in the from line. It needs to be an address in the domain that SES will send from. SES won’t send mail that pretends to be coming form gmail. You don’t have control over, so SES won’t send mail with that in the from line. notification_email should be something@yourverifieddomain


I was wondering if it might be something like that.

My current SendGrid setup has been working for years and has the following:

Are you saying that what I’m trying to do simply isn’t possible in SES because of the reply-to address being on the domain?

The notification email is what’s in the from line, and yes, I am fairly certain that’s your problem. Did you try changing it?

1 Like

I use SES as well and it works well for me. The only difference I can see in comparison is that the
DISCOURSE_SMTP_AUTHENTICATION: login line does not exist in mine. Also that DISCOURSE_SMTP_ENABLE_START_TLS: true and DISCOURSE_SMTP_PORT: 587 are both commented out, though that shouldn’t make a difference.

The only 3 lines that I modify in the app.yml is the SMTP address, username and password. The rest is commented out as-is from a fresh install and using defaults. After rebuild I just need to ensure that the site setting notification email is set to an address which uses a domain verified on SES. I don’t use quotes on the password anymore, but my older installs did and it worked fine either way.

Yeah would be worth trying changing the reply-to address to use an address using the verified SES domain as recommended in the above reply, just to test if that will make it send properly.

If it doesn’t work, I’d check if your host is blocking some ports and perhaps double check that the SES credentials were generated correctly. I see you’ve confirmed above that your domain is verified with SES.


Thanks for the detailed info @markersocial :+1:t2:

Can I ask, is your “reply to” email address on a different domain from the the “From” address? :thinking:

No worries :slight_smile:

The reply to address is on the same domain as the from domain yeah, but on some instances it’s not the same subdomain (still the same root domain though). Both cases work fine for me.

1 Like

I’m sure that you caught this -> have you verified the outgoing email address that discourse uses to send?
If it is notify@yourverifieddomain, you need to go into SES, second row under ‘Identity Management’ and add then verify the sending email. Nothing goes out until you do this.
No alarms, no sirens, just no go.

Having a gmail reply is great. That is what I did. Then members authorization emails were getting spam blocked because From and Reply didn’t match.

Eventually I wrote a simple AWS Lambda (took a week to learn how) that forwards incoming email to the Discourse API. Very clean. No POSTIX.