Category: Best Practices

Creating a Daily Dashboard to Track Bounces and Complaints

(Edited July 11, 2017)—We added a link to a CloudFormation stack in the “Building a Daily Dashboard” section. You can use the CloudFormation stack to create the daily dashboard in a few simple steps.

Bounce and complaint rates can have a negative impact on your sender reputation, and a bad sender reputation makes it less likely that the emails you send will reach your recipients’ inboxes. Further, if your bounce or complaint rate is too high, we may have to suspend your Amazon SES account to protect other users. For these reasons, it is very important that you have a process in place to remove email addresses that have bounced or complained from your recipient list.

This article includes background information about bounces and complaints. It also discusses a sample solution that you can use to keep track of the bounce and complaint notifications that you receive.

What is a Bounce?

A bounce occurs when a message cannot be delivered to the intended recipient. There are two types of bounces:

  • A hard bounce occurs when a persistent issue prevents the message from being delivered. Hard bounces can occur when the recipient’s email address does not exist or the receiving domain does not exist. When an email hard bounces, it means that the recipient did not receive the message, and Amazon SES will no longer attempt to deliver the message.
  • A soft bounce occurs when a temporary issue prevents a message from being delivered. Soft bounces can occur when the recipient’s mailbox is full, when the connection to the receiving email server times out, or when there are too many simultaneous connections to the receiving mail server. When an email soft bounces, Amazon will attempt to redeliver it. If the issue persists, Amazon SES will stop trying to deliver the message, and the soft bounce will be converted to a hard bounce.

To learn more about bounces, see the Amazon SES Bounce FAQ in the Amazon SES Developer Guide.

What is a Complaint?

When an email recipient clicks the Mark as Spam (or similar) button in his or her email client, the ISP records the event as a complaint. If the emails that you send generate too many of these complaint events, the ISP may conclude that you’re sending spam. Many ISPs provide feedback loops, in which the ISP provides you with information about the message that generated the complaint event.

For more information about complaints, see the Amazon SES Complaint FAQ in the Amazon SES Developer Guide.

Building a Daily Dashboard

We recently added a section to the Amazon SES Developer Guide that documents the process of creating a daily bounce and complaint tracking dashboard. You can find the procedures for creating this daily dashboard at

Alternatively, you can download our CloudFormation stack to implement this solution with just a few clicks. To learn more about deploying CloudFormation stacks, see “Get Started” in the AWS CloudFormation User Guide.

This solution uses several AWS components—including Simple Notification Service (SNS), Simple Queue Service (SQS), Identity and Access Management (IAM), Simple Storage Service (S3), Lambda, and CloudWatch—to create a dashboard that is emailed to you every day. The daily dashboard, illustrated in the following image, contains a list of the messages that generated bounces and complaints over the past 24 hours.

This solution uses SNS to track bounce and complaint notifications. Those notifications are then collected in an SQS queue. A CloudWatch trigger initiates a Lambda function, which collects the notification events from SQS, processes them, publishes a dashboard to an S3 bucket, and sends you an email when the dashboard is ready to view. The following image illustrates the architecture of this solution.

When you receive the daily dashboard, you should use it to remove the addresses that hard bounced or complained from your recipient list. This measure will help protect your deliverability and inbox placement rates.

This solution is just one method of tracking the bounces and complaints that you receive when sending email using Amazon SES. We hope you find this sample solution useful. If you have any questions about this solution, please leave a comment below, or start a discussion in the Amazon SES forum.

Do Your Recipients Know Who You Are?

When you send an email for your organization, you want your recipients to read it. For that to happen, your email needs to be delivered, and your recipients need to identify the mail as valuable and worth reading. Of course, you need to provide valuable content in the email itself, but there is more to it: If the email is not clearly branded and identifiable as being from the entity that the recipient signed up to get email from, recipients are likely to ignore your mail, or, worse, hit the “this is spam” button.

As such, SES requires that you clearly align the emails you send with your organization by following the best practices outlined in this blog post.

Before we begin…

First make sure that you are only sending mail to people who signed up to receive email from you directly, not addresses you acquired in any other way. For example, do not send mail to bought or rented lists, addresses collected by your partners, or recipients who signed up with another brand that you own. See the Amazon SES Developer Guide for guidelines on how to obtain and maintain your recipient list.

Clearly aligning your emails with your organization

If you are sending an email to people who signed up to receive mail from, then the following should always be true: 

  1. The "From" address of the email should be The "From" address is the address from which you send the emails. This is the email address or domain you verified with SES.
  2. The "Friendly From" name should clearly be associated with The "Friendly From" name is the name that displays as the sender of the email in the recipient’s email inbox.
  3. The email itself should clearly be branded as a message from Small text in a footer is not sufficient. A good example of branding is to prominently display the logo of in the email.
  4. The email should include a reminder of why the user is getting the message. For instance, you could include a sentence such as "You signed up to get mail from on March 24, 2015."

Example 1: Promotional mail for partners

One example we have seen a lot is that users sign up with a site that promotes deals of some sort, with the expectation that the site will send them mail about deals, special promotions, etc. However, the mail they actually receive is branded as the product with the deal (the partner’s brand) rather than the brand of the site they signed up with. As far as users can tell, they’re getting messages from the partner company – a company they did not sign up with – marketing a variety of products and services. 

There is no easy way for users to see that these messages are actually coming from the deal site that they signed up with. Perhaps this information is visible if they look closely at the small print in the footer of the email, but generally speaking, this isn’t good enough. In these cases, users can easily end up getting annoyed by this mail and hitting the spam button. They may have signed up with the deal site, but they did not sign up with the individual companies that they appear to be getting mail from.

The solution is simple. Make sure the promotions are sent from the deal site. Make sure the mail itself is branded prominently with the deal site’s logo. Include an introductory statement like, “Here is today’s deal from the deal site.” Underneath that, include the promotion for the third party. Then it is absolutely clear to the recipient that the message from the third party is a service of the deal site that the recipient actually signed up with.

Example 2: Election mail

Here is a similar example in another sphere:  It is election season, and someone signs up with a political party to get mail from that party. The party wants to promote candidates that are running for a variety of offices. The party sends mail that looks like it is from Candidate X to people who live in the right geographic area to vote for Candidate X. Candidate X is from the party that these people signed up to get email from, so this is no problem, right? Wrong. If people signed up with the political party, it is okay to send mail from the party, but unless they specifically signed up to get mail from Candidate X, it is not okay for Candidate X to send them mail.

The solution is the same as for the deal site: The party can send the mail, but the mail has to clearly be from the party itself. The party can indicate this with the "From" domain, the "Friendly From" name, and the branding in the mail. The party should also begin with a quick message that says “We thought you would be interested in this message from Candidate X…” Once again, things are aligned: Users only get email from the organization they signed up with, and this is absolutely clear just by glancing at the email they receive.

This is about best practices, not the law

In both of the cases above, there may well be language at the original site indicating that by signing up with the site, recipients are giving permission for partners, affiliates, or third parties to email them. By including this sort of language, this kind of sending may well be legal, and the recipient may have technically given permission for it.

However, this kind of sending is still problematic and may cause us to revoke your ability to send mail with SES. Unless a user explicitly and directly signed up with the organization that, on casual inspection, appears to be sending them mail, there is a high likelihood that the message will be identified as spam either explicitly by the user or by automated algorithms that track engagement. To protect our ability to deliver high quality mail for all senders, SES requires that senders on our platform make it obvious to the recipient that messages are from an organization the recipient signed up with. If this is not obvious, then we consider the message to be unsolicited.


The important thing here is alignment. If a user signs up with a particular organization, then that organization — and only that organization — should send the user email: no partners, no other brands, no affiliates, no third parties. To avoid confusion, the mail itself has to make its connection to the organization the recipient signed up with absolutely clear. Obscuring that connection can confuse users and make your mail look unsolicited, even if the user did in fact sign up for your mail. Mail without a clear connection to the original organization the recipient signed up with is not allowed on SES.

