# What is Amazon SES? [Amazon Simple Email Service (SES)](https://aws.amazon.com/ses) is an email platform that provides an easy, cost-effective way for you to send and receive email using your own email addresses and domains. For example, you can send marketing emails such as special offers, transactional emails such as order confirmations, and other types of correspondence such as newsletters. When you use Amazon SES to receive mail, you can develop software solutions such as email autoresponders, email unsubscribe systems, and applications that generate customer support tickets from incoming emails. For more information about topics related to Amazon SES, see the [AWS Messaging and Targeting Blog](https://aws.amazon.com//blogs/messaging-and-targeting/). ## Benefits Building a large-scale email solution is often a complex and costly challenge for a business. You must deal with infrastructure challenges such as email server management, network configuration, and IP address reputation. Additionally, many third-party email solutions require contract and price negotiations, as well as significant up-front costs. Amazon SES eliminates these challenges and enables you to benefit from the years of experience and sophisticated email infrastructure Amazon.com has built to serve its own large-scale customer base. ## Related services Amazon SES integrates seamlessly with other AWS products. For example, you can: + Add email-sending capabilities to any application. + You can send email from Amazon EC2 by using an [AWS SDK](https://aws.amazon.com/tools/#sdk), by using the [Amazon SES SMTP interface](send-email-smtp.md), or by making calls directly to the [Amazon SES API](https://docs.aws.amazon.com/ses/latest/APIReference/). + Use [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) to create an email-enabled application such as a program that uses Amazon SES to send a newsletter to customers. + Set up [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/) to notify you of your emails that bounced, produced a complaint, or were successfully delivered to the recipient's mail server. When you use Amazon SES to receive emails, your email content can be published to Amazon SNS topics. + Use the AWS Management Console to set up Easy DKIM, which is a way to authenticate your emails. Although you can use Easy DKIM with any DNS provider, it is especially easy to set up when you manage your domain with [Route 53](https://aws.amazon.com/route53/). + Control user access to your email sending by using [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/). + Store emails you receive in [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/). + Take action on your received emails by triggering [AWS Lambda](https://aws.amazon.com/lambda/) functions. + Use [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) to optionally encrypt the mail you receive in your Amazon S3 bucket. + Use [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) to log Amazon SES API calls that you make using the console or the Amazon SES API. + Publish your email sending events to [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) or [Amazon Data Firehose](https://aws.amazon.com/firehose/). If you publish your email sending events to Firehose, you can access them in [Amazon Redshift](https://aws.amazon.com/redshift/), [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/), or [Amazon S3](https://aws.amazon.com/s3/). ## Pricing With Amazon SES, you pay based on the volume of emails sent and received. For more information, see [Amazon SES pricing](https://aws.amazon.com/ses/pricing/). # Regions and Amazon SES Regions SES is available in several AWS Regions around the world. In each region, AWS maintains multiple Availability Zones. These Availability Zones are physically isolated from each other, but are united by private, low-latency, high-throughput, and highly redundant network connections. These Availability Zones enable us to provide very high levels of availability and redundancy, while also minimizing latency. For a list of all of the SES regional endpoints, see [Amazon Simple Email Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ses.html) in the *AWS General Reference*. To learn more about the number of Availability Zones that are available in each region, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). This section contains information that you need to know if you plan to use SES in multiple AWS Regions. It discusses the following subjects: + [SES regions and endpoints](#region-endpoints) + [Sandbox removal and sending limit increases](#region-quota-increases) + [Verification of email addresses and domains](#region-verification) + [Easy DKIM](#region-dkim) + [Account-level suppression list](#region-suppression-list) + [Feedback notifications](#region-feedback-notifications) + [SMTP credentials](#region-smtp) + [Sending authorization](#region-sending-authorization) + [Feedback endpoints used for custom MAIL FROM domains](#region-feedback) + [Email receiving](#region-receive-email) + [Setting up (MX) records](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html) For general information about AWS Regions, see [AWS service endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) in the *AWS General Reference.* ## SES regions and endpoints When you use SES to send email, you connect to a URL that provides an endpoint for the SES API or SMTP interface. The *AWS General Reference* contains a complete list of endpoints that you use to send and receive email through SES. For more information, see [Amazon Simple Email Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ses.html) in the AWS General Reference—specific sections are referenced below: + **[API endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_region)** – When you send email through SES, you can use the URLs listed in this table to make HTTPS requests to the SES API. + **[SMTP endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_smtp_endpoints)** – You can use the URLs listed in this table to send email when using the SMTP interface. + **[Email Receiving endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints)** – If you've configured SES to receive email that's sent to your domain, you can use the inbound SMTP endpoint URLs listed in this table when you [set up the mail exchanger (MX) records in the DNS settings for your domain](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html). **Note** The inbound SMTP URLs aren't IMAP server addresses. In other words, you can't use them to receive email by using an application such as Outlook. For a service that provides an IMAP server for incoming email, see [Amazon WorkMail](https://aws.amazon.com/workmail). ## Sandbox removal and sending limit increases The sandbox status for your account can differ between AWS Regions. In other words, if your account has been removed from the sandbox in the US West (Oregon) region, it might still be in the sandbox in the US East (N. Virginia) region, unless you've also had it removed from the sandbox in that region. Sending limits can also be different depending on the AWS Region. For example, if your account is able to send 10 messages per second in the Europe (Ireland) region, you might be able to send more or fewer messages in other regions. When you [submit a request to have your account removed from the sandbox](request-production-access.md), or when you [submit a request to have your account's sending quotas increased](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas), be sure to choose all of the AWS Regions that your request applies to. You can submit several requests in a single Support Center case. ## Verification of email addresses and domains Before you can send email using SES, you have to verify that you own the email address or domain that you plan to send from. The verification status of email addresses and domains also differs across AWS Regions. For example, if you verify a domain in the US West (Oregon) region, you can't use that domain to send email in the US East (N. Virginia) region until you complete the verification process again for that region. For more information about verifying email addresses and domains, see [Verified identities in Amazon SES](verify-addresses-and-domains.md). ## Easy DKIM You have to perform the Easy DKIM setup process for each AWS Region where you want to use Easy DKIM. That is, in each region, you have to use the SES console or the SES API to generate CNAME records. Next, you have to add all of the CNAME records to the DNS configuration for your domain. For more information about setting up Easy DKIM, see [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). Not all AWS Regions use the default SES DKIM domain, `dkim.amazonses.com`—to see if your region uses a region specific DKIM domain, check the [DKIM domains table](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains) in the *AWS General Reference*. ## Account-level suppression list Your SES account-level suppression list applies to your AWS account only in the current AWS Region. You can manually add or remove, individually or in bulk, addresses from your account-level suppression list by using the SES API v2 or console. For more information about using your account-level suppression list, see [Using the Amazon SES account-level suppression list](sending-email-suppression-list.md). ## Feedback notifications There are two important points to note about setting up feedback notifications in multiple AWS Regions: + Verified identity settings, such as whether you receive feedback by email or through SNS, only apply to the region that you set them in. For example, if you verify *user@example.com* in the US West (Oregon) and US East (N. Virginia) regions and you want to receive bounced emails via SNS notifications, you have to use the SES API or the SES console to set up SNS feedback notifications for *user@example.com* in both regions. + SNS topics that you use for feedback forwarding have to be in the same region where you use SES. For more information about monitoring your sending activity through feedback notifications, see [Setting up event notifications for Amazon SES](monitor-sending-activity-using-notifications.md). ## SMTP credentials The credentials that you use to send email through the SES SMTP interface are unique to each AWS Region. If you use the SES SMTP interface to send email in more than one region, you have to [generate a set of SMTP credentials](smtp-credentials.md) for each region. **Note** If you created your SMTP credentials before January 10, 2019, your SMTP credentials were created using an older version of the AWS Signature. For security purposes, you should delete credentials that you created before this date, and replace them with newer credentials. You can [delete older credentials by using the IAM console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting). ## Feedback endpoints used for custom MAIL FROM domains If you use a custom MAIL FROM domain, SES requires you to publish an MX record so that your domain can receive the bounce and complaint notifications that email providers send you. You can use the same custom MAIL FROM domain for verified identities in different AWS Regions because the bounce and complaint notifications are sent to a region specific feedback endpoint. When you configure a custom MAIL FROM domain, SES automatically specifies the correct feedback endpoint for the region where the custom MAIL FROM is being configured. This endpoint is provided in the MX record's value field for you to publish (add) to your domain's DNS configuration. The custom MAIL FROM setup process is described in [Using a custom MAIL FROM domain](mail-from.md). For reference, the feedback endpoints that SES uses for the different AWS Regions is listed in the [Feedback endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_feedback_endpoints) table in the AWS General Reference. ## Sending authorization Delegate senders can only send emails from the AWS Region where the identity owner's identity is verified. The sending authorization policy that gives permission to the delegate sender must be attached to the identity in that region. For more information about sending authorization, see [Using sending authorization with Amazon SES](sending-authorization.md). ## Email receiving With the exception of Amazon S3 buckets, all of the AWS resources that you use for receiving email with SES have to be in the same AWS Region as the SES endpoint. For example, if you use SES in the US West (Oregon) region, then any SNS topics, KMS keys, and Lambda functions that you use also have to be in the US West (Oregon) region. Similarly, to receive email with SES within a region, you have to create an active receipt rule set in that region. Email receiving concepts and setup process are explained in [Email receiving with Amazon SES](receiving-email.md). The [Email Receiving endpoints](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints) table in the AWS General Reference lists the email receiving endpoints for all of the AWS Regions where SES supports email receiving. # Service quotas in Amazon SES Quotas The following sections list and describe the quotas that apply to Amazon SES resources and operations. Some quotas can be increased, while others can't. To determine whether you can request an increase for a quota, refer to the **Adjustable** column. **Note** SES quotas are for each AWS Region that you use in your AWS account. ## Email sending quotas The following quotas apply to sending email through SES. ### Sending quotas Quotas are based on the number of recipients, rather than on the number of messages. | Resource | Default Quota | Adjustable | | --- | --- | --- | | Number of emails that can be sent per 24-hour period | If your account is in the sandbox, you can send up to 200 emails per 24-hour period. If your account is out of the sandbox, this number varies based on your specific use case. | [Yes](manage-sending-quotas-request-increase.md) | | Number of emails that can be sent per second (sending rate) | If your account is in the sandbox, you can send 1 email per second. If your account is out of the sandbox, this rate varies based on your specific use case. | [Yes](manage-sending-quotas-request-increase.md) | ### Message quotas | Resource | Default Quota | Adjustable | | --- | --- | --- | | **Using the [SES v1 API](https://docs.aws.amazon.com/ses/latest/APIReference/)** - Maximum message size (including attachments) | 10 MB per message (after base64 encoding). | No *(For workloads with message sizes in excess of 10MB, consider migrating to the [SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/).)* | | **Using the [SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/) or [SMTP](send-email-smtp.md)** - Maximum message size (including attachments) | 40 MB per message (after base64 encoding). | No | **Note** Messages larger than 10MB are subject to bandwidth throttling, and depending on your sending rate, you may be throttled to as low as 40MB/s. For example, you could send a 40MB message at the rate of 1 message per second, or two 20MB messages per second. ### Sender and recipient quotas | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of tenants | 10,000 | [ Yes ](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas) | | Maximum number of recipients per message | 50 recipients per message. A recipient is any "To", "CC", or "BCC" address. | No. | | Maximum number of identities that you can verify | 10,000 identities per AWS Region. An *identity* is a domain or email address that you use to send email through SES. | Please contact your AWS Account Manager to discuss your use case. | | Maximum number of dedicated IP pools (inclusive of both managed and standard IP pools) | 50 | No | ### Quotas related to event publishing | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of configuration sets | 10,000 | No | | Maximum length of configuration set name | Configuration set names can contain up to 64 alphanumeric characters. They can also contain hyphens (-) and underscores (\$1). Names can't contain spaces, accented characters, or any other special characters. | No | | Maximum number of event destinations per configuration set | 10 | No | | Maximum number of dimensions per CloudWatch event destination | 10 | No | ### Email template quotas | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of email templates in each AWS Region | 20,000 | No | | Maximum template size | 500 KB | No | | Maximum number of replacement values in each template | Unlimited | N/A | | Maximum number of recipients for each templated email | 50 destinations. A *destination* is any email address on the "To", "CC", or "BCC" lines. The number of destinations you can contact in a single call to the API may be limited by your account's maximum sending rate. | No | ## Email receiving quotas The following table lists the quotas associated with receiving email through SES. | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of rules per receipt rule set | 200 | No | | Maximum number of actions per receipt rule | 10 | No | | Maximum number of recipients per receipt rule | 500 | No | | Maximum number of receipt rule sets per AWS account | 40 | No | | Maximum number of IP address filters per AWS account | 100 | No | | Maximum email size (including headers) that can be stored in an Amazon S3 bucket | 40 MB | No | | Maximum email size (including headers) that can be published using an Amazon SNS notification | 150 KB | No | | Maximum email headers size that can be published using an Amazon SNS notification | 10 KB | No | | Maximum email headers size that can be published using an AWS Lambda function | 50 KB | No | ## Mail Manager quotas The following table lists the quotas associated with Mail Manager. | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of open ingress endpoints | 10 | No | | Maximum number of authorized ingress endpoints | 50 | No | | Maximum number of recipients per message | 100 | No | | Maximum email size (including headers) | 40 MB | No | | Maximum number of traffic policy statements | 20 | No | | Maximum number of traffic policy statement conditions | 10 | No | | Maximum number of traffic policies per region | 100 | No | | Maximum number of SMTP relays | 40 | No | | Maximum number of Address Lists per region | 100 | No | | Maximum number of addresses per Address List | 100,000 | No | | Maximum number of rule sets | 40 | No | | Maximum number of rules per rule set | 40 | No | | Maximum number of conditions per rule | 10 | No | | Maximum number of actions per rule | 10 | No | | Maximum number of relay or send actions per rule set | 10 | No | | Maximum number of *active* archives | 10 | No | | Maximum number of archive search results | 1000 | No | | Maximum number of exported archive search results | 250,000 | No | | Maximum number of running search requests in parallel | 1 | No | | Maximum number of running export requests in parallel | 1 | No | | Maximum number of retention changes for archive per week | 1 | No | ## General quotas The following table lists quotas that apply to both sending and receiving email through SES. ### SES API sending quotas | Resource | Default Quota | Adjustable | | --- | --- | --- | | Rate at which you can call Amazon SES API actions | All actions (except for `SendEmail`, `SendRawEmail`, and `SendTemplatedEmail`) are throttled at one request per second. | No | | MIME parts | 500 | No | ### SES miscellaneous quotas | Resource | Default Quota | Adjustable | | --- | --- | --- | | Maximum number of concurrent import jobs | 20 | No | | Maximum number of concurrent export jobs | 20 | No | # Types of Amazon SES credentials Types of credentials To interact with Amazon Simple Email Service (Amazon SES), you use security credentials to verify who you are and whether you have permission to interact with Amazon SES. There are different types of credentials, and the credentials you use depend on what you want to do. For example, you use AWS access keys when you send an email using the Amazon SES API, and SMTP credentials when you send an email using the Amazon SES SMTP interface. The following table lists the types of credentials you might use with Amazon SES, depending on what you are doing. **** | If you want to access the... | Use these credentials | What the credentials consist of | How to get the credentials | | --- | --- | --- | --- | | Amazon SES API(You might access the Amazon SES API directly, or indirectly through an AWS SDK, the AWS Command Line Interface, or the AWS Tools for Windows PowerShell.) | AWS access keys | Access key ID and secret access key | See [Access Keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) in the *AWS General Reference*. For security best practice, use AWS Identity and Access Management (IAM) user access keys instead of AWS account access keys. Your AWS account credentials grant full access to all your AWS resources, so you should store them in a safe place and instead use IAM user credentials for day-to-day interaction with AWS. For more information, see [Root Account Credentials vs. IAM User Credentials](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html) in the *AWS General Reference*. | | Amazon SES SMTP interface | SMTP credentials | User name and password | See [Obtaining Amazon SES SMTP credentials](smtp-credentials.md). Although your Amazon SES SMTP credentials are different than your AWS access keys and IAM user access keys, Amazon SES SMTP credentials are actually a type of IAM credentials. An IAM user can create Amazon SES SMTP credentials, but the root account owner must ensure that the IAM user's policy gives them permission to access the following IAM actions: "iam:ListUsers", "iam:CreateUser", "iam:CreateAccessKey", and "iam:PutUserPolicy". | | Amazon SES console | IAM user name and passwordOREmail address and password | IAM user name and passwordOREmail address and password | See [IAM User Name and Password](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#iam-user-name-and-password) and [Email Address and Password](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#email-and-password-for-your-AWS-account) of the *AWS General Reference*. For security best practice, use an IAM user name and password instead of an email address and password. The email address and password combination are for your AWS account, so you should store them in a safe place instead of using them for day-to-day interaction with AWS. For more information, see [Root Account Credentials vs. IAM User Credentials](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html) in the *AWS General Reference*. | For more information about different types of AWS security credentials (except for SMTP credentials, which are used only for Amazon SES), see [AWS Security Credentials](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html) in the *AWS General Reference*. # 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" ; 3. To: "Bob" 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. # Using Amazon SES with an AWS SDK Working with AWS SDKs AWS software development kits (SDKs) are available for many popular programming languages. Each SDK provides an API, code examples, and documentation that make it easier for developers to build applications in their preferred language. | SDK documentation | Code examples | | --- | --- | | [AWS SDK for C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK for C\$1\$1 code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) | | [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI code examples](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) | | [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK for Go code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) | | [AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK for Java code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) | | [AWS SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK for JavaScript code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) | | [AWS SDK for Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK for Kotlin code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) | | [AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK for .NET code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) | | [AWS SDK for PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK for PHP code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) | | [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell) | [AWS Tools for PowerShell code examples](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) | | [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK for Python (Boto3) code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) | | [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK for Ruby code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) | | [AWS SDK for Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK for Rust code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) | | [AWS SDK for SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK for SAP ABAP code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) | | [AWS SDK for Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK for Swift code examples](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) | For examples specific to Amazon SES, see [Code examples for Amazon SES using AWS SDKs](service_code_examples.md). **Example availability** Can't find what you need? Request a code example by using the **Provide feedback** link at the bottom of this page.