Problem delegating SES sender

I'm not sure what's causing that, but the :root reference allows access by all principals in the account, so it's probably not the problem. If you want to allow a specific IAM user, you'll need to specify its full ARN, which normally ends with :user/username1 (if the user is defined without an IAM path, as they usually are) instead of :username1. You can copy the full ARN from the user's properties in the IAM console.

Maybe you could try setting the policy statement to permit all resources and restrict the identity with condition keys, like this, and try if it makes any difference (which it might not do):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "stmt1721248399622",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action": "ses:SendRawEmail",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ses:FromAddress": "sender@sourcedomain.tld"
                },
                "ForAllValues:StringLike": {
                    "ses:Recipients": [
                        "*@alloweddestination1.tld",
                        "*@alloweddestination2.tld"
                    ]
                },
                "Null": {
                    "ses:Recipients": false
                }
            }
        }
    ]
}

Aha! I didn't realise the "root" allowed all users in the client account, but that's actually what I need so good news!

I'm also unable to predict the "To:" addresses, but the client can't send to arbitrary addresses- essentially the lambda only allows them to request data to be emailed to their own address so this isn't a problem.

I'll try broadening the "Resources", and then if that works, narrowing it down to restrict it to only the needed ones.

Thanks for your help,

David

Analyzing the described problem, there are several important points to consider:

1. The SES policy is correct in terms of allowing email sending, but there's an issue with the specified Principal.

2. The Principal in the policy is defined as "arn:aws:iam::111111111111:root", which refers to the root account of the production account, not the "admin" user in the client account.

3. The mentioned error indicates that the email addresses are not verified in SES.

To resolve this issue, I suggest the following actions:

1. Modify the SES policy to use the correct ARN of the user or Lambda role in the client account. It should be something like: "Principal": {"AWS": "arn:aws:iam::222222222222:user/admin"} or "Principal": {"AWS": "arn:aws:iam::222222222222:role/lambda-role"}

2. Verify that the email addresses are correctly validated in SES in the EU-WEST-1 region. Both the sender address (admin@mydomain.com) and the recipient (customer@theirdomain.com) need to be verified, or the entire domain needs to be verified.

3. If you're using SES in sandbox mode, remember that you can only send to verified email addresses. Consider requesting removal from the sandbox if necessary for your use case.

4. Ensure that the IAM permissions for the Lambda role in the client account include the necessary SES actions, such as "ses:SendRawEmail".

5. Check that the region specified in the resource ARN in the policy (eu-west-1) matches the region where you're trying to send the email.

By implementing these changes, you should be able to resolve the SES sender delegation problem and allow the Lambda in the client account to send emails using the domain identity of the parent account.

This is very interesting, and I think you may have hit on the problem, but I don't understand some of the points so can't be sure. Let me add what I think about each and see where I'm making the wrong assumptions.

1. I'd prefer to allow any user in the client account to send using delegated authorization (although in fact there's only one user - the sending lambda). Will the existing Principal (":root") do this?
2. The whole "mydomain.com" is validated in the authorizing account, so the sending address (report@mydomain.com) should be OK and I think (hope) the delegated sender should be able to send to any unvalidated address?
3. The authorizing account is in Production mode, the delegated sender account is in the Sandbox. I hope I don't need to get both in Production, otherwise what's the point of delegation?
4. the lambda role in the client account includes AmazonSESFullAccess so hopefully has ses:sendRawEmail in there.
5. I checked the regions, all match so all good.

The :root reference allows all principals in the account. The other writer's remark about it only allowing the root user is simply wrong; what the root reference technically means when used in the Principal element of an AWS policy statement is that it delegates the authorisation decision to the specified AWS account. You can disregard the statement to the contrary. This is officially documented here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-accounts

Also the sender is obviously validated, since the whole domain is validated and sending locally within the account is working.

The documentation on the SES delegation model discussed earlier says explicitly that the delegated sender account must also be in production mode. It's mentioned in the red box on this documentation page: https://docs.aws.amazon.com/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html

Your alternatives would seem to be two. One is to create IAM users or roles in the production account and allow the Lambda functions in the other accounts to assume the role or authenticate as that user. Sending would work, because the sending principal would be local to the sending AWS account that's in production mode.

The other alternative would be to keep the member accounts in sandbox mode but to verify the sender and recipient identities (such as the recipient domains of each customer) in each of those accounts. They could send emails to up to the sandbox limit of 200 messages per day to destination addresses matching identities verified in the member account.

I think this is the key "The documentation on the SES delegation model discussed earlier says explicitly that the delegated sender account must also be in production mode."

I think the most straightforward route for me to take is to create a sender IAM role in the production account, as you suggest. The process for getting the sender into production mode is just too clunky to scale for larger numbers of clients, and the volumes are tiny as the emails are only sent on request, so maybe 20 a day max. The main downside is that (I assume) all the SES cost would appear in the 'parent' production account, so I'd lose the benefit of having this rolled in with all the other service cost accounting in the individual client accounts. I'll have to do some kludge using the CloudWatch logs or some clunkiness of an alternative kind!

Thanks for your help, I'll try all this tomorrow.