- Newest
- Most votes
- Most comments
Hello.
Do you use the AWS API (SendEmail API) to send emails?
In this case, if you have CloudTrail enabled, you should be able to identify the source IP address from the log.
https://docs.aws.amazon.com/ses/latest/dg/logging-using-cloudtrail.html
If you are using SMTP authentication, as of October 2025, the activity is not recorded in CloudTrail, making it difficult to identify the sender.
Therefore, it is recommended to regularly rotate your credentials and monitor CloudWatch metrics to check whether the number of sent emails has increased compared to usual.
We also need automatic key update/disablement in case of compromise, if possible.
There is no automatic function for rotating the SMTP authentication information keys, so users will need to create them themselves.
For example, as described in the following document, it is possible to create SMTP credentials from the secret access key of an IAM user, so I thought that if I customized this code to create SMTP credentials periodically, I could create an automatic rotation mechanism.
https://repost.aws/knowledge-center/ses-rotate-smtp-access-keys
Relevant content
asked 4 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a month ago
Which method is the safest and best for sending emails? SMTP or a direct API call? Because we don't have email templates, we're sending raw emails. What do you recommend, and what could be the real reason our credentials were compromised?
I think that both SMTP authentication and the SES API using the AWS SDK provide the same level of security. If the application that sends emails is hosted on an AWS service such as EC2 or Lambda, you can use an IAM role, so I recommend sending emails using the AWS API with the AWS SDK. If the sender of the email is not an AWS service such as EC2 or Lambda, you will need to issue and use an access key from an IAM user, which is the same as using SMTP authentication information. Therefore, if your application is hosted outside of AWS services, it makes no difference which one you use, as there are equal security risks if you do not have strict control over your credentials.
I'm not sure how your application manages Amazon SES credentials, but I've seen cases in the past where credentials were accidentally exposed to public places like GitHub, resulting in unauthorized use.
You are right about 4-5 months ago our repository had been converted to public and AWS had notificated us. We were quickly updated specific credentials but no all. For example app secret etc. not changed. Do you think anything causes this vulternability?
Are you also pushing application secrets etc. to the repository? In that case, the cause would be that the application secret has been pushed to the repository. Normally, application secrets should be set as environment variables rather than being embedded directly in the code stored in the GitHub repository, as this is the more secure way to manage them.
Did you mean that we should store secrets in the instance environment variables right? Because, we are not storing credentials in repository now. We are storing credentials directly inside instance but still we keep it in a credential file which located in application files (.env file). What is your suggestion?