Posted on Leave a comment

Feedback Loops in Amazon Simple Email Service (SES) (Part 2)

In Part 1, I explained the general feedback mechanisms that are available in Amazon Simple Email Service (SES), and compared their strengths and weaknesses. Now I will explain the different configuration methods that can be used to select a feedback mechanism.

Domain-Level SNS Configuration

You can configure Simple Notification Service (SNS) feedback for an entire domain. Select one of your domains and expand the Notifications section. You can select an SNS topic for bounces, complaints, and deliveries. This is the most straightforward way to enable SNS feedback if you want to treat all email for a domain in exactly the same way.

Address-Specific SNS Configuration

In some cases, you should not treat all email in the domain in the same way. For example, you might have different software environments (dev, staging, production) that use the same domain, but send from different email addresses. Email bounces from Dev should go to developers, bounces from Staging to QA, and bounces from Production to the customer service team. You also might use the same domain for email marketing (not a great idea), and that feedback should go to the marketing team. You can configure each verified email address in SES with a different set of SNS topics.

Configuration Sets

SES Configuration Sets are my least favorite option. However, configuration sets are the only way to send email statistics to CloudWatch or to S3 via Kinesis Firehose, so sometimes you are stuck with using them. The application of a Configuration Set to an email message is determined by setting a special header when submitting the email to SES:


There are several problems with Configuration Sets:

  • Not transparent. In the SES interface, you can see the configuration sets, but you can’t see to which emails each set is being applied.
  • Too easy for a server admin to accidentally break the SMTP server configuration and disable monitoring.
  • A server admin has to get involved if the configuration set needs to be changed.
  • Configuring SMTP servers to set customer headers may be tricky.

I recommend configuring each domain or specific email addresses with SNS topics. Only use configuration sets for getting email statistics into a CloudWatch dashboard.

Posted on Leave a comment

How to “Level Up” your Information System Management

How advanced is your organization’s information system management? Here’s a simple framework for thinking about your organization’s infrastructure management capabilities:

Level 0: We can’t get it to work.

Level 1: We got it working!

Level 2: We got it working and documented the process so that we can set up similar systems on a repeatable basis.

Level 3: We got it working, documented it thoroughly, and implemented the configuration in an automated system to create similar systems. The configuration is version-controlled, and we can track changes.

Of course, these four levels are a little over-simplified. For example, there’s a state between Level 1 and Level 2 in which you got one system working and documented it, but haven’t tested the process by configuring a fresh instance from scratch. When you’re doing something for the first time, you tend to try a lot of things, and sometimes you can’t be sure which one actually solved the problem. The first draft of the documentation may not reflect the minimum necessary steps to get the system working. Ideally, you’d have a different person follow the procedure on a fresh system, to make sure the documentation contains the “necessary and sufficient” information.

Which level is right for your organization? It depends on what meets the organization’s needs at time. A stable business that depends upon a complex information system needs to operate its core systems at Level 3. However, that same company’s internal R&D may operate at Level 0, 1, or 2. An early-stage start-up that’s building an MVP (minimum viable product) and searching for product/market fit should probably operate at Level 1 or 2. When you have limited capital and are struggling to find product/market fit, getting to Level 3 too quickly might waste precious resources that could go into product development. However, the startup’s management needs to remember that the MVP will incur technical debt that will have to be paid off as the product matures.

Craig Finch & Mike Soule, Rootwork’s experienced infrastructure management consultants, would be happy to help you evaluate your organization’s capabilities and develop a plan to make sure that your information systems meet your needs.

Posted on Leave a comment

Amazon Simple Email Service Feedback Loops

Amazon Simple Email Service (SES) is a lean, low-cost option to send bulk email. However, the low cost of SES comes at a cost; it lacks many features that are built into SendGrid or other email services. You have to build your own “features” with combinations of other AWS services. The figure below summarizes some useful integrations that provide monitoring and feedback loops.

Diagram showing how Amazon SES integrates with other services to monitor email sending, bounces, and abuse complaints.


The Dashboard you see in SES is very primitive, with a very limited time series of data. CloudWatch allows you to create your own dashboard to monitor critical parameters, such as bounce and complaint rates. SES will put you on probation or terminate your service if you are suspected of sending spam. CloudWatch also lets you set events that will be triggered when a threshold is crossed.

Kinesis Firehose to S3

Kinesis Firehose is a “data bus.” It accepts data from various sources, transforms it (if necessary), and passes it on to other endpoints. In the context of SES, you can set up a Kinesis Firehose to push email notifications into Amazon S3 storage. It automatically creates a datetime-based folder hierarchy within S3 and stores a JSON file for each event. This maze of folders makes it rather hard to navigate the data by hand.

Logging email events to S3 is not very useful, in my experience, but there might be use cases that I haven’t thought of. Maybe you could set up an AWS Lambda function to watch for abuse notifications that appear in a bucket and take some action-but if you are doing that, you might as well use SNS to send directly to Lambda.

Simple Notification Service

Simple Notification Service, or SNS, is probably the most useful destination for SES data. A SES configuration set can send data directly to an SNS topic. An SNS subscription can listen to one or more topics and send data to a destination, which is one of the following:

  • HTTP
  • Email
  • Email (JSON)
  • Amazon SQS
  • AWS Lambda
  • Platform application endpoint
  • SMS

Personally, I like the HTTPS endpoint the best. You build an API endpoint that receives email feedback, and SNS will POST JSON to your endpoint every time an email bounces or a complaint is registered. Then, your application take immediate action to flag the address and stop sending to it, which is good for your sending reputation.