Amazon SES Blog

Amazon SES Now Offers Dedicated IP Addresses

by Cristian Smochina | on | in Announcements | | Comments

The SES team is pleased to announce that, starting today, you can lease IP addresses dedicated exclusively to your email sending. Prior to the availability of dedicated IPs, all Amazon SES customers sent their email through IP addresses shared by other Amazon SES customers. Although shared IPs remain the best fit for many of our customers, dedicated IPs offer several benefits that might be a great fit for your use case. This blog post explains the use cases that benefit from dedicated IPs, how to request them, and the considerations you need to take when you use them.

Why should I use dedicated IPs?

You might choose to lease dedicated IPs so that you can fully control the email coming from your IPs. Because you know exactly what mail is being sent from those IP addresses, it can make troubleshooting deliverability issues simpler.

Also, most email certification programs require you to have dedicated IPs because they demonstrate your commitment to managing your email reputation.

You might also choose dedicated IPs if you send multiple types of mail, such as marketing and transactional mail, and you want to isolate the reputation of your mail streams to improve your visibility and control over your email deliverability.

Dedicated IPs also address whitelisting and security requirements, because they are an unchanging set of IP addresses. For example, you might use SES to send yourself operational notifications such as alarms. Knowing that all mail originating from your dedicated IPs is safe, you can whitelist the dedicated IPs with your incoming mail servers to ensure that they always accept mail from those IP addresses.

Am I a good candidate for dedicated IPs?

To be a good candidate for dedicated IPs, we typically recommend a sustained and consistent sending pattern and a minimum daily sending volume of 175,000 emails per day (on average). However, if you need dedicated IPs for whitelisting or security purposes and your sending does not meet the minimum volume requirement, feel free to apply anyway, and we will evaluate your request.

SES provides extensive documentation on email-sending best practices as well as guidelines regarding IP-blocking events, but with dedicated IPs the onus is on you to ensure that you send high-quality email that your recipients expect, want, and engage with. Even though you control the email coming from your dedicated IP addresses, SES will continue to monitor SES’s entire IP space to ensure a high deliverability bar for all SES customers.

To learn more about the requirements and whether dedicated IPs are right for you, see Trade-offs Between Dedicated IPs and Shared IPs in the developer guide.

How can I request dedicated IPs?

To request dedicated IPs, open an SES Sending Limits Increase case in Support Center. You can also reach the limit increase form from the Amazon SES console. First, however, be sure to read Requesting Dedicated IPs in the developer guide for instructions on how to use an SES Sending Limits Increase case to request dedicated IPs.

How will my sending process change?

If your request for dedicated IPs is granted, you have to warm up your dedicated IPs before you continue to send emails in the usual way. Warming up your dedicated IPs before you start sending large amounts of email is needed because many receiving ISPs will not accept email from IPs that suddenly send a large volume of email. You warm up your IPs by gradually increasing the volume of emails you send through a new IP address. Each IP address needs some time to build a positive reputation. ISPs determine an IP address’s reputation in part based on the quality and the volume of email sent through that IP address. If you’re not sending a lot of email, a dedicated IP can actually hurt your deliverability because receiving servers aren’t seeing enough email to know whether to trust the IP address or not. Also, your traffic might be rejected by ISPs if you don’t warm up your IPs before sending. You can find more guidance about the warm-up process in the developer guide.

Do dedicated IPs incur an extra cost?

Yes. See the Amazon SES pricing page for dedicated IP pricing information.

Why would I choose to continue using the shared IP model instead of moving to dedicated IPs?

With SES, shared IPs are commitment-free, enable you to send with arbitrary email volume, and there is no cost beyond the regular SES email sending price. Shared IPs are also pre-warmed, which means that you can start sending a large volume of emails through them right away. With shared IPs, it is easier to maintain a good reputation with irregular sending spikes and there is no minimum usage required.

Can I use both shared IPs and dedicated IPs for my sending?

Yes. You can do this by using two different AWS accounts. Request dedicated IPs for one account, and leave the other account at its default option, which is the shared IP model. For example, you could send your transactional mail, which has a steadier sending cadence, through dedicated IPs. For large bursts of mail, you could use shared IPs instead. More guidance about sending from multiple AWS accounts can be found here.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.

Introducing Sending Metrics

by Victor Galis | on | in Announcements | | Comments

The SES team is pleased to announce sending metrics. You will now be able to segment your sending statistics and publish them to CloudWatch or Kinesis Firehose. We want to help you improve your deliverability, and this new feature makes it easier to pinpoint problems hidden by aggregate account-level statistics.

