# How email sending works in Amazon SES
How Amazon SES works

This topic describes what happens when you send an email with SES, and the various outcomes that can occur after the email is sent. The following figure is a high-level overview of the sending process:

![\[Email sending process with Amazon SES, showing potential bounces, complaints, and delivery outcomes.\]](http://docs.aws.amazon.com/ses/latest/dg/images/arch_overview-diagram.png)


****

1. A client application, acting as an email sender, makes a request to SES to send email to one or more recipients.

1. If the request is valid, SES accepts the email.

1. SES sends the message over the Internet to the recipient's receiver. Once the message is passed to SES, it is usually sent immediately, with the first delivery attempt normally occurring within milliseconds.

1. At this point, there are different possibilities. For example:

   1. The ISP successfully delivers the message to the recipient's inbox.

   1. The recipient's email address does not exist, so the ISP sends a bounce notification to SES. SES then forwards the notification to the sender.

   1. The recipient receives the message but considers it to be spam and registers a complaint with the ISP. The ISP, which has a feedback loop set up with SES, sends the complaint to SES, which then forwards it to the sender.

The following sections review the individual possible outcomes after a sender sends an email request to SES and after SES sends an email message to the recipient. 

## After a sender sends an email request to SES


When the sender makes a request to SES to send an email, the call may succeed or fail. The following sections describe what happens in each case.

### Successful sending request


If the request to SES succeeds, SES returns a success response to the sender. This message includes the *message ID*, a string of characters that uniquely identifies the request. You can use the message ID to identify the sent email or to track problems encountered during sending (you must [store your own mapping](faqs-enforcement.md#cm-feedback-loop-q8) between an identifier and the SES message ID that SES passes back to you when it accepts the email). SES then assembles an email message based on the request parameters, scans the message for questionable content and viruses and then sends it out over the Internet using Simple Mail Transfer Protocol (SMTP). Your message is usually sent immediately; the first delivery attempt typically occurs within milliseconds.

**Note**  
If SES accepts the sender's request and then determines that the message contains a virus, SES stops processing the message and doesn't attempt to deliver it to the recipient's mail server.

### Failed sending request


If the sender's email-sending request to SES fails, SES responds to the sender with an error and drops the email. The request could fail for several reasons. For example, the request may not be formatted properly or the email address may not have been verified by the sender. 

The method through which you can determine if the request has failed depends on how you call SES. The following are examples of how errors and exceptions are returned:
+ If you are calling SES through the Query (HTTPS) API (`SendEmail` or `SendRawEmail`), the actions will return an error. For more information, see the [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/).
+ If you are using an AWS SDK for a programming language that uses exceptions, the call to SES will throw a *MessageRejectedException*. (The name of the exception may vary slightly depending on the SDK.)
+ If you are using the SMTP interface, then the sender receives an SMTP response code, but how the error is conveyed depends on the sender's client. Some clients may display an error code; others may not.

For information about errors that can occur when you send an email with SES, see [Amazon SES email sending errors](troubleshoot-error-messages.md).

## After Amazon SES sends an email


If the sender's request to SES succeeds, then SES sends the email and one of the following outcomes occurs:
+ **Successful delivery and the recipient does not object to the email – **The email is accepted by the ISP, and the ISP delivers the email to the recipient. A successful delivery is shown in the following figure.  
![\[Email flow diagram showing sender, Amazon SES, receiver ISP, and recipient with successful delivery.\]](http://docs.aws.amazon.com/ses/latest/dg/images/successful-diagram.png)
+ **Hard bounce – **The email is rejected by the ISP because of a persistent condition or rejected by SES because the email address is on the SES suppression list. An email address is on the SES suppression list if it has recently caused a hard bounce for any SES customer. A hard bounce with an ISP can occur because the recipient's address is invalid. A hard bounce notification is sent from the ISP back to SES, which notifies the sender through email or through Amazon Simple Notification Service (Amazon SNS), depending on the sender's setup. SES notifies the sender of suppression list bounces by the same means. The path of a hard bounce from an ISP is shown in the following figure.  
![\[Email flow diagram showing sender, Amazon SES, and receiver with arrows indicating message path.\]](http://docs.aws.amazon.com/ses/latest/dg/images/hard_bounce-diagram.png)
+ **Soft bounce – **The ISP cannot deliver the email to the recipient because of a temporary condition, such as the ISP is too busy to handle the request or the recipient's mailbox is full. A soft bounce can also occur if the domain does not exist. The ISP sends a soft bounce notification back to SES, or, in the case of a nonexistent domain, SES cannot find an email server for the domain. In either case, SES retries the email for an extended period of time. If SES cannot deliver the email in that time period, it sends you a bounce notification through email or through Amazon SNS. If SES can deliver the email to the recipient during a retry, the delivery is successful. A soft bounce is shown in the following figure. In this case, SES retries sending the email, and the ISP is eventually able to deliver it to the recipient.  
![\[Email flow diagram showing sender, Amazon SES, receiver, and recipient with soft bounce scenario.\]](http://docs.aws.amazon.com/ses/latest/dg/images/soft_bounce-diagram.png)
+ **Complaint – **The email is accepted by the ISP and delivered to the recipient, but the recipient considers the email to be spam and clicks a button such as "Mark as spam" in his or her email client. If SES has a feedback loop set up with the ISP, then a complaint notification is sent to SES, which forwards the complaint notification to the sender. Most ISPs do not provide the email address of the recipient who submitted the complaint, so the complaint notification from SES provides the sender a list of recipients who might have sent the complaint, based on the recipients of the original message and the ISP from which SES received the complaint. The path of a complaint is shown in the following figure.  
![\[Diagram showing email flow from sender through Amazon SES, ISP, and recipient, with complaint feedback loop.\]](http://docs.aws.amazon.com/ses/latest/dg/images/complaint-diagram.png)
+ **Auto response – **The email is accepted by the ISP, and the ISP delivers it to the recipient. The ISP then sends an automatic response such as an out-of-the-office (OOTO) message to SES. SES forwards the auto response notification to the sender. An auto response is shown in the following figure.  
![\[Diagram showing email flow from sender through Amazon SES, ISP, recipient, and auto-response back to sender.\]](http://docs.aws.amazon.com/ses/latest/dg/images/auto_response-diagram.png)

  Make sure that your SES-enabled program does not retry sending messages that generate an auto response.
**Tip**  
You can use the SES mailbox simulator to test a successful delivery, bounce, complaint, OOTO, or what happens when an address is on the suppression list. For more information, see [Using the mailbox simulator manually](send-an-email-from-console.md#send-email-simulator).

# Email format in Amazon SES
Email format

When a client makes a request to Amazon SES, Amazon SES constructs an email message compliant with the Internet Message Format specification ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)). An email consists of a *header*, a *body*, and an *envelope*, as described below.
+ **Header—**Contains routing instructions and information about the message. Examples are the sender's address, the recipient's address, the subject, and the date. The header is analogous to the information at the top of a postal letter, though it can contain many other types of information, such as the format of the message. 
+ **Body—**Contains the text of the message itself.
+ **Envelope—**Contains the actual routing information that is communicated between the email client and the mail server during the SMTP session. This email envelope information is analogous to the information on a postal envelope. The routing information of the email envelope is usually the same as the routing information in the email header, but not always. For example, when you send a blind carbon copy (BCC), the actual recipient address (derived from the envelope) is not the same as the "To" address that is displayed in the recipient's email client, which is derived from the header.

The following is a simple example of an email. The header is followed by a blank line and then the body of the email. The envelope isn't shown because it is communicated between the client and the mail server during the SMTP session, rather than a part of the email itself. 

```
 1. Received: from abc.smtp-out.amazonses.com (123.45.67.89) by in.example.com (87.65.43.210); Fri, 17 Dec 2010 14:26:22
 2. From: "Andrew" <andrew@example.com>;
 3. To: "Bob" <bob@example.com>
 4. Date: Fri, 17 Dec 2010 14:26:21 -0800
 5. Subject: Hello
 6. Message-ID: <61967230-7A45-4A9D-BEC9-87CBCF2211C9@example.com>
 7. Accept-Language: en-US
 8. Content-Language: en-US
 9. Content-Type: text/plain; charset="us-ascii"
10. Content-Transfer-Encoding: quoted-printable
11. MIME-Version: 1.0
12. 
13. Hello, I hope you are having a good day.
14. 
15. -Andrew
```

The following sections review email headers and bodies and identify the information that you need to provide when you use Amazon SES.

## Email header


There is one header per email message. Each line of the header contains a field followed by a colon followed by a field body. When you read an email in an email client, the email client typically displays the values of the following header fields:
+ **To—**The email addresses of the message's recipients.
+ **CC—**The email addresses of the message's carbon copy recipients.
+ **From—**The email address from which the email is sent.
+ **Subject—**A summary of the message topic.
+ **Date—**The time and date the email is sent.

There are many additional header fields that provide routing information and describe the content of the message. Email clients typically do not display these fields to the user. For a full list of the header fields that Amazon SES accepts, see [Amazon SES header fields](header-fields.md). When you use Amazon SES, you particularly need to understand the difference between "From," "Reply-To," and "Return-Path" header fields. As noted previously, the "From" address is the email address of the message sender, whereas "Reply-To" and "Return-Path" are as follows:
+ **Reply-To—**The email address to which replies will be sent. By default, replies are sent to the original sender's email address.
+ **Return-Path—**The email address to which message bounces and complaints should be sent. "Return-Path" is sometimes called "envelope from," "envelope sender," or "MAIL FROM."
**Note**  
When you use Amazon SES, we recommend that you always set the "Return-Path" parameter so that you can be aware of bounces and take corrective action if they occur.

To easily match a bounced message with its intended recipient, you can use Variable Envelope Return Path (VERP). With VERP, you set a different "Return-Path" for each recipient, so that if the message bounces back, you automatically know which recipient it bounced from, rather than having to open the bounce message and parse it.

## Email body


The email body contains the text of the message. The body can be sent in the following formats:
+ **HTML—**If the recipient's email client can interpret HTML, the body can include formatted text and hyperlinks
+ **Plain text—**If the recipient's email client is text-based, the body must not contain any nonprintable characters.
+ **Both HTML and plain text—**When you use both formats to send the same content in a single message, the recipient's email client decides which to display, based upon its capabilities.

If you are sending an email message to a large number of recipients, then it makes sense to send it in both HTML and text. Some recipients will have HTML-enabled email clients, so that they can click embedded hyperlinks in the message. Recipients using text-based email clients will need you to include URLs that they can copy and open using a web browser.

## Email information you need to provide to Amazon SES


When you send an email with Amazon SES, the email information you need to provide depends on how you call Amazon SES. You can provide a minimal amount of information and have Amazon SES take care of all of the formatting for you. Or, if you want to do something more advanced like send an attachment, you can provide the raw message yourself. The following sections review what you need to provide when you send an email by using the Amazon SES API, the Amazon SES SMTP interface, or the Amazon SES console.

### Amazon SES API


If you call the Amazon SES API directly, you call either the `SendEmail` or the `SendRawEmail` API. The amount of information you need to provide depends on which API you call.
+ The `SendEmail API` requires you to provide only a source address, destination address, message subject, and a message body. You can optionally provide "Reply-To" addresses. When you call this API, Amazon SES automatically assembles a properly formatted multi-part Multipurpose Internet Mail Extensions (MIME) email message optimized for display by email client software. For more information, see [Sending formatted email using the Amazon SES API](send-email-formatted.md).
+ The `SendRawEmail` API provides you the flexibility to format and send your own raw email message by specifying headers, MIME parts, and content types. `SendRawEmail` is typically used by advanced users. You need to provide the body of the message and all header fields that are specified as required in the Internet Message Format specification ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)). For more information, see [Sending raw email using the Amazon SES API v2](send-email-raw.md).

If you use an AWS SDK to call the Amazon SES API, you provide the information listed above to the corresponding functions (for example, `SendEmail` and `SendRawEmail` for Java).

For more information about sending email using the Amazon SES API, see [Using the Amazon SES API to send email](send-email-api.md).

### Amazon SES SMTP interface


When you access Amazon SES through the SMTP interface, your SMTP client application assembles the message, so the information you need to provide depends on the application you are using. At a minimum, the SMTP exchange between a client and a server requires a source address, a destination address, and message data. 

For more information about sending email using the Amazon SES SMTP interface, see [Using the Amazon SES SMTP interface to send email](send-email-smtp.md).

### Amazon SES console


When you send an email by using the Amazon SES console, the amount of information you need to provide depends on whether you choose to send a formatted or raw email.
+ To send a formatted email, you need to provide a source address, a destination address, a message subject, and a message body. Amazon SES automatically assembles a properly formatted multi-part MIME email message optimized for display by email client software. You can also specify a reply-to and a return path field.
+ To send a raw email, you provide the source address, a destination address, and the message content, which must contain the body of the message and all header fields that are specified as required in the Internet Message Format specification ([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt)).

# Understanding email deliverability in Amazon SES
Understanding deliverability

You want your recipients to read your emails, find them valuable, and not label them as spam. In other words, you want to maximize email *deliverability*—the percentage of your emails that arrive in your recipients' inboxes. This topic reviews email deliverability concepts that you should be familiar with when you use Amazon SES.

To maximize email deliverability, you need to understand email delivery issues, proactively take steps to prevent them, stay informed of the status of the emails that you send, and then improve your email-sending program, if necessary, to further increase the likelihood of successful deliveries. The following sections review the concepts behind these steps and how Amazon SES helps you through the process. 

![\[Circular diagram showing four steps to improve email delivery: understand issues, be proactive, stay informed, and improve program.\]](http://docs.aws.amazon.com/ses/latest/dg/images/deliverability_concepts-diagram.png)


## Understand email delivery issues


In most cases, your messages are delivered successfully to recipients who expect them. In some cases, however, a delivery might fail, or a recipient might not want to receive the mail that you are sending. Bounces, complaints, and the suppression list are related to these delivery issues and are described in the following sections. 

### Bounce


If your recipient's receiver (for example, an email provider) fails to deliver your message to the recipient, the receiver bounces the message back to Amazon SES. Amazon SES then notifies you of the bounced email through email or through Amazon Simple Notification Service (Amazon SNS), depending on how you have your system set up. For more information, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md).

There are *hard bounces* and *soft bounces*, as follows: 
+ **Hard bounce – **A persistent email delivery failure. For example, the mailbox does not exist. Amazon SES does not retry hard bounces, with the exception of DNS lookup failures. We strongly recommend that you do not make repeated delivery attempts to email addresses that hard bounce.
+ **Soft bounce – **A temporary email delivery failure. For example, the mailbox is full, there are too many connections (also called *throttling*), or the connection times out. Amazon SES retries soft bounces multiple times. If the email still cannot be delivered, then Amazon SES stops retrying it.

Amazon SES notifies you of hard bounces and soft bounces that will no longer be retried. However, only hard bounces count toward your bounce rate and the bounce metric that you retrieve using the Amazon SES console or the `GetSendStatistics` API.

Bounces can also be *synchronous* or *asynchronous*. A synchronous bounce occurs while the email servers of the sender and receiver are actively communicating. An asynchronous bounce occurs when a receiver initially accepts an email message for delivery and then subsequently fails to deliver it to the recipient.

### Complaint


Most email client programs provide a button labeled "Mark as Spam," or similar, which moves the message to a spam folder, and forwards it to the email provider. Additionally, most email providers maintain an abuse address (e.g., abuse@example.net), where users can forward unwanted email messages and request that the email provider take action to prevent them. In both of these cases, the recipient is making a complaint. If the email provider concludes that you are a spammer, and Amazon SES has a feedback loop set up with the email provider, then the email provider will send the complaint back to Amazon SES. When Amazon SES receives such a complaint, it forwards the complaint to you either by email or by using an Amazon SNS notification, depending on how you have your system set up. For more information, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md). We recommend that you do not make repeated delivery attempts to email addresses that generate complaints. 

### Global suppression list


The Amazon SES *global suppression list*, owned and managed by SES to protect the reputation of addresses in the SES shared IP pool, contains recipient email addresses that have recently caused a hard bounce for any SES customer. If you try to send an email through SES to an address that is on the suppression list, the call to SES succeeds, but SES treats the email as a hard bounce instead of attempting to send it. Like any hard bounce, suppression list bounces count towards your sending quota and your bounce rate. An email address can remain on the suppression list for up to 14 days. If you're sure that the email address that you're trying to send to is valid, you can override the global suppression list by making sure the address isn't listed in your account-level suppression list and SES will still attempt delivery, but if it bounces, the bounce will affect your own reputation, but no one else will get bounces because they can’t send to that email address if they aren’t using their own account-level suppression list. To understand more about the account-level suppression list, see [Using the Amazon SES account-level suppression list](sending-email-suppression-list.md).

## Be proactive


One of the biggest issues with email on the Internet is unsolicited bulk email (spam). Email providers take extensive measures to prevent their customers from receiving spam. Amazon SES also takes steps to decrease the likelihood that email providers consider your email to be spam. Amazon SES uses verification, authentication, sending quotas, and content filtering. Amazon SES also maintains a trusted reputation with email providers and requires you to send high-quality email. Amazon SES does some of those things for you automatically (for example, content filtering); in other cases, it provides the tools (such as authentication), or guides you in the right direction (sending quotas). The following sections provide more information about each concept.

### Verification


Unfortunately, it's possible for a spammer to falsify an email header and spoof the originating email address so that it appears as though the email originated from a different source. To maintain trust between email providers and Amazon SES, Amazon SES needs to ensure that its senders are who they say they are. You are therefore required to verify all email addresses from which you send emails through Amazon SES to protect your sending identity. You can verify email addresses by using the Amazon SES console or by using the Amazon SES API. You can also verify entire domains. For more information, see [Creating an email address identity](creating-identities.md#verify-email-addresses-procedure) and [Creating a domain identity](creating-identities.md#verify-domain-procedure).

If your account is still in the Amazon SES sandbox, you also need to verify all recipient addresses except for addresses provided by the Amazon SES mailbox simulator. For information about getting out of the sandbox, see [Request production access (Moving out of the Amazon SES sandbox)](request-production-access.md). For more information about the mailbox simulator, see [Using the mailbox simulator manually](send-an-email-from-console.md#send-email-simulator).

### Authentication


*Authentication* is another way that you can indicate to email providers that you are who you say you are. When you authenticate an email, you provide evidence that you are the owner of the account and that your emails have not been modified in transit. In some cases, email providers refuse to forward email that is not authenticated. Amazon SES supports two methods of authentication: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). For more information, see [Configuring identities in Amazon SES](configure-identities.md).

### Sending quotas


If an email provider detects sudden, unexpected spikes in the volume or rate of your emails, the email provider might suspect you are a spammer and block your emails. Therefore, every Amazon SES account has a set of sending quotas. These quotas restrict the number of emails that you can send in a 24-hour period, and the number that you can send per second. These sending quotas help protect your trustworthiness with email providers.

In most cases, if you're a brand-new user, Amazon SES lets you send a small amount of email each day. If the mail that you send is acceptable to email providers, we automatically increase this quota. Your sending quotas steadily increase over time so that you can send larger quantities of email at faster rates. You can also create an [SES Sending Limits Increase case](https://aws.amazon.com/ses/extendedaccessrequest/) to request additional quota increases.

For more information about sending quotas and how to increase them, see [Managing your Amazon SES sending limits](manage-sending-quotas.md).

### Content filtering


Many email providers use content filtering to determine if incoming emails are spam. Content filters look for questionable content and block the email if the email fits the profile of spam. Amazon SES uses content filters also. When your application sends a request to Amazon SES, Amazon SES assembles an email message on your behalf and then scans the message header and body to determine if they contain content that email providers might consider spam. If your messages look like spam to the content filters that Amazon SES uses, your reputation with Amazon SES will be negatively affected. 

Amazon SES also scans all messages for viruses. If a message contains a virus, Amazon SES doesn't attempt to deliver the message to the recipient's mail server.

### Reputation


When it comes to email sending, *reputation*—a measure of confidence that an IP address, email address, or sending domain is not the source of spam—is important. Amazon SES maintains a strong reputation with email providers so that they deliver your email to your recipients' inboxes. Similarly, you need to maintain a trusted reputation with Amazon SES. You build your reputation with Amazon SES by sending high-quality content. When you send high-quality content, your reputation becomes more trusted over time and Amazon SES increases your sending quotas. Excessive bounces and complaints negatively impact your reputation and can cause Amazon SES to reduce the sending quotas for your account, or terminate your Amazon SES account.

One way to help maintain your reputation is to use the mailbox simulator when you test your system, instead of sending to email addresses that you have created yourself. Emails to the mailbox simulator do not count toward your bounce and complaint metrics. For more information about the mailbox simulator, see [Using the mailbox simulator manually](send-an-email-from-console.md#send-email-simulator).

### High-quality email


High-quality email is email that recipients find valuable and want to receive. Value means different things to different recipients and can come in the form of offers, order confirmations, receipts, newsletters, etc. Ultimately, your deliverability rests on the quality of the emails that you send because email providers block emails that they consider to be low quality. 

## Stay informed


Whether your deliveries fail, your recipients complain about your emails, or Amazon SES successfully delivers an email to a recipient's mail server, Amazon SES helps you to track down the issue by providing notifications and by enabling you to easily monitor your usage statistics.

### Notifications


When an email bounces, the email provider notifies Amazon SES, and Amazon SES notifies you. Amazon SES notifies you of hard bounces and soft bounces that Amazon SES will no longer retry. Many email providers also forward complaints, and Amazon SES sets up complaint feedback loops with the major email providers so you don't have to. Amazon SES can notify you of bounces, complaints, and successful deliveries in two ways: you can set your account up to receive notifications through Amazon SNS, or you can receive notifications by email (bounces and complaints only). For more information, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md).

### Usage statistics


Amazon SES provides usage statistics so that you can view your failed deliveries to determine and resolve the root causes. You can view your usage statistics by using the Amazon SES console or by calling the Amazon SES API. You can view how many deliveries, bounces, complaints, and virus-infected rejected emails you have, and you can also view your sending quotas to ensure that you stay within them.

## Improve your email-sending program


If you are getting large numbers of bounces and complaints, it's time to reassess your email-sending strategy. Remember that excessive bounces, complaints, and attempts to send low-quality email constitute abuse and put your AWS account at risk of termination. Ultimately, you need to be sure that you use Amazon SES to send high-quality emails and to only send emails to recipients who want to receive them. 

## At-least-once delivery


Amazon SES stores copies of your messages on multiple servers for redundancy and high availability. On rare occasions, one of the servers that stores a copy of a message might be unavailable when you receive or delete a message.

If this occurs, the copy of the message isn't deleted on that unavailable server, and you might get that message copy again when you receive messages. Design your applications to be idempotent (they should not be affected adversely when processing the same message more than once).

# Best practices for sending email using Amazon SES
Email best practices

The way you manage email communications with your customers is referred to as your *email program*. There are several factors that can lead to the success or failure of your email program; these factors may seem confusing or mysterious at first. However, by understanding how email is delivered, and by following certain best practices, you can increase the chances of your email successfully reaching your customers' inboxes.

**Topics**
+ [

# Email program success metrics
](success-metrics.md)
+ [

# Maintaining a positive sender reputation
](tips-and-best-practices.md)

# Email program success metrics
Success metrics

There are several metrics that help measure the success of your email program.

**Topics**
+ [

## Bounces
](#metrics-bounce-rate)
+ [

## Complaints
](#metrics-complaints)
+ [

## Message quality
](#metrics-quality)

## Bounces
Bounce Rate

A *bounce* occurs when an email cannot be delivered to the intended recipient. There are two types of bounces: *hard bounces* and *soft bounces*. A hard bounce occurs when the email cannot be delivered because of a persistent issue, such as when an email address doesn't exist. A soft bounce occurs when a temporary issue prevents the delivery of an email. Soft bounces can occur when a recipient's inbox is full, or when the receiving server is temporarily unavailable. Amazon SES handles soft bounces by attempting to re-deliver soft bounced emails for a certain period of time.

It's essential that you monitor the number of hard bounces in your email program, and that you remove hard-bouncing email addresses from your recipient lists. When email receivers detect a high rate of hard bounces, they assume that you don't know your recipients well. As a result, a high hard bounce rate can negatively impact the deliverability of your email messages.

The following guidelines can help you avoid bounces and improve your sender reputation:
+ Try to keep your hard bounce rate below 5%. The fewer hard bounces in your email program, the more likely ISPs will see your messages as legitimate and valuable. This rate should be considered a reasonable and attainable goal, but isn't a universal rule across all ISPs.
+ Never rent or buy email lists. These lists may contain large numbers of invalid addresses, which could cause your hard bounce rates to increase dramatically. Furthermore, these lists could contain spam traps—email addresses specifically used to catch illegitimate senders. If your messages land in a spam trap, your delivery rates and sender reputation could be irrevocably damaged.
+ Keep your list up to date. If you haven't emailed your recipients in a long time, try to validate your customers' statuses through some other means (such as website login activity or purchase history).
+ If you don't have a method of verifying your customers' statuses, consider sending a *win-back* email. A typical win-back email mentions that you haven't heard from the customer in a while, and encourages the customer to confirm that they still want to receive your email. After sending a win-back email, purge all of the recipients who did not respond from your lists.

When you receive bounces, it's vital that you respond to them appropriately by observing the following rules:
+ If an email address hard bounces, immediately remove that address from your lists. Do not attempt to re-send messages to hard-bouncing addresses. Repeated hard bounces add up, and ultimately harm your reputation with the recipient's ISP.
+ Make sure that the address you use to receive bounce notifications is able to receive email. For more information about setting up bounce and complaint notifications, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md).
+ If your inbound email comes to you from an ISP, instead of through your own internal servers, an influx of bounce notifications can land in your spam folder or be dropped completely. Ideally, you should not use a hosted email address to receive bounces. If you must, however, then check the spam folder often, and don't mark the bounce messages as spam. In Amazon SES, you can specify the address that bounce notifications are sent to.
+ Usually, a bounce provides the address of the mailbox refusing delivery. However, if you need more granular data to map a recipient address to a particular email campaign, include an X-header with a value you can trace back to your internal tracking system. For more information, see [Amazon SES header fields](header-fields.md).

## Complaints
Complaints

A complaint occurs when an email recipient clicks the "Mark as Spam" (or equivalent) button in their web-based email client. If you accumulate a large number of these complaints, the ISP assumes that you are sending spam. This has a negative impact on your deliverability rate and sender reputation. Some, but not all, ISPs will notify you when a complaint is reported; this is known as a *feedback loop*. Amazon SES automatically forwards complaints from ISPs that offer feedback loops to you.

The following guidelines can help you avoid complaints and improve your sender reputation:
+ Try to keep your complaint rate below 0.1%. The fewer complaints in your email program, the more likely ISPs will see your messages as legitimate and valuable. This rate should be considered a reasonable and attainable goal, but isn't a universal rule across all ISPs.
+ If a customer complains about a marketing email, you should immediately stop sending that customer marketing emails. However, if your email program also includes other types of emails (such as notification or transactional emails), it may be acceptable to continue to send those types of messages to the recipient who issued the complaint.
+ As with hard bounces, if you have a list that you haven't sent email to in a while, ensure that your recipients understand why they're receiving your messages. We recommend that you send a welcome message reminding them of who you are and why you're contacting them.

When you receive complaints, it's vital that you respond to them appropriately by observing the following rules:
+ Make sure that the address you use to receive complaint notifications is able to receive email. For more information about setting up bounce and complaint notifications, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md).
+ Make sure that your complaint notifications aren't being marked as spam by your ISP or mail system.
+ Complaint notifications usually contain the body of the email; this is different from bounce notifications, which only include the email headers. However, in complaint notifications, the email address of the individual who issued the complaint is removed. Use custom X-headers or special identifiers embedded in the email body so that you can identify the email address that issued the complaint. This technique makes it easier to identify addresses that complained so that you can remove them from your recipient lists.

## Message quality
Message quality

Email receivers use *content filters* to detect certain attributes in your messages to identify whether your message is legitimate. These content filters automatically review the content of your messages to identify common traits of unwanted to malicious messages. Amazon SES uses content filtering technologies to help detect and block messages that contain malware before they are sent.

If an email receiver's content filters determine that your message contains the characteristics of spam or malicious email, your message will most likely be flagged and diverted from recipients' inboxes.

Remember the following when designing your email:
+ Modern content filters are intelligent, continuously adapting and changing. They don't rely on a predefined set of rules. Third-party services such as [ReturnPath](https://returnpath.com/) or [Litmus](https://litmus.com/) can help identify content in your email that may trigger content filters.
+ If your email contains links, check the URLs for those links against DNS-based Blackhole Lists (DNSBLs), such as those found at [URIBL.com](http://uribl.com/) and [SURBL.org](http://www.surbl.org/).
+ Avoid using link shorteners. Malicious senders may use link shorteners to hide the actual destination of a link. When ISPs notice that link shortening services—even the most reputable ones—are being used for nefarious purposes, they may deny access to those services altogether. If your email contains a link to a link shortening service that has been added to a deny list, it won't reach your customers' inboxes, and the success of your email campaign suffers.
+ Test every link in your email to ensure that it points to the intended page.
+ Make sure your website includes Privacy Policy and Terms of Use documents, and that these documents are up to date. It's a good practice to link to these documents from each email you send. Providing links to these documents demonstrates that you have nothing to hide from your customers, which can help build a relationship of trust.
+ If you plan to send high-frequency content (such as "daily deals" messages), ensure that the content of your email is different with each deployment. When you send messages with high frequency, you must ensure that those messages are timely and relevant, rather than repetitive and annoying.

# Maintaining a positive sender reputation


In Amazon SES, sender reputation refers to the credibility and trustworthiness of the email sender as perceived by email providers and spam filters. It is a measure of how likely your emails are to be considered legitimate and delivered successfully to the recipients' inboxes.

The following sections introduce the core email sending principals you must pay attention to in order to ensure that your email communications reach your intended audience while maintaining a good sender reputation.

## Domain and "From" address considerations

+ Think carefully about the addresses you send email from. The "From" address is one of the first pieces of information your recipients see, and therefore can leave a lasting first impression. Additionally, some ISPs associate your reputation with your "From" address.
+ Consider using subdomains for different types of communications. For example, assume you are sending email from the domain *example.com*, and you plan to send both marketing and transactional messages. Rather than sending all of your messages from *example.com*, send your marketing messages from a subdomain such as *marketing.example.com*, and your transactional messages from a subdomain such as *orders.example.com*. Unique subdomains develop their own reputations. Using subdomains reduces the risk of damage to your reputation if, for example, your marketing communications land in a spam trap or trigger a content filter.
+ If you plan to send a large number of messages, don't send those messages from an ISP-based address such as *sender@hotmail.com*. If an ISP notices a large volume of messages coming from *sender@hotmail.com*, that email is treated differently than an email that comes from an outbound email sending domain that you own.
+ Work with your domain registrar to ensure that the WHOIS information for your domain is accurate. Maintaining an honest and up-to-date WHOIS record demonstrates that you value transparency, and allows users to quickly identify whether or not your domain is legitimate.
+ Avoid using a *no-reply* address, such as *no-reply@example.com*, as your "From" or "Reply-to" address. Using a *no-reply@* email address sends your recipients a clear message: that you aren't offering them a way to contact you, and that you're not interested in their feedback.

## Authentication

+ Authenticate your domain with [SPF](send-email-authentication-spf.md) and SenderID. These authentication methods confirm to email recipients that each email you send is actually from the domain it claims to be from.
+ Sign your outbound mail with [DKIM](send-email-authentication-dkim.md). This step confirms to recipients that the content has not been changed in transit between sender and receiver.
+ You can test your authentication settings for both SPF and DKIM by sending an email to an ISP-based email address that you own, such as a personal Gmail or Hotmail account, and then viewing the message's headers. The headers indicate whether your attempts to authenticate and sign the message were successful.

## Building and maintaining your lists

+ Implement a double opt-in strategy. When users sign up to receive email from you, send them a message with a confirmation link, and do not start sending them email until they confirm their address by clicking that link. A double opt-in strategy helps reduce the number of hard bounces resulting from typographical errors.
+ When collecting email addresses with a web-based form, perform minimal validation on those addresses upon submission. For example, ensure that the addresses you collect are well-formed (that is, they are in the format *recipient@example.com*), and that they refer to domains with valid MX records.
+ Use caution when allowing user-defined input to be passed to Amazon SES unchecked. Forums registrations and form submissions present unique risks because the content is completely user-generated, and spammers can fill out forms with their own content. It's your responsibility to ensure that you only send email with high-quality content.
+ It is highly unlikely that a standard alias (such as *postmaster@*, *abuse@*, or *noc@*) will ever sign up for your email intentionally. Ensure that you are only sending messages to real people who actually want to receive them. This rule is especially true for standard aliases, which are customarily reserved for email watchdogs. These aliases can be maliciously added to your list as a form of sabotage, in order to damage your reputation.

## Compliance

+ Be aware of the email marketing and anti-spam laws and regulations in the countries and regions you send email to. You're responsible for ensuring that the email you send complies with these laws. This guide doesn't cover these laws, so it's important that you research them. For a list of laws, see [Email Spam Legislation by Country](https://en.wikipedia.org/wiki/Email_spam_legislation_by_country) on Wikipedia.
+ Always consult an attorney to obtain legal advice.