Without a configuration set, SES sends your mail and tells you very little about what happened. With one, every event becomes a message you can act on.
What it controls
A configuration set bundles settings that apply to mail sent with it:
- Event destinations. Where bounces, complaints, deliveries, rejects, delays, opens and clicks are published.
- Reputation metrics. Whether SES tracks bounce and complaint rates for this set separately.
- Dedicated IP pool. Which pool of dedicated IPs the mail uses.
- Suppression settings. Whether this mail overrides the account’s suppression list behaviour.
- Tracking. Open and click tracking, and the domain used for tracking links.
You choose the set when you send, by naming it in the API call or an SMTP header.
Publishing events
An event destination is a place SES writes events to. For monitoring, the common route is an SNS topic. SES publishes each event as a JSON message and SNS fans it out to whatever subscribes, such as an HTTPS endpoint for an external tool.
A set per purpose
Many teams use several sets, for example one for transactional mail and one for marketing. That gives you separate metrics and separate reputation tracking per stream, and you can send each through its own IP pool.
What to remember
Mail sent without a set carries no event publishing. If a dashboard looks empty or incomplete, check that your application names the right set on every send. A forgotten set on one code path is a common cause of missing events.
Common questions
Do I have to use a configuration set?
To receive event data for opens, clicks, deliveries and delays you do, because those events are only published for mail sent with a set. Bounce and complaint notifications can also be set up on the identity itself.
Where can events go?
SES can publish events to SNS topics, Kinesis Data Firehose, CloudWatch and EventBridge, among others. SNS is the usual choice for feeding an external tool.