AWS SES Permissions Policy Generator
AWS SES looks simple on the surface: give an application permission to send email and move on. In practice, that single decision often becomes the source of unexpected costs, abuse investigations, or quiet policy drift as environments change.
This tool exists to remove that ambiguity.
It generates explicit AWS SES IAM permission policies that define exactly who may send email, from where, and in which region — with current AWS SES pricing tiers and regional cost differences taken into account.
The generator runs externally and outputs policy JSON only. No AWS credentials, keys, or account data are collected or processed.
What this generator is designed to solve
Most SES permission examples online are overly broad. They allow email sending from anywhere, by anything, as long as the role exists. That approach worked when SES usage was small and pricing flat. It does not hold up today.
This generator helps you:
- Prevent unauthorised mail sending from test systems or forgotten services
- Keep SES traffic locked to approved regions
- Reduce the risk of unexpected volume-based charges
- Produce policies that are clear during security or finance reviews
How the policy controls work
IP-based restrictions
Restricting SES usage by source IP address ensures that only known infrastructure can send email. This is particularly useful when:
- Separating transactional email from marketing platforms
- Locking SES access to a production VPC or mail relay
- Preventing compromised credentials from being abused elsewhere
Only traffic originating from approved IP ranges will be allowed to send.
Sender address and domain rules
The policy can restrict sending to specific addresses or entire domains using ses:FromAddress.
This prevents common failure scenarios such as:
- Developers sending mail from personal addresses
- Test scripts using production sender identities
- Third-party code attempting to spoof approved domains
Only declared sender patterns are permitted.
Action-level scope
The generated policy focuses on ses:SendEmail only.
It avoids granting broader SES permissions that applications rarely need, keeping the permission surface narrow and easier to reason about.
Example generated policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SESEmailPolicy9474",
"Effect": "Allow",
"Action": [
"ses:SendEmail",
"ses:SendRawEmail"
],
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"2.3.4.5"
]
},
"StringLike": {
"ses:FromAddress": [
"[email protected]"
]
},
"StringNotLike": {
"ses:FromAddress": [
"*@example2.com",
"*@*.example2.com",
"*@example3.com",
"*@*.example3.com"
]
}
}
}
]
}This example allows email sending only when all three conditions are met:
- The sender address matches an approved pattern
- The request originates from known infrastructure
Operational notes
- Always test generated policies in a non-production account first
- Review SES sending limits after applying new restrictions
- Revisit policies when adding regions or changing mail architecture
Disclaimer
- This tool is provided as-is, without warranty
- Generated policies must be reviewed before production use
- No responsibility is accepted for misconfiguration or misuse
- Always confirm behaviour against current AWS documentation and internal governance rules