Keep your sign-ups, "From" addresses, and the branding of your messages aligned, and you should be in good shape!

Amazon SES Best Practices: Top 5 Best Practices for List Management

If you are an Amazon SES customer, you probably know that in addition to managing your email campaigns, you need to be mindful of your reputation as an email sender.

Maintaining a good reputation as a sender is vital if you rely on email delivery as part of your business – if you have a good reputation, your emails have the best chance of arriving in your recipients’ inboxes. If your reputation is questionable, your messages could get dropped or banished to the spam folder. Recipient ISPs may also decide to throttle your email, preventing you from delivering emails to your recipients on time.

This blog post provides five best practices to help you keep your email-sending reputation and deliverability high by focusing on the source of most deliverability problems: list acquisition and management.

Without further ado, here are our Top 5 Best Practices for List Management:

1. Use confirmed opt-in (a.k.a. double opt-in or the gold standard).

The principle behind this is simple – when a user enters an email address on your website, you need to verify that the address is legitimate before you add it to the mailing list you use for your regular campaigns. To this end, you send a verification email to the address and ask the subscriber to click a link in the email, which will then enable the account. By clicking on this link, the email address owner is confirming that they are willing to receive the email notifications they signed up for on your website. The benefits of this practice are evident:

  • You will not send to an email address more than once (or a few times, if the customer requests a second verification email). If the address is fake (or a typo) and the email is sent to someone who doesn’t want to hear from you, then you are less likely to get a complaint from this person because they will only get one email.
  • Since your actual mail campaigns are only going to addresses you have verified, then you know that you are making good use of your resources and that your campaigns are actually appreciated by the recipients.

2. Process bounces and complaints.

SES provides feedback on bounces and complaints through SNS (or email) to make it easy for you to be alerted of addresses that bounce or recipients who complain. If you get a hard bounce or a complaint, you should remove that email address from your list. You should also identify the root cause of the bounces and complaints. For example, say that you notice that your bounce rate for new subscriptions is rising. This could be an indicator that people are signing up for your service using fake email addresses. While it is not unusual for someone to sign up using a fake email address, you need to make sure that you are not encouraging your customers to do so. One way in which you could be encouraging customers to do this is by giving away free stuff without asking for a confirmed opt-in. If you are in this situation, you need to change the incentive that drives customers to sign up using fake addresses: either remove the gifts or implement confirmed opt-in (there is a reason we call this the gold standard J).

3. Remove non-engagers.

You need to operate under the assumption that if a customer is not opening or clicking your email, then they are not interested in what you’re sending. Define a timeframe that makes sense to your business, and if a recipient doesn’t interact with your mail within that timeframe, stop emailing them. This tactic is a great complement to double opt-in and should be standard for any email sender. Regardless of whether a customer originally opted in through double opt-in or just a regular signup, an email address can go stale and become a spamtrap.  Spamtraps are silent reputation traps, which means that you will get no indication that you are hitting them – removing non-engagers is the only way to avoid them. They are used by many organizations to measure a sender’s reputation, and particularly how well the sender is measuring engagement. If you continue to email spamtraps, your mail could end up in the spam folder, your domain could be blacklisted, and SES could suspend your service.

4. Make it easy for your recipients to unsubscribe.

If you are sending bulk email (as opposed to mail that is the result of a transaction), then you need to make it easy for customers to opt out of the mail. Include an easy-to-spot opt-out link in every bulk email, and use the list-unsubscribe header for easy integration with ISPs who support it. If a customer does not want the mail, you should not send it to them. Sending email to an unwilling recipient will do more harm than good. In many locations, including the US, Canada, and much of Europe and Asia, enabling recipients to easily opt out of your email is a legal requirement.

5. Keep your mailing lists independent.

If you operate more than one website, you should never mix your subscriber lists. Customers who sign up for website A should never (under any circumstance) receive an email from website B, unless they sign up for that one too. The reason is simple: These customers have only agreed to receive email from website A. Furthermore, if your customers get mail from a website unknown to them, they are likely to mark that mail as spam, thus hurting your email reputation.

