SES sent email lands in spam after activating Custom MAIL FROM domain and WorkMail

0

Hey guys, I'm using SES to send emails programmatically since weeks and everything was fine. Now I followed a recommendation from the AWS console to activate "Custom MAIL FROM domain". Meanwhile I was activating Amazon WorkMail as well to activate a new email for sending and receiving emails.

I'm using this plugin to send emails programmatically: https://www.npmjs.com/package/@strapi/provider-email-amazon-ses

This tool is asking for these credentials: providerOptions: { key: env("AWS_ACCESS_KEY_ID"), secret: env("AWS_ACCESS_SECRET"), amazon: "https://email.eu-central-1.amazonaws.com", }, settings: { defaultFrom: "no-reply@....com", defaultReplyTo: "info@....com", },

Neither no-reply@, nor info@ are setup yet in WorkMail as it wasn't needed before I suppose it's not needed. Do I have to wait until the changes of "Custom MAIL FROM domain" are verified by the receiving email providers or why does the programmatically sent emails land in spam now?

The newly setup email address in WorkMail works fine. Those emails sent through the WorkMail Web Client works fine. E-Mail does not land in spam.

Any ideas how to solve the Spam issue?

Thank you in advance.

2 Answers
0

Yes, unfortunately I was using SES in eu-central-1 and had to activate WorkMail in eu-west-1. WorkMail worked find but then I experienced the above issue. So I thought I simply delete SES in eu-central-1 and recreate it in eu-west-1. Now my newly created SES in eu-west-1 is in sandbox mode and I'm still waiting for the activation of the production mode. Due to that whole misunderstanding, I cannot send any emails in production right now for my product. Maybe you can speed up things: Case ID 9843889541

answered 2 years ago
  • Hi -- I see that case has been taken care of. Hopefully you're back in action now, but feel free to ping if you run across any further bumps. Have a great weekend!

0

Hi there -- thank you for your interest in WorkMail and SES!

I noticed that in the credential options you quoted above, you're citing the SES endpoint for eu-central-1. That is a region that WorkMail is not available in, so your WorkMail organization must be elsewhere. If you have used the same custom MAIL FROM subdomain (e.g., mail.yourdomain.com) for both SES and WorkMail, you may have accidentally invalidated your domain's Custom MAIL FROM MX record for your application running in eu-central-1, because it is region-specific.

If this is the case, you can easily correct it just by giving your WorkMail organization's custom MAIL FROM a new, unique subdomain name, and then changing that original MX record back.

Just head back to the Domains page in the WorkMail console and follow the link in the Custom MAIL FROM section, which will take you to the right page in the SES console. In the Custom MAIL FROM section, click the Edit button, give it a new name, save it, and then publish the new DNS records. For example, if you were using mail.yourdomain.com and want to keep that one for your SES activity, you could use workmail.yourdomain.com for WorkMail instead. After your WorkMail records are published, just change the MX record for your SES Custom MAIL FROM domain to point back at eu-central-1 instead of the WorkMail region it is now. At that point you should have SES verified identities for the same domain name in each of two regions, one for each of your messaging use cases, and each with its own valid and unique custom MAIL FROM.

I hope that helps!

Kind regards,

Sabrina

profile pictureAWS
sld
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions