Possible to get a report of email addresses that bounced from Amazon SES? - amazon-ses

While the SES dashboard shows aggregated statistics about the bounce rate of emails sent through the service, I do not see a way of retrieving the individual addresses that bounced. Is this possible? Our situation is that the 'from' address we had set in certain emails was incorrect and resolved to a non existant mailbox on our (verfied sender) domain, so anything SES would have forwarded to the from address is likely gone.

Use the Amazon SNS (simple notification service), and then you can add your email address - or Amazon SQS service for holding a log of all bounces/complaints.

The answer is no, they are gone. Lesson: make sure you from address is valid (good practice obviously) and goes to a mailbox that resolves (and/or set up and process a SQS queue for them to go to)

I had the same problem. The SES report didn't show enough details for the accruing bounce error. I modified the sesreport.zip, where the deliveries, from-emails/source-emails, and the subject column are added and are included in the report.
You can find my modification here:
https://github.com/Morning-Train/AWS-SES-Report
I hope my answer helps you with your problem.

Related

AWS SES - Store email sent to`testing#my-domain.com` in S3, receive other emails to `me#my-domain.com` in iCloud?

Short Description
I am trying to figure out how to use AWS SES to receive email and store this in an S3 bucket, but only for a specific email address of a domain. The rest of the emails I would like to be handled by my email provider iCloud (or any other provider).
Why
I am working on a CDK Construct, and in order to test this construct I need to receive an email to a specific email address (testing#my-domain.com for example). I also need to read the contents of this email in order to complete the testing, however the domain I own is already setup to receive emails to other email addresses within that domain (contact#my-domain.com, and me#my-domain.com for example). Currently, this domain is registered through NameCheap (arbitrary DNS registrar) and the email client is setup through iCloud.
The Problem
The issue I am finding is that in order to receive email from AWS SES, I need to configure MX records for my domain on NameCheap to point to AWS SES. If I do this then I will no longer be able to receive emails from any other email addresses on my domain such as contact#my-domain.com or me#my-domain.com on iCloud (or any other email provider) as emails can only go to one server based upon the highest priority MX record.
In essence a pseudocode example of the logic I would like to have:
if email_address == 'testing#my-domain.com' then
save_to_s3_bucket()
else
default_send_to_icloud()
Investigated Solutions
Purchase second domain
One thing I could do, is apply a rule in iCloud that would forward all emails from the testing#my-domain.com email to go to any other address. The only way this would work is if I purchased a second domain and forwarded emails to an address on this domain. Here I could setup the MX records with no conflict as this domain would be used only for this purpose, and save to S3 bucket.
I don't like this approach because now I have to purchase a recurring fee of $12/year for a singular purpose of receiving an email for a test. This seems like an overkill solution for my problem.
Send email to S3 Bucket Endpoint
This is an imaginary solution (to the best of my knowledge), but wanted to show I have investigated this route. The idea would be if AWS S3 offered a service where they controlled a domain that anyone could send an email to, and then you could configure your S3 bucket to accept emails from some REGEX domain string and allow these to be saved to your bucket as a file. (I haven't fleshed out what the whole process is, but just giving rough concept)
This does not work as this is not a current offering from S3 (but would be pretty cool if they added it).
Forward to iCloud
The last option feels like a configuration nightmare, but the idea would be to configure AWS SES to receive all emails by setting the MX records of the domain to point there. Then we could apply rule-based filter to forward the emails that we aren't saving to S3 on to the iCloud server.
This approach has quite a few question marks, such as would the email appear to be sent from SES? How would I respond via iCloud to emails? Would need to investigate latency, dropped emails, etc. from SES.
I really don't want to do this as it feels like a nightmare of configuration. I have not done this though so please let me know if it is simpler than I might imagine.
These are the only solutions I have found thus far, are there any other solutions? I find it hard to believe I am the only person who has come across an issue like this, but googling for a solution like this is extremely difficult.
After some searching I found a solution by using a subdomain of my original domain. If I do this, then I can maintain the original MX records of my root domain and receive emails to my iCloud (or any other provider). Next I can add MX records to a subdomain, all emails will now be directed to AWS SES.
Type
Host
Value
Priority
TTL
MX
my-domain.com
mx04.mail.icloud.com
10
Automatic
MX
my-domain.com
mx07.mail.icloud.com
10
Automatic
MX
testing.my-domain.com
inbound-smtp.us-east-1.amazonaws.com
10
Automatic
The benefit of doing it this way is that subdomains are free in most (all?) DNS registrars.
AWS SES MX Configuration Docs
Now all emails from me#my-domain.com, contact#my-domain.com, etc will go to iCloud. All emails to anything#testing.my-domain.com, another#testing.my-domain.com, etc will go to AWS.

Amazon SES not delivering to fresh g suite address

Amazon gives 'Delivery Status Notification (Failure)'.
Important information:
the gsuite recipient didn't exist when the first 5-ish emails where sent.
The gsuite destination domain is mine, we're using ses to do automated mailings to our own students. Some users didn't get created automatically but were targeted by SES regardless.
However, even once the recipient is created, the problem remains. Same error.
Sending to recipient+blabla#gsuite works. So I'm assuming SES decides not to send to recipients that failed too many times?
If this is the case, is there a way to tell SES to retry anyway?
And no, I didn't ask amazon, apparently you need to pay for a support subscription before they're willing to help...
Thanks in advance,
Wim
Update:
There is also an account level suppression list ( [https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-email-suppression-list.html] ). I checked the 'global' suppression list before, which didn't help.
Why all of this information is this hard to find is beyond me. Or maybe it's just me '-)
Extra note for people fighting with aws cli: before you can list the suppressed addresses or remove them you first have to 'turn on' the management of the list:
aws sesv2 put-account-suppression-attributes --suppressed-reasons BOUNCE COMPLAINT
Hope this helps someone else...

Email Deliverability - Wrong Email in From section

I recently started working in hosting/software firm. And currently we have problem with our DNS server.
Two days ago we started getting complaints from our clients that they are receiving emails but in the From section there is a mistake, it shows wrong email of a sender. The email address that's displayed is a random address from one of our clients.
After trying to solve this problem i realized that in Email Deliverability section in cPanel Problems Exist (DKIM, SPF, and Reverse DNS).
When clicked on manage it shows how the records should look and it says that I need to update them, the problem is those same inputs do exist and so the problem persists.
It's important to note that this is a shared hosting server.
Is this some form of hacker attack? Did anyone ever had the same problem?
The sender email address is always specified by the mail client used to send that email (it's common to make mistakes in mail client settings). If those emails are not really sent by your team/server, it could be spoofing. You can implement SPF/DKIM + DMARC in your domain so that recipients can reject spoofed messages whenever they're not coming from your server.
Turns off the problem was coming from a different IP address. We were being attacked. As soon as we blocked it it stopped, and that error cPanel was showing was because the configuration on our server, it was always there.
This was the problem. I advise all WHM/cPanel users to update ASAP because the problem is really hard to find once you get in the middle of it.
https://www.tenable.com/blog/cve-2019-10149-critical-remote-command-execution-vulnerability-discovered-in-exim
You can monitor your email health score with a mail testing service.
These services allow you to check for deliverability issues along with spam activity on your email. Warmup Inbox provides a health score to all users. It's nice to keep track of how your email is performing/what needs to be improved.
Implementing a SPF record alongside proper DMARC and DKIM settings for your domain will drastically increase the overall deliverability rates of all outgoing mail coming from your domain. DKIM and DMARC increase deliverability rating as well as keep your mail server safe from malicious attacks and damaging spam mail.

Email Spoofing Cpanel

I'm getting returned email in my indox that I nerver sent before,How Can I use Cpanel to stop it, my inbox alway filled up.
I read this article
http://www.werockyourweb.com/stop-spoof-email
But it seen doesn't work for me. Thank!
It seem some email system block my email address, it look like
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue
Please let us know a sample header of the similar mail from queue
Make sure that the domain engaged in the process is having a valid SPF(TXT) record.
SPF
Spoofing can be done in many ways like if you have any form which may have bug in it and causing spamming from it .. or many any of your signup process form has bug which allows spamming over it
if its clear spoofing then yes SPF and DKIM will help to reduce it.
That's correct! Adding DKIM and SPF should help to reduce the spoof emails. If you will paste the headers here, we can identify the real cause of it. You will find it from the returned email as well from the server logs.

Email verification using telnet fear of marked as spam

Problem Background:
I have a 35K+ user members and growing fast. I am planning to migrate to Amazon SES service. Amazon SES has a criteria to reduce the quota or even terminate service based on bounce-back emails.
I send promotional emails to my members. But the fear is that there are email address which are no longer exists so a fair possibility that Amazon SES notice me and take action to reduce or terminate my service. I need to make sure I have valid email address which do not disturb SES.
Possible Solution:
To cope this problem I am planning to do the following procedure for each email address;
Step1. Collect the MX record for the email domain.
Step2. telnet to that MX domain
Step3. Verify email address with the following pattern
EHLO my_domain_name
MAIL FROM:<my_valid_email#my_domain_name>
RCPT TO:<email_to_verify#my_user_email_domain>
I will verify the response after each command trigger such as email is valid if I receive 250 status after RCPT command
Now what are the possible precautions I should care about to be not marked as SPAM or rejected by the remote server???
I guess you have seen this question here: How to check if an email address exists without sending an email? ? That talks a bit about the disadvantages.
I am no expert but I suspect that it is going to be pretty hard to guarantee that someone won't blacklist you at some point or that you get 100% accurate results from this, or any other method for that matter.
For your scenario though, maybe that does not matter too much - just try to do the check infrequently so that you reduce the number of guaranteed bounce backs and if you send only a few that get bounced back it won't matter too much. On top of that you can have your own system that handles a bounce back and makes sure you do not re-send to that email again.
Doing all of that may be just "good enough" to work.
You may get very different answers from what you expect. Many (most?) e-mail systems set up to prevent spam won't give away user information just like that. My own server, for example, will say 250 OK for every address on my domains, even if those addresses are in fact non-existing.
What you should do is have a system which reads those bounce e-mails and remove unused addresses after a number of bounces. A good way of doing that is having different sender addresses for each message (or at least for each recipient), making it easy to connect bounce messages with their intended recipients. This technique is sometimes called Variable envelope return path.