Never forget: Your email campaigns are only as good as their ability to reach your customers, and following best practices can be the difference between a delivered and a dropped email. While the above best practices should help you, list management is only a part of the equation – the quality of your content also plays a big role in your ability to deliver email. Nevertheless, we hope our recommendations in this post will prove useful in your email endeavors.

If you have questions, feel free to let us know via the SES Forums or in the comment section of this blog.

Credentials and SES

Hi SES senders,

In this blog post I’ll explain which security credentials you need to use depending on how you connect to SES. By “credentials,” I’m referring to identifiers (username/password, AWS access keys, etc.) that you use when you access SES in some way – through the API, SMTP interface, or AWS Management Console.

Credentials are important because they identify you to AWS, and (if uncompromised) protect your account from unauthorized use, but there are a couple of different types of credentials you might use depending on what you’re doing with SES. That is sometimes where people run into trouble. For example, we periodically hear from new customers who are unable to connect to SES’s SMTP interface, and often the reason is because they are using their AWS credentials instead of their SES SMTP credentials.

What do you want to do?

There are three ways you can interact with SES:

Below, we’ll look at which credentials you need to use to access SES in each of those ways.

Signing into the AWS Management Console

You can use the AWS Management Console to do things like check your sending statistics, view your sending limits, send a test email, configure your feedback settings, and so on. To sign into the console, you use one of these sets of credentials:

  • An Identity and Access Management (IAM) username and password (Recommended)
  • The email address and password associated with your root AWS account (NOT recommended, as explained shortly)

Here is a quick rundown on the difference between IAM credentials and root account credentials: When you signed up for AWS, you specified an email address and password. These root-level credentials (a.k.a. root account credentials) are associated with your AWS account, and you can use them to sign into the AWS Management Console, Support Center, etc. Your root-level credentials allow unrestricted access to your account, including your billing information and any AWS services you’re using. For security purposes, we strongly recommend that you store your root-level credentials in a safe place, and use them only when you need to access your account and billing information.

Instead of using your root-level credentials, you should create IAM users, which are identities that you give other people/processes so that they can access your resources. You can create an IAM user that is highly restricted or allowed to do most anything the root account can – it’s your choice. For example, you could create an IAM user that can sign into the console and make requests to SES, but not allow access to any other AWS service or billing information. The important thing is that you can control the IAM user’s permissions and delete the IAM user at any time. You give your IAM users a username and password, and they sign in to your AWS Management Console by going to a sign-in page specific to your account (you’d give them the URL). For a comprehensive discussion of IAM best practices, go here.

Accessing SES through the SES API (by HTTPS, AWS SDK, AWS CLI, or AWS Tools for Windows Powershell)

To call SES through its API, you need AWS access keys, which consist of an access key ID and secret access key. How you generate your AWS access keys depends on whether you want to create AWS access keys for an IAM user (highly recommended) or for your AWS root account (NOT recommended, as explained in the previous section). Here is where to go for both:

Accessing SES through the SMTP interface

You might choose to use SES’s SMTP interface because it’s one of the easiest ways to set up SES – for example, you can configure any number of SMTP-compatible programs or an email server you already use (like Sendmail/Postfix/PHPMailer) to send through SES, or you might call SES through the built-in SMTP functions of a programming language like Java.

To connect to the SES SMTP interface, you use your SES SMTP credentials. You can get your SES SMTP credentials one of two ways:

  • Using the SES console. Click SMTP Settings in the left pane, and then click Create My SMTP Credentials.
  • Converting AWS credentials (more complicated, requires programming) by following the procedure in the Developer Guide.

Although your SES SMTP credentials look very much like AWS access keys – they are both alphanumeric strings – they are not the same! If you try to connect to the SES SMTP interface with your AWS credentials, the connection attempt will fail. SES SMTP and AWS credentials are related, though. SES SMTP credentials are in fact a type of IAM credentials, and if you want an existing IAM user to be able to access the SES SMTP interface, you can convert their AWS credentials to SES SMTP credentials. This requires programming, but we have an example here to get you started. Some people choose this method so that they can automate the SES SMTP credential creation process.

