SES Incoming Mail Accepted but S3 Delivery Silently Fails (Access Denied / No S3 Log)

Based on your description, your setup appears to be mostly correct, but there are a few potential issues that could be causing the silent failure:

1. Verification of SES Setup: Check if you have the AMAZON_SES_SETUP_NOTIFICATION file in your S3 bucket. This file indicates that SES has successfully tested its ability to write to your bucket. If this file exists, it means SES can write to the bucket, but there might be other issues with the actual email delivery.

2. MX Record Configuration: Ensure your MX record is pointing to the correct SES endpoint for receiving emails. For the Ohio region (us-east-2), your MX record should point to inbound-smtp.us-east-2.amazonaws.com. Using the wrong endpoint (like one for sending emails) could result in authentication errors.

3. Receipt Rule Set: Verify that your receipt rule set is active and properly configured. The rule should include the correct recipient addresses and be enabled.

4. Bucket Policy Condition: Your bucket policy includes conditions for aws:SourceAccount and aws:SourceArn, which are good security practices, but could potentially cause issues if not exactly matching the SES configuration. You might try temporarily simplifying the policy to just the basic SES permission without conditions to test if that's the issue:

{
"Sid":"AllowSESPuts",
"Effect":"Allow",
"Principal":{
"Service":"ses.amazonaws.com"
},
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::[S3-BUCKET-NAME]/*",
"Condition":{
"StringEquals":{
"aws:Referer":"[12-DIGIT-ACCOUNT-ID]"
}
}
}

5. Testing Process: Send a test email to your domain and check if it appears in the S3 bucket. Remember that the email file will have a unique name consisting of letters and numbers, not the subject line or sender information.

6. CloudWatch Logs: Consider setting up CloudWatch Logs for your SES receipt rules to get more visibility into what's happening when emails are received.

If none of these suggestions resolve the issue, you might need to contact AWS Support for further assistance, as there could be an underlying issue with the SES service in your account or region.
Sources
Step 5: View the received email - Amazon Simple Email Service
Giving permissions to Amazon SES for email receiving - Amazon Simple Email Service
Use CreateReceiptRule with an AWS SDK - AWS SDK Code Examples
SES email receiving don't deliver mail (error 530) | AWS re:Post

Hey,

Hope you're keeping well.

In SES receipt rule S3 actions, the aws:SourceArn in your bucket policy must match the ARN of the specific receipt rule, not the rule set ARN. You can find the correct ARN in the SES console by opening the rule, which will look like arn:aws:ses:us-east-2:<account-id>:receipt-rule/<rule-name>. Update the bucket policy to match that exact ARN and keep the aws:SourceAccount condition as-is. Also, make sure the bucket does not block public access in a way that overrides the SES principal permissions. Once the policy matches the actual rule ARN, SES will be able to write the object to S.

Thanks and regards,
Taz

Hey,

Hope you're keeping well.

In SES receipt rules, the aws:SourceArn in your bucket policy must match the ARN of the specific receipt rule or receipt rule set that triggers the S3 action, and SES actually uses the rule ARN, not the rule set ARN. You can find it in the SES console by opening the rule and checking its ARN, then update your bucket policy accordingly. Also make sure the bucket’s Block Public Access settings aren’t preventing the put, and enable Amazon S3 server access logging or CloudTrail data events for S3 to confirm whether SES is attempting the write.

Thanks and regards,
Taz