Why use sending metrics?

With the launch of sending metrics, SES enables you to better segment your send statistics, so that you can see how specific types of emails perform. You will find it easier to diagnose problems quickly before they threaten the reputation of your whole domain.

For example, you may want to see if a specific email campaign is targeting the right people by tracking the bounce and complaint rates separately from your other campaigns and transactional email. Alternatively, you may manage sending for a larger company and may want to get statistics on the email that each team sends to make sure they all uphold the same standards.

For what types of events can I see metrics?

Five types of events are available through this feature:

  • Send – The API call to SES was successful and SES will attempt to deliver the email.
  • Reject – SES rejected the email after the initial send API call was successful. This typically happens when we detect that the email contains a virus.
  • Delivery – The remote server accepted the email from SES. It is still possible that the remote server will send an asynchronous bounce or that the recipient will complain later on.
  • Bounce – The remote server rejected the email. Note that SES automatically retries when getting a “soft” bounce. Only permanent failures to deliver the email will show up in this statistic.
  • Complaint – The recipient marked the incoming email as spam.

For best practices in dealing with bounces and complaints, please see the Amazon SES Best Practices.

How can I see my sending metrics?

SES supports publishing to Kinesis Firehose and CloudWatch.

CloudWatch is best suited for situations where you want aggregate metrics. SES will publish metrics to your account in CloudWatch. Your metrics will be aggregate event counts segmented based on dimensions you specify in your setup in SES. You can see event counts by type and combination of specified dimensions. For example, if you have a dimension called Campaign, you could tag your emails with a message tag called Campaign and see the sending metrics for each individual campaign separately in CloudWatch.

Firehose enables you to see individual events sent by SES published as records to a stream that will save it to S3, feed it into Kinesis Analytics, make it available in an Elasticsearch Service cluster, or push it to Redshift. The event will include information like the type, message tags, time stamp, and message ID associated with the message.

How do I enable sending metrics?

With the release of this feature, SES will begin publishing basic account-level metrics to CloudWatch on your behalf. In order to start getting more detailed metrics, you must first create a configuration set, which will contain event destinations that specify where to publish the events. You can use either the SES console or APIs.

To get started with sending metrics using the console:

  1. Click on the Configuration Sets link from the navigation pane on the left, and then on the Create Configuration Set button. Name your new configuration set.
  2. After creating the configuration set, click on your new configuration to go to a page where you can add event destinations to define where your events should be published. You can select either CloudWatch or Firehose.
  3. Give your new destination a name and select which event types SES will send to this destination. You can send a particular type of event to multiple destinations if you want.
  4. Configure destination-specific info:
  • For CloudWatch, this means adding the dimensions. The values of the message tags or email headers with names that match your dimensions will be associated with that event. (See the Amazon CloudWatch Concepts documentation for more information about how this will work in CloudWatch.) If the tag or header is not present for a given message, SES will use the default value you specify instead.
  • For Firehose, specify the name of the stream and the role SES will assume to publish the events to your Firehose stream. SES will put a record containing a JSON representation of each event to that stream. You can have SES create a role with permissions to publish to Firehose on your behalf, select an existing role, or create the role yourself. SES will verify that it can assume the specified role and use it to publish to the specified stream before allowing you to save your Firehose destination.

When you are finished with the definition, you can start setting the new optional parameter called ConfigurationSetName on the SendEmail and SendRawEmail APIs or passing in the optional X-SES-CONFIGURATION-SET header when using SendRawEmail and the SMTP endpoint. If both the parameter and header are specified, the configuration set from the parameter will take precedence. Emails sent with a configuration set specified will trigger events, which will be published to the event destinations associated with that configuration set.

How do message tags work?

Like headers, message tags are message-specific key-value pairs, but you specify them as a parameter to the SendEmail/SendRawEmail API call. They will be used as value for a CloudWatch dimension or show up in the record for the event published to Firehose.

For example, you could tag your emails with a tag called Type and use values like Transactional, Marketing, Customer_Support, etc. Then, you could add a Type dimension in your CloudWatch event destination and see metrics broken down by each of those email types.

To help you get started, SES will automatically tag all emails with:

  • configuration set name (ses:configuration-set)
  • caller identity (ses:caller-identity)
  • MAIL FROM domain (ses:from-domain)
  • source IP (ses:source-ip)
  • outgoing IP (ses:outgoing-ip)

Additional SES-provided tags may be available in the future. See our documentation for an up to date list of auto-tags.

These auto-tags will be present when appropriate (for example, the source IP will be available when you use the SMTP interface) and you can use them the same way you would use any custom tags you add.

For example, if you manage an AWS account to send email on behalf of multiple users, you could set up a configuration set with a CloudWatch destination that has a ses:caller-identity dimension. You could then add this configuration set as a parameter to all outgoing email sending calls and get a detailed breakdown by the IAM user that was used to send the email for the various event metrics. Alternatively, if you use multiple domains to send emails, you could use the ses:from-domain tag instead to get sending statistics by domain.

How do these events look at the various event destinations?

In CloudWatch, you will find new choices inside the SES namespace based on your event destinations as well as a new Account Metrics option. The Account Metrics option contains basic, account-wide metrics equivalent to the ones currently available in the Sending Statistics section of the SES Console or the GetSendStatistics API. If you choose one of the options based on your configuration sets, you will see a metric per unique combination of tag values, which you can graph or set alarms on.

With Firehose, you can configure your stream to put events to various services.

You can consume the events directly from S3. If you choose this option, you should see files containing one JSON object per line representing an individual event. The file contains an aggregation of events based on a time interval which you can configure in the stream setup. The format looks like:

{"eventType":"Send","mail":{"timestamp":"2016-10-17T18:46:39.808Z","source":"source","sourceArn":"sourceArn","sendingAccountId":"XXXXXXXXXXXX","messageId":"574af616-10fc-4298-abdc-16be2cf77afc","destination":["a@example.com"],"headersTruncated":false,"headers":[{"name":null,"value":null}],"commonHeaders":{"messageId":"574af616-10fc-4298-abdc-16b02cf77afc"},"tags":{"ses:configuration-set":["FirehoseTest"],"ExampleTagName":["ExampleTagValue"]}},"send":{}}
{"eventType":"Bounce","bounce":{"bounceType":"Permanent","bounceSubType":"ContentRejected","bouncedRecipients":[{"emailAddress":"fake.person@fakeDomain.com"}],"timestamp":"2016-10-17T18:46:39.808Z","feedbackId":"63e7a3ba-ad42-4d6a-b736-262562369be4","reportingMTA":"reportingMta.com"},"mail":{"timestamp":"2016-10-17T18:46:39.808Z","source":"source","sourceArn":"sourceArn","sendingAccountId":"XXXXXXXXXXXX","messageId":"71ae6d3f-540b-4310-80ae-5f34d63dcb81","destination":["a@example.com"],"headersTruncated":false,"headers":[{"name":null,"value":null}],"commonHeaders":{"messageId":"71ae6d3f-54cb-4310-80ae-5f34d63dcb81"},"tags":{"ses:configuration-set":["FirehoseTest"],"ExampleTagName":["ExampleTagValue"]}}}

Alternatively, you can have Redshift load the data from your S3 bucket. You can specify a schema that will convert the JSON objects into rows in a relational database that you can query using SQL. For more information on how to set this up, see our Redshift event publishing tutorial.

You can also feed the data into Amazon Elasticsearch Service, which is a managed service that makes it easy to create a domain and deploy, operate, and scale Elasticsearch clusters in the AWS Cloud. Elasticsearch is a popular open-source search and analytics engine. To learn more, see the Amazon Elasticsearch Service documentation.

One example of a tool built on top of Elasticsearch is Kibana, which you can use to visualize data. Here’s a simple example:

 

For more details on how to set up Elasticsearch and Kibana, see our tutorial.

This is not an exhaustive list, and there may be additional options for consuming and analyzing data pushed through Firehose.

How much will this cost me?

Although you can now access basic account-level email sending statistics in CloudWatch for free, normal CloudWatch prices apply for any metrics you collect using configuration sets. You may also incur additional costs by using other AWS services. For example, if you use a Firehose stream to push event data to an S3 bucket, standard S3 charges will apply. SES itself will not charge for this feature beyond current SES pricing.

What if I don’t specify a configuration set on my outgoing emails?

You can still get the usual metrics from the GetSendStatistics API and CloudWatch at the account level, but none of the new, more granular metrics will be available. SES will ignore any tags on an email with no configuration set specified.

We hope that you enjoy this feature! As always, please leave any comments and questions you may have in the SES Forum or here in the comments section of the blog.

Do Your Recipients Know Who You Are?

by Samuel Minter | on | in Best Practices | | Comments

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

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

Before we begin…

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

Clearly aligning your emails with your organization

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

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

Example 1: Promotional mail for partners

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

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

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

Example 2: Election mail

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

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

This is about best practices, not the law

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

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

Remember…

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

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

Amazon SES Now Includes Original Message Headers in Notifications

by Cristian Flocea | on | in Announcements | | Comments

The Amazon SES team is pleased to announce the addition of original email headers to the bounce, complaint, and delivery notifications SES provides through Amazon SNS.

We strive to make your email-sending process easier, and today we’re taking another step in that direction. Increasing your visibility into the feedback you receive from SES has always been a key focus for us. Starting today, the headers you pass to SES in your email-sending requests can be made available in your SNS notifications. Read on for answers to some common questions.

How do I enable this feature?

Use the Amazon SES console or API to configure the notification settings for an identity (email address or domain) and notification type (bounce, complaint, or delivery).

For example, to use the SES console to include the original headers for an identity’s bounce notifications, you’d go to the notification settings for an identity and select Include original headers next to the bounce notification configuration:

original-message-headers-selection

After this feature is enabled, the notifications will contain the headers in both raw name/value format and in JSON format for commonly provided headers.

How can I leverage this feature in my email sending?

When SES successfully enqueues your email, it returns a unique message identifier (message ID). Previously, to associate an SNS notification to an original message send request, you needed to store a mapping between your own message identifier and the SES message ID. You no longer need to do that. You can include your identifier as a custom header, or even in the Message-ID header, and SES will return that to you, removing the need for you to maintain your own mapping.

You can also now leverage custom message headers to easily separate subsets of your email stream. For example, say you suspect that a specific type of email you send through SES may be causing a higher than usual complaint rate. You can mark those emails with a custom header value, and later perform a programmatic analysis on the received SNS notifications to see how the marked emails are behaving compared to your overall sending.

How about decoding header values? Does SES help me there?

SES unfolds and decodes the header values for you. If SES isn’t able to decode a header, it will return the raw provided value.

Are there any limits to the headers in the notifications?

There is no limit on the number of headers SES returns to you, but 10 KB is the maximum header size for each notification. If your header section surpasses 10 KB, SES will return the first 10 KB of headers and set headersTruncated to true.

Does this change have any impact on how SES processes messages?

No. SES still adds or overwrites specific headers like Date and Message-ID. Check out our header appendix for more information.

Is there any potential for this change to impact my notification parser?

If you do not enable this feature by using the SES console or API, your notifications will remain the same. If you enable the feature, standard JSON parsers will continue to parse the notifications correctly. If you do custom parsing, please check your parser implementation to ensure that it still works with SES notifications. As an example, line parsers are not always compatible with the addition of new information, and would therefore need to be updated to accommodate the new header fields.

For examples of bounce, complaint, and delivery SNS notifications, check out our developer guide.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.

Amazon SES Now Supports Custom MAIL FROM Domains

by Cristian Smochina | on | in Announcements | | Comments

The Amazon SES team is pleased to announce that, to increase your email authentication options, you can now use your own MAIL FROM domain when you send emails with SES.

First, a quick refresher on the different “source” addresses associated with an email: an email has a “From” address and a MAIL FROM address. The “From” address is the address that you pass to SES in the header of your email. This is the address that recipients see when they view your email in their inbox (RFC 5322). The MAIL FROM address (a.k.a. “envelope MAIL FROM”), on the other hand, is the address that the sending mail server (SES) transmits to the receiving mail server to indicate the source of the mail (RFC 5321). The MAIL FROM address is used by the receiving mail server to return bounce messages and other error notifications, and is only viewable by recipients if they inspect the email’s headers in the raw message source. By default, SES uses its own MAIL FROM domain (amazonses.com or a subdomain of that) when it sends your emails.

Why use my own MAIL FROM domain?

You might choose to use your own MAIL FROM domain to give you more flexibility in complying with Domain-based Message Authentication, Reporting and Conformance (DMARC). DMARC is an email authentication protocol that relies on two other authentication protocols (Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)) to enable receiving mail servers to validate that an incoming email is authorized by the owner of the sending domain and has not been modified during transit.

An email can comply with DMARC in two ways: by satisfying the DKIM requirements and/or by satisfying the SPF requirements. You can use either method, but some senders prefer to use both DKIM and SPF for maximum deliverability. As established by DMARC, the requirements for each validation are as follows:

  • DKIM. The requirements to pass DKIM validation for DMARC are: 1) the message must have a valid DKIM signature, and 2) the domain in the DKIM signature must align with the domain in the “From” address in the header of the email. You can easily achieve DKIM validation with SES, which provides a tool (EasyDKIM) to DKIM-sign your messages automatically.
  • SPF. The requirements to pass SPF validation for DMARC are: 1) The domain in the MAIL FROM address of the email must authorize the sending mail server to send for it via a DNS record, and 2) the domain in the email’s “From” address must match the MAIL FROM domain. When SES uses its default MAIL FROM domain, the first SPF requirement is satisfied (because the MAIL FROM domain is amazonses.com, and the mail server is SES), but the second requirement is not satisfied. This is where the benefit of using your own MAIL FROM domain comes in – it enables you to meet that second SPF requirement.

Can I use any domain as my MAIL FROM domain?

The MAIL FROM domain you use with SES must be a subdomain of the verified identity you want to use it with. For example, a MAIL FROM domain of bounce.example.com would be a legitimate MAIL FROM domain for verified domain example.com or verified email address user@example.com. An additional requirement is that the MAIL FROM domain you use with SES must not be a domain that you use in a “From” address if the MAIL FROM domain is the destination of email feedback forwarding.

How do I set it up?

You configure an identity to use a specific MAIL FROM domain within the Identity Management part of the SES console, or by using the SES API. You also must publish MX and SPF records to your domain’s DNS server. When SES successfully detects the MX record, emails you send from the identity will use the specified MAIL FROM domain. For a full description of the set-up procedure, see the developer guide.

Will my sending process change?

No. After you configure a verified identity to use a specified MAIL FROM domain and SES successfully detects the required MX record, you simply continue to send emails in the usual way.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.

Welcome, Mandrill Customers!

by Nic Webb | on | in Announcements | | Comments

After the recent announcement of changes with Mandrill, we have received many questions from Mandrill customers who are looking at options for email service providers.

Moving to a new platform can be daunting. If you want to understand what SES is and what it can do for you, check out our product detail page and Getting Started guide. We also have our re:Invent 2014 and 2015 presentations, with real-world examples on how to use the email sending and receiving capabilities of SES. Like many other AWS products, SES offers a free tier.

If you’re ready to dive in and start your migration, we have put together a list of resources to get you up and running with SES.

  • If you send emails through an SMTP interface, check out our SMTP endpoints.
  • If you send emails through a web API, take a look at the SES API. You can interact with the SES API directly through HTTPS, or use one of the many AWS SDKs that take care of the details for you. AWS SDKs are available for Android, iOS, Java, .NET, Node.js, PHP, Python, and Ruby.
  • If you are an API user, note that:

    • Mandrill’s send method corresponds to SES’s SendEmail.
    • Mandrill’s send-raw method corresponds to SES’s SendRawEmail.
    • There is no corresponding send_at parameter for SES – messages are queued for delivery when you make an email-sending call to SES.
    • There is no need to specify async – SES API calls are inherently asynchronous.
  • If you process incoming email, we offer the ability to receive those emails through SES. Through our inbound processing, you can save your emails to S3, receive SNS notifications, and perform custom logic using Lambda.
  • To help you maintain good deliverability, we can automatically DKIM-sign your emails using Easy DKIM. (You are also free to do that manually.)
  • SES offers a mailbox simulator you can use to test your application’s handling of scenarios such as deliveries, bounces, and complaints.

We want your transition to be simple. If you have any questions, we welcome you to our forums, or you can review our support options.

Welcome to SES!

Introducing the AWS Lambda Blueprint for Filtering Emails Received Through Amazon SES

by Mahae Koh | on | in Announcements, How To | | Comments

When we set out to build an email receiving service for AWS, we wanted to make receiving email easy, but we also wanted to empower you to make your own decisions about how your inbound emails should be handled. With the goal of striking a balance between ease of use and flexibility, we integrated SES with AWS Lambda, which allows you to easily define your own filter function with arbitrary logic.

Today, we’ll discuss how you can build a simple customized filter function using the new AWS Lambda blueprint for filtering inbound email.

Defining your email filter

When you log into the AWS Lambda console and select “Create a Lambda Function,” you are presented with a list of blueprints you can use. One of these blueprints is called “inbound-ses-spam-filter”—we’ll use this blueprint in our example as a springboard to jumpstart our custom filter function.

Spam filter Lambda blueprint

The blueprint is simple: it checks whether the email has passed SPF and DKIM validations, and whether the email is deemed spam or virus. If an email fails one or more of these tests, the message is bounced using a SendBounce call to SES; otherwise, the rule engine is instructed to continue processing the message.

Once you’ve selected the blueprint, you can customize it to fit your individual needs. First, you’ll need to fill in your domain as the bounce sender:

var sendBounceParams = {
  BounceSender: 'mailer-daemon@<MYDOMAIN>.com',
  OriginalMessageId: messageId,
  MessageDsn: {
    ReportingMta: 'dns; <MYDOMAIN>.com',
    ArrivalDate: new Date(),
    ExtensionFields: []
  },
  BouncedRecipientInfoList: []
};

The heart of the filtering logic, however, lies in the following if statement:

if (receipt.spfVerdict.status === 'FAIL' ||
        receipt.dkimVerdict.status === 'FAIL' ||
        receipt.spamVerdict.status === 'FAIL' ||
        receipt.virusVerdict.status === 'FAIL')

You can modify this conditional statement to fit your use case. Perhaps there’s a particular sender you want to block, or you noticed a pattern of spam with a particular header. For this example, we’ll bounce all emails with the subject line “Buy stuff!”

var mailMetadata = sesNotification.mail;

if (receipt.spfVerdict.status === 'FAIL' ||
        receipt.dkimVerdict.status === 'FAIL' ||
        receipt.spamVerdict.status === 'FAIL' ||
        receipt.virusVerdict.status === 'FAIL' ||
        mailMetadata.commonHeaders.subject === 'Buy stuff!')

The filter function will be invoked synchronously to ensure that it can return a disposition value back to SES, which will then use this value to decide whether to continue processing the message. This particular filter function returns “stop_rule_set” as the disposition after bouncing the message, effectively instructing SES to stop processing the message once the Lambda function returns.

context.succeed({
  disposition: 'stop_rule_set'
});

Check out our documentation for more information about disposition values.

Because the filter function uses SES’s SendBounce API, you need to make sure that your Lambda function’s execution IAM role is allowed to call SendBounce. You can use the following example policy document, which allows your filter function to call SendBounce for any verified domain:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ses:SendBounce"
      ],
      "Resource": "*"
    }
  ]
}

Configuring your email filter

Now that you’ve defined your filter function, you need to configure it to process your inbound email stream. To do this, you can create an SES receipt rule that synchronously invokes an AWS Lambda function, which can be done either through the SES console or by using the CreateReceiptRule API (see our documentation to find out more about creating receipt rules). For this example, we’ll use the console’s receipt rule wizard to create our filter rule.

Lambda action

Note that the invocation type must be set to RequestResponse (synchronous) so that your filter function can decide whether or not the message should be filtered out.

In order to prevent your existing rules from being evaluated for unwanted emails, you need to make sure that your filter rule is processed before any of your processing rules. You can do this by setting the position of your new rule in Step 3 of the receipt rule wizard.

Rule position

Once you’ve created your filter rule, it will be shown at position 1 of your rule set:

Rule set

Note that the rule was configured without specific recipients, which causes the rule to be evaluated for all your inbound emails regardless of the intended recipient. You can always limit the scope of your filter rule by configuring specific recipients to match.

Testing your email filter

You can now test your filter function by sending an email to the address you’re listening in on. To simulate spam or virus, you can use GTUBE or EICAR, respectively, as the message content.

Receiving email programmatically has traditionally been a complex task, due to the open nature of email and the abuse vectors that come with it. We hope that you’ll find the new AWS Lambda blueprint for filtering inbound email to be a useful starting point to help you deal with unwanted mail and manage your operating costs.

Happy hacking!

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

by Manuel Basurto | on | in Best Practices | | Comments

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

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

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

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

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

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

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

2. Process bounces and complaints.

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

3. Remove non-engagers.

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

4. Make it easy for your recipients to unsubscribe.

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

5. Keep your mailing lists independent.

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

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

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

Receiving Email with Amazon SES

by Peter Winckles | on | in Announcements | | Comments

The Amazon SES team is pleased to announce that you can now use SES to receive email!

For the past four years, SES has strived to make your life easier by maintaining a fleet of SMTP servers ready to send mail when you want it. There’s no need to worry about scaling, ensuring message delivery, or navigating relationships with countless email service providers.