An IAM user can also create SMTP credentials by using the SES console, but that IAM user’s policy needs to give them permission to use IAM itself, because SES SMTP credentials are created through IAM. If the IAM user tries to create SES SMTP credentials using the console and they don’t have IAM permissions, they will get a pop-up error that says “… not authorized to perform iam:ListUsers…” In that case you would need to modify their policy so they have access to IAM.


Here is a summary of the credentials you use to access SES in various ways:

  • To sign into the console, you can use an IAM username and password (recommended) or root account email address and password (not recommended).
  • To use the API (HTTPS/SDK/CLI/AWS Tools for Powershell), you need an AWS access key ID and secret access key. We recommend that you create these credentials for an IAM user rather than the root account.
  • To use the SMTP interface, you need SES SMTP credentials.

For a table that lists the different types of credentials, see the Developer Guide.

Thanks for using SES!

Can I use multiple AWS Accounts with SES?

07/03/17 Update: You can now verify as many as 10,000 identities per AWS account. See this forum announcement for details.

Short answer:

Yes, but with restrictions.

Long answer:

SES is generally structured around the idea that each AWS account is independent in its sending and can be treated as a separate entity.  We realize however that there are a variety of situations in which one actual underlying entity may need or want to send from multiple AWS accounts.  A few examples would be:

  • You need to send from more than 1000 verified identities.
  • You send several different streams of email with distinctly different content and you want to separate them completely for billing or other reasons.
  • You send on behalf of several different clients, and you want to keep their sending separate.
  • You want to use both dedicated IPs and shared IPs for your sending, or you are in the process of transitioning from shared IPs to dedicated IPs.
In these types of cases, and some others, sending from multiple AWS accounts may be a good way for you to use SES.  If you are going to do so, keep the following in mind:


  1. Generally, you should request production access for one account at a time.  Once one account is fully established and sending mail, request production access for the next account.  If you request production access for multiple accounts at once, you will need to provide a detailed explanation about what you are trying to do, since we don’t have the history of any of the accounts to judge anything by.
  2. Each time you request production access for an additional account, include a full explanation (in the use case field of our form) of why you need to use multiple accounts instead of continuing to use the account(s) you already have. We’re going to ask for it anyhow if you leave it out, so you are better off just making sure to include the information up front.
  3. Each time you request production access for an additional account beyond the second account, we will look at the sending from existing accounts to make sure the content on each existing account is clearly different from the others. SES’s expectation is that each AWS account should be sending a clearly distinct stream of email. Why?  Well, we want to make sure people aren’t just splitting their sending between many separate accounts to try to avoid detection of bad sending patterns.  If we find that the email being sent from the existing accounts looks similar in nature, we will ask you if you can please consolidate your existing sending before you request production access for additional accounts. If there is a significant reason why the content needs to be the same across multiple accounts, you can reply and explain it to us. After we review we will let you know whether we’ve made an exception and granted you production access to the new account.  If you know the content looks similar, save yourself the back and forth and just explain it to us in the use case section of the production access form to begin with.
  4. If any existing account is on probation, we will not grant additional accounts until that situation is resolved.
  5. If any of the accounts gets shut down for bad sending practices, it puts the sending status of the other accounts at risk if they are engaging in similar practices, even if they haven’t yet triggered our alarms separately.

As you may have noticed above, there are a couple places where we might reply to your production access requests with a request for more information.  If that is our response, it is important to remember that we are not denying you production access on the new account, we are just asking for more information before we make a decision.

If you keep all of these things in mind, you should be able to send successfully with SES through multiple AWS accounts.

What do I do if my registration emails themselves have high bounce rates?

We occasionally hear from customers we have pinged about high bounce rates that they are already doing everything they can… Specifically, they remove addresses that bounce and make sure they never send to them again, and when someone registers for their website or service, they send an initial confirmation mail that the user needs to click on to opt in. If the user never clicks on that message, they don’t get emailed again. Yet, these customers might still have an unacceptably high bounce rate…due to the registration process itself.

What is going on here?

There may be an issue of typos, especially if your site is aimed at younger or mobile users. This usually isn’t enough to cause an excessive bounce problem by itself, but it’s also easily mitigated. Just ask for the email address twice, and don’t accept it if the entries don’t match. That will make this particular problem mostly go away.

It’s very likely that the problem is more deeply ingrained with your process, though. Almost all of our customers who run into this problem find out that people are registering for their site by intentionally using fake email addresses – for example, entering something like instead of their real email address. There may be enough people doing this to cause you to have an excessively high bounce rate. Having high rates of bounces is viewed by many mailbox providers as a strong indication of a low quality sender, and that kind of sending can have implications to not only your deliverability, but to SES’s deliverability as a whole. So we require that all SES users keep their bounce rates low.

Now, there are some services out there that you can pass email addresses to that will give you a classification as to how likely the address is to be a “good” address. For some use cases, those services can be helpful. But in this kind of situation, it doesn’t get to the underlying problem, which is that users are intentionally giving you fake addresses. There are typically two reasons people do this:

A) They don’t actually want to get email from you and/or they don’t trust you with that information.

B) They can give a fake address and still get access to the website/feature/application that they are interested in.

As such, the main way to solve the problem is to attack one of those two issues. Ultimately, you need to look at how you are structuring/incentivizing your registration process such that you are unintentionally encouraging the use of fake addresses.

Approach #1, addressing A) above: Let the user register with you without providing an email address. Let them choose a user ID or use some other form of registration. ONLY ask for an email address at the moment the user is actually proactively asking to have you send them email. This way, the user has no reason to give you a fake address. They can access all the features you are offering without giving you an email address. If they are actually signing up for you to send them something, it would be pointless to provide a fake email address, because then they won’t get whatever it is they want. And if they just don’t trust you with their address, they won’t sign up for you to send them information by email. This is generally the preferred approach from a best practices point of view, because it also ensures that users really want your email, and aren’t just getting it as a side effect of signing up.

Approach #2, addressing B) above: If you do decide to require an email address at sign-up time, don’t actually let the user access the incentives behind the signup until they click on a verification link in your first email. Note that for this approach to work, you must make it clear to the user at the point they are providing the email address that they will need to complete the verification step before they can download the app (or get whatever it is they are signing up for). This way, the user knows that giving you a fake address is pointless. If they try to access whatever they signed up for, they won’t get anything other than a screen that says they still need to verify their address to continue, so they won’t bother. If they truly want your application or service, they will provide a real address. This does add a bit of friction to your sign-up process, but will most likely make the fake-address problem go away. If the increased friction is unacceptable, consider Approach #1 instead.

There are pros and cons to both of these approaches, and which one is better for you will depend on the details of what you are doing. There may be other approaches that will work as well, but these are the two that, in our experience, most directly address the underlying problem in these cases.

Remember, if your bounce problem is caused by people submitting invalid email addresses during your registration process, that problem is not unsolvable — it just takes a bit of thinking about why your users are doing what they are doing, and changing your process to discourage them from providing bad information. By fixing this issue, you can not only lower your bounce rates, but the users that do end up subscribed to your mail will generally be more engaged anyway.

DKIM Troubleshooting Series: Deliverability Considerations

Hello and welcome to the last entry in the Amazon SES DKIM troubleshooting blog series. So far, we have seen various technical problems that appeared between us and properly signed emails, and we also saw how DKIM helps protect our domain from various impersonators. We will now see whether DKIM can also improve our deliverability (the likelihood that our emails will arrive in our recipients’ Inboxes as opposed to their Spam or Junk folders).

Why are my emails still getting to the spam folder, even if I am properly using DKIM?

Ok, we have set up proper authentication, but now we need to focus on a new problem. Our emails are still arriving in the Spam folders of our customers for a major ISP. We cannot understand what’s wrong. Wasn’t DKIM supposed to prevent that?

