is not authorized to perform ses sendemail

This message is an AWS IAM authorization failure, not an SMTP or SES protocol status code. The full error looks like:

User: arn:aws:iam::123456789012:user/my-sender is not authorized to perform:
ses:SendEmail on resource: arn:aws:ses:us-east-1:123456789012:identity/example.com

It means the IAM principal (user or assumed role) that signed the SES SendEmail request has no effective Allow for the ses:SendEmail action on that resource. Because IAM is deny-by-default, a missing permission, a too-narrow Resource, a blocking Condition, or an explicit Deny/SCP all surface as the same "not authorized" text.

What causes "is not authorized to perform: ses:SendEmail"?

• No SES permission attached. The principal's policies never grant ses:SendEmail. This is the common case for a new Lambda execution role, EC2 instance role, or IAM user.
• Wrong action for the call path. The SES SMTP interface (which AWS documents as using SES API version 2 of ses:SendRawEmail) and the classic SendRawEmail API action both authorize against ses:SendRawEmail, not ses:SendEmail. AWS documents that SMTP users "must allow access to ses:SendRawEmail at a minimum." (Note: the SES API v2 SendEmail call authorizes against ses:SendEmail for all content types — Simple, Raw, and Template.) Because the right action depends on which API/interface you use, granting both ses:SendEmail and ses:SendRawEmail is the simplest way to avoid this error.
• Resource ARN too narrow or wrong Region. If your policy scopes Resource to a specific identity ARN, the request must match it — including Region. SES is regional, so arn:aws:ses:us-east-1:... will not authorize a call made to eu-west-1.
• A Condition is blocking the request. Keys like ses:FromAddress, ses:Recipients, ses:FromDisplayName, or ses:FeedbackAddress (and StringLike is case-sensitive) can cause an otherwise-valid Allow not to match.
• Explicit Deny or SCP. An explicit Deny in any attached policy, a permissions boundary, or an Organizations SCP overrides any Allow.
• Cross-account sending. When account B sends on behalf of an identity owned by account A, account A must attach a sending authorization (identity) policy to the identity; an IAM policy alone in account B is not enough. Only sending authorization policies can grant cross-account access.

Note: this is distinct from the SES sandbox restriction. An unverified address or sandbox cap returns MessageRejected ("Email address is not verified"), not an IAM not authorized error.

How do I fix "is not authorized to perform: ses:SendEmail"?

1. Identify the failing principal. Read the ARN in the error (User: / AssumedRole: segment). Attach the policy to that role/user — not to a different one.

2. Attach an identity-based policy granting the send actions. This is the AWS-documented "email-sending actions only" policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSESSend",
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "*"
    }
  ]
}

Including both ses:SendEmail and ses:SendRawEmail covers the API v2 SendEmail call as well as the SMTP interface and the classic SendRawEmail API. Resource: "*" lets the principal send from any verified identity in the account.

3. Scope it down once it works (optional). To restrict which verified identity may be used, set Resource to the identity ARN — match the Region exactly:

"Resource": "arn:aws:ses:us-east-1:123456789012:identity/example.com"

4. Check for blockers. Search all attached policies, permissions boundaries, and SCPs for an explicit Deny on ses:Send*. Remove or narrow any Condition (e.g. ses:FromAddress) that excludes your real From/recipient values.

5. Confirm the Region. Make sure the SES client/SDK Region matches the Region where the identity is verified and where the ARN points.

6. Cross-account: have the identity-owning account add a sending authorization policy to the identity granting your account/role ses:SendEmail and ses:SendRawEmail.

After updating, re-test — IAM changes are eventually consistent and typically propagate within seconds to a few minutes; don't assume the new permission is live immediately in automated retry logic.

Courier users: if you route SES through Courier, the credentials you provide must belong to a principal carrying the policy above. A ses:SendEmail authorization error in your provider logs points to the AWS-side IAM grant, not to your Courier configuration.