However, you’d still need to manage a fleet of SMTP servers if you wanted to receive mail. As with sending mail, receiving mail comes with its own set of headaches: scaling for traffic spikes, blocking malicious senders, filtering out spam and viruses, and ultimately routing mail to your application, to name a few.

As of today, the SES team would like to invite you to say goodbye to these hassles, and rely on SES to simply receive your mail just as you rely on us to simply send your mail.

Why should I use SES to receive mail?

SES is ideally suited for servicing mail that is programmatically actionable. The following are a handful of common use cases that you can now leverage SES to solve:

  • Automatically create support tickets from customer email.
  • Implement an email auto-responder.
  • Process email list unsubscribe requests.
  • Process email bounces and complaints.
  • Create an email archival solution.
  • Update correspondence in tickets, forums, etc. by email.
  • Receive files from customers via email.

You can also use SES to manage your organization’s entire mail stream, directing mail destined to personal inboxes to Amazon WorkMail and processing customer service mail, etc. programmatically with SES.

How does it work?

Think of SES as an email gateway to the AWS ecosystem. After onboarding your domain onto SES, we will receive mail on your behalf, and allow you to consume it through a variety of different AWS services. For example, you can configure SES to deliver all of your mail to an Amazon S3 bucket, and process it directly using AWS Lambda.

SES empowers you to make decisions about how your mail is processed through the concept of a rule set. Every account that receives mail using SES has a single active rule set that you customize to dictate to SES what you’d like done with your mail across all of your SES-managed domains.

A rule set is simply an ordered list of rules, and a rule is a combination of a matching condition and an ordered list of actions. A condition is something like “All mail to someone@example.com” or “All mail to example.com and all subdomains.” Actions are things like “Encrypt my mail using my AWS KMS key, write it to my S3 bucket, and notify me of the delivery via Amazon SNS” or “Asynchronously execute my Lambda function that updates my mailing list based on unsubscribe emails” or “Send me a SNS notification containing the email.” A more thorough discussion of rule sets, rules, and actions can be found in our developer guide.

Your rule set is sequentially evaluated for every message SES receives, and only the actions that apply to the message are executed. This enables you to write rules that route mail differently based on individual message characteristics. You can have a rule that drops mail that SES flags as spam across all of your domains, another that writes mail to a.example.com to one S3 bucket, another that writes mail to b.example.com to a different bucket and then executes a Lambda function but only when the email contains a specific header value, and so on.

Amazon SES rule set

The system was designed to be both highly customizable and convenient to use. Our goal is to minimize the amount of custom email routing or parsing logic that your application needs to do, and, if you capitalize on our Lambda integration, you may not even need an application at all!

How do I get started?

The best place to start is the SES developer guide. It provides detailed instructions on how to onboard a domain onto SES to receive mail, as well as walks you through the process of setting up rules to govern your mail flows. Then, head over to the SES console to set up your domains to begin receiving mail!

Finally, if you’re heading to AWS re:Invent this year, be sure to check out our presentation showcasing our new features!

Announcing Sending Authorization!

by Brian Huang | on | in Announcements | | Comments

The Amazon SES team is excited to announce the release of sending authorization! This feature allows users to grant permission to use their email addresses or domains to other accounts or IAM users.

Note that for simplicity, we’ll be referring to email addresses and domains collectively as “identities” and the accounts and IAM users receiving permissions as “delegate senders.”

Why should I use sending authorization?

The primary incentive to use sending authorization is to enable cross-account identity usage with fine-grained permission control. Let’s look at two example use cases.

Say you’ve just been hired to create and manage an email marketing campaign for an online retailer. Until now, in order to send the retailer’s marketing emails under their domain name, you would have had to convince them to allow you to verify their domain under your own AWS account—this would let you send emails using any address under their domain, at any time, and for any purpose, which the retailer might not be comfortable with. You’d also have to work out who would get the bounce/complaint/delivery notifications, which might be additionally confusing because the notifications from your marketing emails would be sent to the same place as the notifications from the transactional emails the retailer is handling.

With sending authorization, however, you can use the retailer’s identity and receive delivery, bounce and complaint notifications while letting them retain sole ownership of it. Identity owners will still be able to monitor usage with delivery, bounce, and complaint notifications and can adjust permissions at any time, and use AWS condition keys to finely control the scope of those permissions.

Imagine instead that you own or administrate for a company that has several disparate teams that all wish to use SES to send emails using a common email address. Until now, you would have had to create and maintain IAM users for each of these teams under the same account (in which case they still would have access to each other’s identities) or verify the same identity under multiple different accounts.