DKIM is a great way to show ISPs that the emails we send actually belong to us. It also helps ISPs differentiate our traffic from other emails originating from the same IP address, by associating our email with our domain reputation. This way, we’re giving ISPs the opportunity to decide whether to place our emails in the Spam or Inbox based on our domain reputation regardless of the actual originating IP address.

What DKIM doesn’t do, however, is influence our domain’s actual standing with ISPs. By signing the email, our domain took responsibility for its content. If that content is unsolicited, for example, and the recipient clicks the "Report Spam" button, then we will be in trouble, and so will emails originating from our domain. Alternatively, if we are sending a high-quality email which is gladly accepted by our recipients, our good (domain) reputation will follow across outgoing IP addresses.

We start reading the Amazon SES Email Sending Best Practices whitepaper and discover the different building blocks of developing a rock-solid sending reputation. For example, we can start by analyzing our high complaint rate and investigating what we can do to reduce it. This is no longer a matter for this blog post though…

This seven part blog post series covered the most common issues we notice our customers having when they set up EasyDKIM with SES. We hope to have shed some light on details of this process that are more obscure on first sight. If you haven’t found the answer to your problem here, if the suggestions in these posts don’t work for you or if you just want to say hi, we invite you to post on the Amazon SES Forum and ask any questions you may have.

Happy sending and thank you for using SES!

Never send to old addresses, but what if you have to?

The best practice is to only send mail to people who have specifically asked for your mail, and who have recently interacted with your site.  "Interacted" can mean different things to different people, but generally it means they have logged in to your website, they have recently done business with you, or they have opened or clicked one of your recent emails.  For more, see our best practices document (PDF).

But, what if up to this point you haven’t been tracking those things?  You have a list of addresses that you have acquired over the years, but you don’t have a mechanism in place to know when each one last interacted with you, or perhaps you don’t have a record of how each of those addresses got into your system in the first place.  Maybe you haven’t even been removing addresses that bounce or complain.  Ouch!  This is going to be a problem!  

If you just start sending to that list, you have a very high probability of running into problems.  Some of the addresses may no longer be valid, especially if you have not been removing addresses that bounce.  Other recipients may have interacted with you so long ago that they don’t remember you and are now quite likely to mark your messages as spam.  Some old addresses may even have been transformed into spamtraps over the years.  So now it is very probable that you will get flagged for having too high a bounce or complaint rate or even be reported for hitting spamtraps.

You want to be able to improve this situation.

So what do you do?

Before anything else, you need to set up your system to process any bounces and complaints your sending generates, if you aren’t already doing so.  Information on how to do so with SES is here.

You also should set up a mechanism to track both how you acquire new addresses (direct sign up, transactions, etc.) and also when the last interaction with each address happens (open, click, visit, purchase, etc.).  The mechanisms you use for these things are highly dependent on your business and your own use cases, so we won’t get into that in this post, but it is crucial for pruning your list of addresses that are no longer interacting with you.

At this point, the addresses on your mailing list will fall naturally into one of two categories:  addresses for which you have this tracking information ("good addresses") and addresses where you do not ("questionable addresses").

Because sending to questionable addresses is highly risky and can possibly generate high bounce and complaint rates, you want to make sure that any such sending is balanced by good sending…  quite a bit of good sending.  

We recommend that you send at least 20 messages to "good addresses" for every one you send to a questionable address.  This way, you’re makings sure that the bulk of your sending is to known good addresses that have not bounced, and to recipients you have recently engaged with.  Meanwhile you dribble out a small flow of emails to the questionable addresses.

If sending to these these questionable addresses result in bounces or complaints, remove the addresses from your list immediately and never send to them again.  If your emails are delivered without incident, you can move them into your “good addresses” pool.

Over time, as long as you also purge addresses that have not interacted with you in some time, you will end up with a list that you can feel safe sending to.

What is DMARC and should you use it?

This past year, the email industry launched a new standard to help senders protect their mail from being spoofed by phishing attempts.  Thus, DMARC was born.  It stands for “Domain-based Message Authentication, Reporting and Conformance.”  It’s a mouthful, but the impact of DMARC is significant.  LinkedIn has a good article describing what exactly DMARC brings to the table.  In a nutshell, DMARC enables you to tell ISPs how to handle email that spoofs your domain (e.g., quarantine, block, etc.).

Here’s how it works:

  1. You, as a sender, authenticate your email using SPF and/or DKIM.  Remember, you can use the Amazon SES Easy DKIM feature to accomplish this.  With authentication, you prove to the ISP that you are in fact the originator of the message.
  2. You publish a DMARC record in your DNS.  Instructions for how to do this can be found here.  For an example record, you can look at the DMARC record for shown below. 897 IN TXT "v=DMARC1; p=quarantine; pct=100;;"

    In English, the record states “For any email failing authentication with a “From” domain of, put in the spam folder 100 percent of the time and send activity reports to”

  3. Once your TXT record is publically published, participating ISPs will look at messages purporting to come from your domain, check whether you have a DMARC record, and if so, perform whatever action you’ve specified in your “p=” field to messages that are not authenticated.
  4. You watch the reports that flow into both the “rua” and “ruf” addresses, where individual and aggregate violation reports are sent. You should verify reports are actually phishing attempts and not your email you didn’t authenticate. If you find a lot of instances of phishing against your domain being reported, you can work with 3rd party vendors to takedown fake domains.
  5. You’re all set!

Please note that DMARC is all or nothing and applies to every email coming into an ISP’s email system in the same way.  This means that if you have any 3rd party email systems sending messages on your behalf (such as a CRM solution or event notification system), you’ll need to set these systems up with authentication or else you risk having that mail treated as phishing attempts.  As noted in step #4 above, watch the incoming reports carefully, especially after you enable DMARC, to ensure you’re not inadvertently telling ISPs to throw away legitimate mail from your domain that just happens to be not be authenticated.  Remember, an ISP will only be able to tell whether email is legitimate if the mail is authenticated from your domain.

As always, let us know if you have any questions.  We believe DMARC is a step in the right direction for curbing phishing email at the ISP level, where you have no visibility into who may be spoofing your domain.

Email Definitions: Complaint Rate

Now that we’ve talked about complaints and feedback loops, we are ready to discuss complaint rates.

As a reminder, a complaint occurs when an email recipient marks an email message as spam by clicking “This is spam” or “send to spam folder” in their web email client. The Internet Service Provider (ISP) records this as a complaint. If the ISP has a feedback loop in place with the Email Service Provider (ESP), the ESP is notified. If you are using Amazon SES, then Amazon SES is the ESP and it forwards the complaint to you by email or by using an Amazon Simple Notification (SNS) topic, depending on how you have your system set up. (For more information, see Handling Bounces and Complaints.)

You can calculate the overall complaint rate by dividing the total number of complaints by the number of emails sent:

Complaint rate

However, this doesn’t necessarily give you an accurate idea of the complaint rates that ISPs are seeing, because not all ISPs have feedback loops set up with your ESP (e.g., Amazon SES). In order to get a better picture, you can calculate your complaint rate per ISP or domain (e.g.,  For each domain or ISP, you would use something like this:

Yahoo's complaint rate

Your target for each ISP that is sending you complaints should be for each ISP’s complaint rate to be less than 0.1%. ISPs are trying to make their users happy, so they take complaints very seriously. Try to keep your complaint rates very low, even if you need to calculate them some other way.

If you trace a complaint back to a specific recipient, you should remove that recipient from your list so that they don’t get that type of email from you again. In other words, if you receive a complaint from a recipient for a marketing email, you should stop sending them your marketing email but continue to send them transactional email. For more information about how to keep complaint rates low, see Amazon Simple Email Service Email Sending Best Practices. Happy emailing!

Note added 2015-12-04: For SES specifically, we expect our senders’ complaint rates to remain below 0.1%. Senders with a complaint rate exceeding 0.5% risk suspension.