With sending authorization, you can verify the common identity under the single account (perhaps yours) and simply grant the other teams permission to use it. If you still prefer the IAM policy route, you can take advantage of the new condition keys released with sending authorization to tighten up the IAM policies.

Sending authorization is designed to be powerful and flexible. In fact, Amazon WorkMail uses sending authorization to provide an enterprise-level email and calendaring service built on SES.

How does sending authorization work?

Identity owners grant permissions by creating authorization policies. Let’s look at an example. The policy below gives account 9999-9999-9999 permission to use the ses-example.com domain owned by 8888-8888-8888 in SendEmail and SendRawEmail requests as long as the “From” address is marketing@ses-example.com (with any address tags).

{
  "Id": "SampleAuthorizationPolicy",	
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AuthorizeMarketer",
      "Effect": "Allow",
      "Resource": "arn:aws:ses:us-east-1:888888888888:identity/ses-example.com",
      "Principal": {"AWS": ["999999999999"]},
      "Action": ["SES:SendEmail", "SES:SendRawEmail"],
      "Condition": {
        "StringLike": {
          "ses:FromAddress": "marketing+.*@ses-example.com"
        }
      }
    }
  ]
}

You could write this policy yourself, or you could use the Policy Generator in the SES console, which is even easier. Your Policy Generator page would look like:

Policy generator

Identity owners can add or create a policy for an identity using the PutIdentityPolicy API or the SES console, and can have up to 20 different policies for each identity. You can read more about how to construct and use policies in our developer guide.

How do I make a call with someone else’s identity that I have permission to use?

You’ll specify to SES that you’re using someone else’s identity by presenting an ARN when you make a request. The ARN below refers to an example domain identity (ses-example.com) owned by account 9999-9999-9999 in the US West (Oregon) AWS region.

	arn:aws:ses:us-west-2:999999999999:identity/ses-example.com

Depending on how you make your call, you may need to provide up to three different ARNs: a “source” identity ARN, a “from” identity ARN, and a “return-path” identity ARN. The SendEmail and SendRawEmail APIs have new optional parameters for this purpose, but users of our SMTP endpoint or our SendRawEmail API have the option to instead provide the ARNs as X-headers (X-SES-Source-ARN, X-SES-From-ARN, and X-SES-Return-Path-ARN). See our SendEmail and SendRawEmail documentation for more information about these identities). These headers will be removed by SES before your email is sent.

What happens to notifications when email is sent by a delegate?

Both the identity owner and the delegate sender can set their own bounce, complaint, and delivery notification preferences. SES respects both sets of preferences independently. As a delegate sender, you can configure your notification settings almost as you would if you were the identity owner. The two key differences are that you use ARNs in place of identities, and cannot configure feedback forwarding (a.k.a. receiving bounces and complaints via email) in the console or the API. But, this doesn’t mean that delegate senders cannot use feedback forwarding. If you are a delegate sender and you do want bounces and complaints to be forwarded to an email address you own, just set the “return-path” address of your emails to an identity that you own. You can read more about it in our developer guide.

Billing, sending limits, and reputation

Cross-account emails count against the delegate’s sending limits, so the delegate is responsible for applying for any sending limit increases they might need. Similarly, delegated emails get charged to the delegate’s account, and any bounces and complaints count against the delegate’s reputation.

Sending authorization and IAM policies

It’s important to distinguish between SES sending authorization policies and IAM policies. Although the policies look similar at first glance, sending authorization policies dictate who is allowed to use an SES identity, and IAM policies (set using AWS Identity Access and Management) control what IAM users are allowed to do. The two are independent. Therefore, it’s entirely possible for an IAM user to be unable to use an identity despite having authorization from the owner because the user’s IAM policies do not give permission to use SES (and vice versa). Keep in mind, however, that by default, IAM users with SES access are allowed to use any identities owned by their parent account unless a sending authorization policy explicitly dictates otherwise.

On a related note, with the release of sending authorization, we’re externalizing several new condition keys that you can use in your sending authorization and/or IAM policies:

  • ses:Recipients
  • ses:FromAddress
  • ses:FromDisplayName
  • ses:FeedbackAddress

These can be used to control when policies apply. For example, you might use the “ses:FromAddress” condition key to write an IAM policy that only permits an IAM user to call SES using a certain “From” address. For more information about how to use our new condition keys, see our developer guide.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.