# Email authentication methods Email authentication methods Amazon Simple Email Service (Amazon SES) uses the Simple Mail Transfer Protocol (SMTP) to send email. Because SMTP does not provide any authentication by itself, spammers can send email messages that claim to originate from someone else, while hiding their true origin. By falsifying email headers and spoofing source IP addresses, spammers can mislead recipients into believing that the email messages that they are receiving are authentic. Most ISPs that forward email traffic take measures to evaluate whether email is legitimate. One such measure that ISPs take is to determine whether an email is authenticated. Authentication requires senders to verify that they are the owner of the account that they are sending from. In some cases, ISPs refuse to forward email that is not authenticated. To ensure optimal deliverability, we recommend that you authenticate your emails. **Topics** + [ # Authenticating Email with DKIM in Amazon SES ](send-email-authentication-dkim.md) + [ # Authenticating Email with SPF in Amazon SES ](send-email-authentication-spf.md) + [ # Using a custom MAIL FROM domain ](mail-from.md) + [ # Complying with DMARC authentication protocol in Amazon SES ](send-email-authentication-dmarc.md) + [ # Using BIMI in Amazon SES ](send-email-authentication-bimi.md) # Authenticating Email with DKIM in Amazon SES Authenticating Email with DKIM *DomainKeys Identified Mail* (*DKIM*) is an email security standard designed to make sure that an email that claims to have come from a specific domain was indeed authorized by the owner of that domain. It uses public-key cryptography to sign an email with a private key. Recipient servers can then use a public key published to a domain's DNS to verify that parts of the email have not been modified during the transit. DKIM signatures are optional. You might decide to sign your email using a DKIM signature to enhance deliverability with DKIM-compliant email providers. Amazon SES provides three options for signing your messages using a DKIM signature: + **Easy DKIM**: SES generates a public-private key pair and automatically adds a DKIM signature to every message that you send from that identity, see [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). + **Deterministic Easy DKIM (DEED)**: Enables you to maintain consistent DKIM signing across multiple AWS Regions by creating replica identities that automatically inherit the DKIM signing attributes as a parent identity that is using Easy DKIM, see [Using Deterministic Easy DKIM (DEED) in Amazon SES](send-email-authentication-dkim-deed.md). + **BYODKIM (Bring Your Own DKIM)**: You provide your own public-private key pair and SES adds a DKIM signature to every message that you send from that identity, see [Provide your own DKIM authentication token (BYODKIM) in Amazon SES](send-email-authentication-dkim-bring-your-own.md). + **Manually add DKIM signature**: You add your own DKIM signature to email that you send using the `SendRawEmail` API, see [Manual DKIM signing in Amazon SES](send-email-authentication-dkim-manual.md). ## DKIM signing key length DKIM signing key length Since many DNS providers now fully support DKIM 2048 bit RSA encryption, Amazon SES also supports DKIM 2048 to allow more secure authentication of emails and therefore uses it as the default key length when you configure Easy DKIM either from the API or the console. 2048 bit keys can be setup and used in Bring Your Own DKIM (BYODKIM) as well, where your signing key length must be at least 1024 bits and no more than 2048 bits. For the sake of security as well as your email’s deliverability, when configured with Easy DKIM, you have the choice to use either 1024 and 2048 bit key lengths along with the flexibility of flipping back to 1024 in the event there are problems caused by any DNS providers who still don’t support 2048. *When you create a new identity, it will be created with DKIM 2048 by default unless you specify 1024.* To preserve the deliverability of in transit emails, there are restrictions on the frequency at which you can change your DKIM key length. Restrictions include: + Not being able to switch to the same key length as is already configured. + Not being able to switch to different key length more than once in a 24 hour period (unless it’s the first downgrade to 1024 in that period). When your email is in transit, DNS is using your public key to authenticate your email; therefore, if you change keys too quickly or frequently, DNS may not be able to DKIM authenticate your email as the former key may already be invalidated, thus, these restrictions safeguard against that. ## DKIM considerations When you use DKIM to authenticate your email, the following rules apply: + You only need to set up DKIM for the domain that you use in your "From" address. You don't need to set up DKIM for domains that you use in "Return-Path" or "Reply-to" addresses. + Amazon SES is available in several AWS Regions. If you use more than one AWS Region to send email, you have to complete the DKIM setup process in each of those Regions to ensure that all of your email is DKIM-signed. + Because DKIM properties are inherited from the parent domain, when you verify a domain with DKIM authentication: + DKIM authentication will also apply to all subdomains of that domain. + DKIM settings for a subdomain can override the settings for the parent domain by disabling the inheritance if you don't want the subdomain to use DKIM authentication, as well as the ability to re-enable later. + DKIM authentication will also apply to all email sent from an email identity that references the DKIM verified domain in its address. + DKIM settings for an email address can override the settings for the subdomain (if applicable) and the parent domain by disabling the inheritance if you want to send mail without DKIM authentication, as well as the ability to re-enable later. ## Understanding inherited DKIM signing properties It's important to first understand that an email address identity inherits its DKIM signing properties from its parent domain if that domain was configured with DKIM, regardless of whether Easy DKIM or BYODKIM was used. Therefore, disabling or enabling DKIM signing on the email address identity, is in effect, overriding the domain's DKIM signing properties based on these key facts: + If you already set up DKIM for the domain that an email address belongs to, you do not need to enable DKIM signing for the email address identity as well. + When you set up DKIM for a domain, Amazon SES automatically authenticates every email from every address on that domain through the inherited DKIM properties from the parent domain. + DKIM settings for a specific email address identity *automatically override the settings of the parent domain or subdomain (if applicable)* that the address belongs to. Since the email address identity's DKIM signing properties are inherited from the parent domain, if you're planning on overriding these properties, you must keep in mind the hierarchical rules of overriding as explained in the table below. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html) It’s generally never recommended to disable your DKIM signing as it risks tarnishing your sender reputation, and it increases the risk of having your sent mail go to junk or spam folders or having your domain spoofed. However, the capability exists to override the domain inherited DKIM signing properties on an email address identity for any particular use case or outlying business decision that you might have to either permanently or temporarily disable DKIM signing, or to re-enable it at a later time. See [Overriding inherited DKIM signing on an email address identity](send-email-authentication-dkim-easy-managing.md#send-email-authentication-dkim-easy-setup-email). # Easy DKIM in Amazon SES Easy DKIM When you set up Easy DKIM for a domain identity, Amazon SES automatically adds a 2048-bit DKIM key to every email that you send from that identity. You can configure Easy DKIM by using the Amazon SES console, or by using the API. **Note** To set up Easy DKIM, you have to modify the DNS settings for your domain. If you use Route 53 as your DNS provider, Amazon SES can automatically create the appropriate records for you. If you use another DNS provider, see your provider's documentation to learn more about changing the DNS settings for your domain. **Warning** If you currently have BYODKIM enabled and are transitioning over to Easy DKIM, be aware that Amazon SES will not use BYODKIM to sign your emails while Easy DKIM is being set up and your DKIM status is in a pending state. Between the moment you make the call to enable Easy DKIM (either through the API or console) and the moment when SES can confirm your DNS configuration, your emails may be sent by SES without a DKIM signature. Therefore, it is advised to use an intermediary step to migrate from one DKIM signing method to the other (e.g., using a subdomain of your domain with BYODKIM enabled and then deleting it once Easy DKIM verification has passed), or perform this activity during your application's downtime, if any. ## Setting up Easy DKIM for a verified domain identity Enabling on a domain The procedure in this section is streamlined to just show the steps necessary to configure Easy DKIM on a domain identity that you've already created. If you haven't yet created a domain identity or you want to see all available options for customizing a domain identity, such as using a default configuration set, custom MAIL FROM domain, and tags, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). Part of creating an Easy DKIM domain identity is configuring its DKIM-based verification where you will have the choice to either accept the Amazon SES default of 2048 bits, or to override the default by selecting 1024 bits. See [DKIM signing key length](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) to learn more about DKIM signing key lengths and how to change them. **To set up Easy DKIM for a domain** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Domain*. **Note** If you need to create or verify a domain, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In the **Advanced DKIM settings** container, choose the **Easy DKIM** button in the **Identity type** field. 1. In the **DKIM signing key length** field, choose either [**RSA\$12048\$1BIT** or **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048). 1. In the **DKIM signatures** field, check the **Enabled** box. 1. Choose **Save changes**. 1. Now that you’ve configured your domain identity with Easy DKIM, you must complete the verification process with your DNS provider - proceed to [Verifying a DKIM domain identity with your DNS provider](creating-identities.md#just-verify-domain-proc) and follow the DNS authentication procedures for Easy DKIM. ## Change the Easy DKIM signing key length for an identity Change the Easy DKIM key length The procedure in this section shows how you can easily change the Easy DKIM bits required for the signing algorithm. While a signing length of 2048 bits is always preferred for the enhanced security it provides, there may be situations that require you to use the 1024 bit length, such as having to use a DNS provider who only supports DKIM 1024. To preserve the deliverability of in transit emails, there are restrictions on the frequency at which you can change or flip your DKIM key length. When your email is in transit, DNS is using your public key to authenticate your email; therefore, if you change keys too quickly or frequently, DNS may not be able to DKIM authenticate your email as the former key may already be invalidated, thus, the following restrictions safeguard against that: + You can't switch to the same key length as is already configured. + You can't switch to a different key length more than once in a 24 hour period (unless it’s the first downgrade to 1024 in that period). In using the following procedures to change your key length, if you violate one of these restrictions, the console will return an error banner stating that *the input you provided is invalid* along with the reason of why it was invalid. **To change the DKIM signing key length bits** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity you want to change the DKIM signing key length for. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In the **Advanced DKIM settings** container, choose either [**RSA\$12048\$1BIT** or **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) in the **DKIM signing key length** field. 1. Choose **Save changes**. # Using Deterministic Easy DKIM (DEED) in Amazon SES Deterministic Easy DKIM (DEED) Deterministic Easy DKIM (DEED) offers a solution for managing DKIM configurations across multiple AWS Regions. By simplifying DNS management and ensuring consistent DKIM signing, DEED helps you streamline your multi-region email sending operations while maintaining robust email authentication practices. ## What is Deterministic Easy DKIM (DEED)? What is DEED? Deterministic Easy DKIM (DEED) is a feature that generates consistent DKIM tokens across all AWS Regions based on a parent domain that is configured with [Easy DKIM](send-email-authentication-dkim-easy.md). This enables you to replicate identities in different AWS Regions that automatically inherit and maintain the same DKIM signing configuration as a parent identity that is currently configured with Easy DKIM. With DEED, you only need to publish DNS records once for the parent identity, and replica identities will use the same DNS records to verify domain ownership and manage DKIM signing. By simplifying DNS management and ensuring consistent DKIM signing, DEED helps you streamline your multi-region email sending operations while maintaining best email authentication practices. Terminology used when talking about DEED: + **Parent identity** – A verified identity configured with Easy DKIM that serves as the source for DKIM configuration for a replica identity. + **Replica identity** – A copy of a parent identity that shares the same DNS setup and DKIM signing configuration. + **Parent region** – The AWS Region where a parent identity is set up. + **Replica region** – An AWS Region where a replica identity is set up. + **DEED identity** – Any identity that is used as either a parent identity or a replica identity. (When a new identity is created, it is initially treated as a regular (non-DEED) identity. However, once a replica is created, the identity is then considered a DEED identity.) Key benefits of using DEED include: + **Simplified DNS management** – Publish DNS records only once for the parent identity. + **Easier multi-region operations** – Simplify the process of expanding email sending operations to new regions. + **Reduced administrative overhead** – Manage DKIM configurations centrally from the parent identity. ## How Deterministic Easy DKIM (DEED) works How DEED works When you create a replica identity, Amazon SES automatically replicates the DKIM signing key from the parent identity to the replica identity. Any subsequent DKIM key rotations or key length changes made to the parent identity are automatically propagated to all replica identities. The process involves the following workflow: 1. Create a parent identity in an AWS Region using Easy DKIM. 1. Set up the required DNS records for the parent identity. 1. Create replica identities in other AWS Regions, specifying the parent identity's domain name and DKIM signing region. 1. Amazon SES automatically replicates the parent's DKIM configuration to the replica identities. Important considerations: + You cannot create a replica of an identity that is already a replica. + The parent identity must have [Easy DKIM](send-email-authentication-dkim-easy.md) enabled—you cannot create replicas of BYODKIM or manually signed identities. + Parent identities cannot be deleted until all replica identities are deleted. ## Setting up a replica identity using DEED Setting up a replica identity This section will provide examples showing you how to create and verify a replica identity using DEED along with the necessary permissions required. **Topics** + [ ### Creating a replica identity ](#creating-replica-identity) + [ ### Verifying replica identity configuration ](#verifying-replica-identity) + [ ### Required Permissions to use DEED ](#required-permissions) ### Creating a replica identity Creating a replica identity To create replica identity: 1. In the AWS Region where you want to create a replica identity, open the SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). (In the SES console, replica identities are referred to as *Global identities*.) 1. In the navigation pane, choose **Identities**. 1. Choose **Create identity**. 1. Select **Domain** under **Identity type** and enter the domain name of an existing identity configured with Easy DKIM that you want to replicate and serve as the parent. 1. Expand **Advanced DKIM settings** and select **Deterministic Easy DKIM**. 1. From the **Parent region** dropdown menu, select a parent region where an Easy DKIM-signed identity with the same name as you entered for your Global (replica) identity resides. (Your replica region defaults to the region you signed into the SES console with.) 1. Ensure **DKIM signatures** is enabled. 1. (Optional) Add one or more **Tags** to your domain identity. 1. Review the configuration and choose **Create identity**. Using the AWS CLI: To create a replica identity based on a parent identity configured with Easy DKIM, you need to specify the parent's domain name, the region where you want to create the replica identity, and the parent's DKIM signing region as shown in this example: ``` aws sesv2 create-email-identity --email-identity example.com --region us-west-2 --dkim-signing-attributes '{"DomainSigningAttributesOrigin": "AWS_SES_US_EAST_1"}' ``` In the preceding example: 1. Replace *example.com* with the parent domain identity being replicated. 1. Replace *us-west-2* with the region where the replica domain identity will be created. 1. Replace *AWS\$1SES\$1US\$1EAST\$11* with the parent's DKIM signing region that represents its Easy DKIM signing configuration that will be replicated to the replica identity. **Note** The `AWS_SES_` prefix indicates that DKIM was configured for the parent identity by using Easy DKIM, and `US_EAST_1` is the AWS Region where it was created. ### Verifying replica identity configuration Verifying replica identity After creating the replica identity, you can verify that it was configured correctly with the parent identity's DKIM signing configuration. **To verify a replica identity:** 1. In the AWS Region where you created the replica identity, open the SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, choose **Identities** and select the identity you want to verify from the **Identities** table. 1. Under the **Authentication** tab, the **DKIM configuration** field will indicate the status, and the **Parent region** field will indicate the region being used for the identity's DKIM signing configuration utilizing DEED. Using the AWS CLI: Use the `get-email-identity` command specifying the replica's domain name and region: ``` aws sesv2 get-email-identity --email-identity example.com --region us-west-2 ``` The response will include the value of the parent region in the `SigningAttributesOrigin` parameter signifying that the replica identity has been successfully configured with the parent identity's DKIM signing configuration: ``` { "DkimAttributes": { "SigningAttributesOrigin": "AWS_SES_US_EAST_1" } } ``` ### Required Permissions to use DEED Required permissions To use DEED, you need: 1. Standard permissions for creating email identities in the replica region. 1. Permission to replicate the DKIM signing key from the parent region. #### Example IAM policy for DKIM replication Example IAM policy The following policy allows DKIM signing key replication from a parent identity to specified replica regions: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDKIMReplication", "Effect": "Allow", "Action": "ses:ReplicateEmailIdentityDKIMSigningKey", "Resource": "arn:aws:ses:us-east-1:123456789124:identity/example.com", "Condition": { "ForAllValues:StringEquals": { "ses:ReplicaRegion": ["us-east-1", "us-east-1"] } } } ] } ``` ------ ## Best practices Best practices The following best practices are recommended: + **Plan your parent and replica regions** – Give consideration to the parent region you choose, as it will be the source of truth for the DKIM configuration used in replica regions. + **Use consistent IAM policies** – Ensure that your IAM policies allow for DKIM replication across all intended regions. + **Keep parent identities active** – Remember that your replica identities inherit the DKIM signing configuration of the parent identity, because of this dependency, you cannot delete a parent identity until all replica identities are deleted. ## Troubleshooting Troubleshooting If you encounter issues with DEED, consider the following: + **Verification errors** – Ensure that you have the necessary permissions for DKIM replication. + **Replication delays** – Allow some time for replication to complete, especially when creating new replica identities. + **DNS issues** – Verify that the DNS records for the parent identity are correctly set up and propagated. # Provide your own DKIM authentication token (BYODKIM) in Amazon SES BYODKIM - Bring Your Own DKIM As an alternative to using [Easy DKIM](send-email-authentication-dkim-easy.md), you can instead configure DKIM authentication by using your own public-private key pair. This process is known as *Bring Your Own DKIM* (*BYODKIM*). With BYODKIM, you can use a single DNS record to configure DKIM authentication for your domains, as opposed to Easy DKIM, which requires you to publish three separate DNS records. Additionally, with BYODKIM you can rotate the DKIM keys for your domains as often as you want. **Topics** + [ ## Step 1: Create the key pair ](#send-email-authentication-dkim-bring-your-own-create-key-pair) + [ ## Step 2: Add the selector and public key to your DNS provider's domain configuration ](#send-email-authentication-dkim-bring-your-own-update-dns) + [ ## Step 3: Configure and verify a domain to use BYODKIM ](#send-email-authentication-dkim-bring-your-own-configure-identity) **Warning** If you currently have Easy DKIM enabled and are transitioning over to BYODKIM, be aware that Amazon SES will not use Easy DKIM to sign your emails while BYODKIM is being set up and your DKIM status is in a pending state. Between the moment you make the call to enable BYODKIM (either through the API or console) and the moment when SES can confirm your DNS configuration, your emails may be sent by SES without a DKIM signature. Therefore, it is advised to use an intermediary step to migrate from one DKIM signing method to the other (e.g., using a subdomain of your domain with Easy DKIM enabled and then deleting it once BYODKIM verification has passed), or perform this activity during your application's downtime, if any. ## Step 1: Create the key pair Create the key pair To use the Bring Your Own DKIM feature, you first have to create an RSA key pair. The private key that you generate has to be in either PKCS \$11 or PKCS \$18 format, must use at least 1024-bit RSA encryption and up to 2048-bit, and be encoded using base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. See [DKIM signing key length](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) to learn more about DKIM signing key lengths and how to change them. **Note** You can use third-party applications and tools to generate RSA key pairs as long as the private key is generated with at least 1024-bit RSA encryption and up to 2048-bit, and is encoded using base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. In the following procedure, the example code which uses the `openssl genrsa` command that's built into most Linux, macOS, or Unix operating systems to create the key pair will automatically use base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) encoding. **To create the key pair from the Linux, macOS, or Unix command line** 1. At the command line, enter the following command to generate the private key replacing *nnnn* with a bit length of at least 1024 and up to 2048: ``` openssl genrsa -f4 -out private.key nnnn ``` 1. At the command line, enter the following command to generate the public key: ``` openssl rsa -in private.key -outform PEM -pubout -out public.key ``` ## Step 2: Add the selector and public key to your DNS provider's domain configuration Add the selector and public key to your DNS provider Now that you've created a key pair, you have to add the public key as a TXT record to the DNS configuration for your domain. **To add the public key to the DNS configuration for your domain** 1. Sign in to the management console for your DNS or hosting provider. 1. Add a new text record to the DNS configuration for your domain. The record should use the following format: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) In the preceding example, make the following changes: + Replace *selector* with a unique name that identifies the key. **Note** A small number of DNS providers don't allow you to include underscores (\$1) in record names. However, the underscore in the DKIM record name is required. If your DNS provider doesn't allow you to enter an underscore in the record name, contact the provider's customer support team for assistance. + Replace *example.com* with your domain. + Replace *yourPublicKey* with the public key that you created earlier and include the `p=` prefix as shown in the *Value* column above. **Note** When you publish (add) your public key to your DNS provider, it must be formatted as follows: You have to delete the first and last lines (`-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----`, respectively) of the generated public key. Additionally, you have to remove the line breaks in the generated public key. The resulting value is a string of characters with no spaces or line breaks. You must include the `p=` prefix as shown in the *Value* column in the table above. Different providers have different procedures for updating DNS records. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply you can't use the domain with Amazon SES. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) ## Step 3: Configure and verify a domain to use BYODKIM Configure and verify a domain to use BYODKIM You can set up BYODKIM for both new domains (that is, domains that you don't currently use to send email through Amazon SES) and existing domains (that is, domains that you've already set up to use with Amazon SES) by using either the console or AWS CLI. Before you use the AWS CLI procedures in this section, you first have to install and configure the AWS CLI. For more information, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/).. ### Option 1: Creating a new domain identity that uses BYODKIM This section contains procedures for creating a new domain identity that uses BYODKIM. A new domain identity is a domain that you haven't previously set up to send email using Amazon SES. If you want to configure an existing domain to use BYODKIM, complete the procedure in [Option 2: Configuring an existing domain identity](#send-email-authentication-dkim-bring-your-own-configure-identity-existing-domain) instead. **To create an identity using BYODKIM from the console** + Follow the procedures in [Creating a domain identity](creating-identities.md#verify-domain-procedure), and when you get to Step 8, follow the BYODKIM specific instructions. **To create an identity using BYODKIM from the AWS CLI** To configure a new domain, use the `CreateEmailIdentity` operation in the Amazon SES API. 1. In a text editor, paste the following code: ``` { "EmailIdentity":"example.com", "DkimSigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" } } ``` In the preceding example, make the following changes: + Replace *example.com* with the domain that you want to create. + Replace *privateKey* with your private key. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. + Replace *selector* with the unique selector that you specified when you created the TXT record in the DNS configuration for your domain. When you finish, save the file as `create-identity.json`. 1. At the command line, enter the following command: ``` aws sesv2 create-email-identity --cli-input-json file://path/to/create-identity.json ``` In the preceding command, replace *path/to/create-identity.json* with the complete path to the file that you created in the previous step. ### Option 2: Configuring an existing domain identity This section contains procedures for updating an existing domain identity to use BYODKIM. An existing domain identity is a domain that you have already set up to send email using Amazon SES. **To update a domain identity using BYODKIM from the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Domain*. **Note** If you need to create or verify a domain, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** pane, choose **Edit**. 1. In the **Advanced DKIM settings** pane, choose the **Provide DKIM authentication token (BYODKIM)** button in the **Identity type** field. 1. For **Private key**, paste the private key you generated earlier. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. 1. For **Selector name**, enter the name of the selector that you specified in your domain’s DNS settings. 1. In the **DKIM signatures** field, check the **Enabled** box. 1. Choose **Save changes**. **To update a domain identity using BYODKIM from the AWS CLI** To configure an existing domain, use the `PutEmailIdentityDkimSigningAttributes` operation in the Amazon SES API. 1. In a text editor, paste the following code: ``` { "SigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" }, "SigningAttributesOrigin":"EXTERNAL" } ``` In the preceding example, make the following changes: + Replace *privateKey* with your private key. **Note** You have to delete the first and last lines (`-----BEGIN PRIVATE KEY-----` and `-----END PRIVATE KEY-----`, respectively) of the generated private key. Additionally, you have to remove the line breaks in the generated private key. The resulting value is a string of characters with no spaces or line breaks. + Replace *selector* with the unique selector that you specified when you created the TXT record in the DNS configuration for your domain. When you finish, save the file as `update-identity.json`. 1. At the command line, enter the following command: ``` aws sesv2 put-email-identity-dkim-signing-attributes --email-identity example.com --cli-input-json file://path/to/update-identity.json ``` In the preceding command, make the following changes: + Replace *path/to/update-identity.json* with the complete path to the file that you created in the previous step. + Replace *example.com* with the domain that you want to update. ### Verifying the DKIM status for a domain that uses BYODKIM **To verify the DKIM status of a domain from the console** After you configure a domain to use BYODKIM, you can use the SES console to verify that DKIM is properly configured. 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity whose DKIM status you want to verify. 1. It can take up to 72 hours for changes to DNS settings to propagate. As soon as Amazon SES detects all of the required DKIM records in your domain’s DNS settings, the verification process is complete. If everything has been configured correctly, your domain’s **DKIM configuration** field displays **Successful** in the **DomainKeys Identified Mail (DKIM)** pane, and the **Identity status** field displays **Verified** in the **Summary** pane. **To verify the DKIM status of a domain using the AWS CLI** After you configure a domain to use BYODKIM, you can use the GetEmailIdentity operation to verify that DKIM is properly configured. + At the command line, enter the following command: ``` aws sesv2 get-email-identity --email-identity example.com ``` In the preceding command, replace *example.com* with your domain. This command returns a JSON object that contains a section that resembles the following example. ``` { ... "DkimAttributes": { "SigningAttributesOrigin": "EXTERNAL", "SigningEnabled": true, "Status": "SUCCESS", "Tokens": [ ] }, ... } ``` If all of the following are true, BYODKIM is properly configured for the domain: + The value of the `SigningAttributesOrigin` property is `EXTERNAL`. + The value of `SigningEnabled` is `true`. + The value of `Status` is `SUCCESS`. # Managing Easy DKIM and BYODKIM Managing Easy DKIM & BYODKIM You can manage the DKIM settings for your identities authenticated with either Easy DKIM or BYODKIM by using the web-based Amazon SES console, or by using the Amazon SES API. You can use either of these methods to obtain the DKIM records for an identity, or to enable or disable DKIM signing for an identity. ## Obtaining DKIM Records for an identity You can obtain the DKIM records for your domain or email address at any time by using the Amazon SES console. **To obtain the DKIM records for an identity by using the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to obtain DKIM records. 1. On the **Authentication** tab of the identity details page, expand **View DNS records**. 1. Copy either the three CNAME records if you used Easy DKIM, or the TXT record if you used BYODKIM, that appear in this section. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. The following image shows an example of the expanded **View DNS records** section revealing CNAME records associated with Easy DKIM. ![\[\]](http://docs.aws.amazon.com/ses/latest/dg/images/dkim_existing_dns.png) You can also obtain the DKIM records for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To obtain the DKIM records for an identity by using the AWS CLI** 1. At the command line, type the following command: ``` aws ses get-identity-dkim-attributes --identities "example.com" ``` In the preceding example, replace *example.com* with the identity that you want to obtain DKIM records for. You can specify either an email address or a domain. 1. The output of this command contains a `DkimTokens` section, as shown in the following example: ``` { "DkimAttributes": { "example.com": { "DkimEnabled": true, "DkimVerificationStatus": "Success", "DkimTokens": [ "hirjd4exampled5477y22yd23ettobi", "v3rnz522czcl46quexamplek3efo5o6x", "y4examplexbhyhnsjcmtvzotfvqjmdqoj" ] } } } ``` You can use the tokens to create the CNAME records that you add to the DNS settings for your domain. To create the CNAME records, use the following template: ``` token1._domainkey.example.com CNAME token1.dkim.amazonses.com token2._domainkey.example.com CNAME token2.dkim.amazonses.com token3._domainkey.example.com CNAME token3.dkim.amazonses.com ``` Replace each instance of *token1* with the first token in the list you received when you ran the `get-identity-dkim-attributes` command, replace all instances of *token2* with the second token in the list, and replace all instances of *token3* with the third token in the list. For example, applying this template to the tokens shown in the preceding example produces the following records: ``` hirjd4exampled5477y22yd23ettobi._domainkey.example.com CNAME hirjd4exampled5477y22yd23ettobi.dkim.amazonses.com v3rnz522czcl46quexamplek3efo5o6x._domainkey.example.com CNAME v3rnz522czcl46quexamplek3efo5o6x.dkim.amazonses.com y4examplexbhyhnsjcmtvzotfvqjmdqoj._domainkey.example.com CNAME y4examplexbhyhnsjcmtvzotfvqjmdqoj.dkim.amazonses.com ``` **Note** 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*. ## Disabling Easy DKIM for an identity You can quickly disable DKIM authentication for an identity by using the Amazon SES console. **To disable DKIM for an identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to disable DKIM. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In **Advanced DKIM settings**, clear the **Enabled** box in the **DKIM signatures** field. You can also disable DKIM for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To disable DKIM for an identity by using the AWS CLI** + At the command line, type the following command: ``` aws ses set-identity-dkim-enabled --identity example.com --no-dkim-enabled ``` In the preceding example, replace *example.com* with the identity that you want to disable DKIM for. You can specify either an email address or a domain. ## Enabling Easy DKIM for an identity If you previously disabled DKIM for an identity, you can enable it again by using the Amazon SES console. **To enable DKIM for an identity** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose the identity for which you want to enable DKIM. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. 1. In **Advanced DKIM settings**, check the **Enabled** box in the **DKIM signatures** field. You can also enable DKIM for an identity by using the Amazon SES API. A common method of interacting with the API is to use the AWS CLI. **To enable DKIM for an identity by using the AWS CLI** + At the command line, type the following command: ``` aws ses set-identity-dkim-enabled --identity example.com --dkim-enabled ``` In the preceding example, replace *example.com* with the identity that you want to enable DKIM for. You can specify either an email address or a domain. ## Overriding inherited DKIM signing on an email address identity Overriding DKIM signing on email address In this section you'll learn how to override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with Amazon SES. You can only do this for email address identities that belong to domains you already own because DNS settings are configured at the domain level. **Important** You can't disable/enable DKIM signing for email address identities... on domains that you don't own. For example, you can't toggle DKIM signing for a *gmail.com* or *hotmail.com* address, on domains that you own, but have not yet been verified in Amazon SES, on domains that you own, but have not enabled DKIM signing on the domain. This section contains the following topics: + [Understanding inherited DKIM signing properties](#dkim-easy-setup-email-key-points-mng) + [Overriding DKIM signing on an email address identity (console)](#override-dkim-email-console-mng) + [Overriding DKIM signing on an email address identity (AWS CLI)](#override-dkim-email-cli-mng) ### Understanding inherited DKIM signing properties It's important to first understand that an email address identity inherits its DKIM signing properties from its parent domain if that domain was configured with DKIM, regardless of whether Easy DKIM or BYODKIM was used. Therefore, disabling or enabling DKIM signing on the email address identity, is in effect, overriding the domain's DKIM signing properties based on these key facts: + If you already set up DKIM for the domain that an email address belongs to, you do not need to enable DKIM signing for the email address identity as well. + When you set up DKIM for a domain, Amazon SES automatically authenticates every email from every address on that domain through the inherited DKIM properties from the parent domain. + DKIM settings for a specific email address identity *automatically override the settings of the parent domain or subdomain (if applicable)* that the address belongs to. Since the email address identity's DKIM signing properties are inherited from the parent domain, if you're planning on overriding these properties, you must keep in mind the hierarchical rules of overriding as explained in the table below. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy-managing.html) It’s generally never recommended to disable your DKIM signing as it risks tarnishing your sender reputation, and it increases the risk of having your sent mail go to junk or spam folders or having your domain spoofed. However, the capability exists to override the domain inherited DKIM signing properties on an email address identity for any particular use case or outlying business decision that you might have to either permanently or temporarily disable DKIM signing, or to re-enable it at a later time. ### Overriding DKIM signing on an email address identity (console) Overriding DKIM signing (console) The following SES console procedure explains how to override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with Amazon SES. **To disable/enable DKIM signing for an email address identity using the console** 1. Sign in to the AWS Management Console and open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the navigation pane, under **Configuration**, choose **Verified identities**. 1. In the list of identities, choose an identity where the **Identity type** is *Email address* and belongs to one of your verified domains. 1. Under the **Authentication** tab, in the **DomainKeys Identified Mail (DKIM)** container, choose **Edit**. **Note** The **Authentication** tab is only present if the selected email address identity belongs to a domain that has already been verified by SES. If you haven't verified your domain yet, see [Creating a domain identity](creating-identities.md#verify-domain-procedure). 1. Under **Advanced DKIM settings**, in the **DKIM signatures** field, clear the **Enabled** checkbox to disable DKIM signing, or select it to re-enable DKIM signing (if it had been overridden previously). 1. Choose **Save changes**. ### Overriding DKIM signing on an email address identity (AWS CLI) Overriding DKIM signing (AWS CLI) The following example uses the AWS CLI with a SES API command and parameters that will override (disable or enable) the inherited DKIM signing properties from the parent domain on a specific email address identity that you've already verified with SES. **To disable/enable DKIM signing for an email address identity using the AWS CLI** + Assuming you own the *example.com* domain, and you want to disable DKIM signing for one of the domain's email addresses, at the command line, type the following command: ``` aws sesv2 put-email-identity-dkim-attributes --email-identity marketing@example.com --no-signing-enabled ``` 1. Replace *marketing@example.com* with the email address identity that you want to disable DKIM signing for. 1. `--no-signing-enabled` will disable DKIM signing. To re-enable DKIM signing, use `--signing-enabled`. # Manual DKIM signing in Amazon SES Manual DKIM signing As an alternative to using Easy DKIM, you can instead manually add DKIM signatures to your messages, and then send those messages using Amazon SES. If you choose to manually sign your messages, you first have to create a DKIM signature. After you create the message and the DKIM signature, you can use the [SendRawEmail](https://docs.aws.amazon.com/ses/latest/APIReference/API_SendRawEmail.html) API to send it. If you decide to manually sign your email, consider the following factors: + Every message that you send by using Amazon SES contains a DKIM header that references a signing domain of *amazonses.com* (that is, it contains the following string: `d=amazonses.com`). Therefore, if you manually sign your messages, your messages will include *two* DKIM headers: one for your domain, and the one that Amazon SES automatically creates for *amazonses.com*. + Amazon SES doesn't validate DKIM signatures that you manually add to your messages. If there are errors with the DKIM signature in a message, it might be rejected by email providers. + When you sign your messages, you should use a bit length of at least 1024 bits. + Don't sign the following fields: Message-ID, Date, Return-Path, Bounces-To. **Note** If you use an email client to send email using the Amazon SES SMTP interface, your client might automatically perform DKIM signing of your messages. Some clients might sign some of these fields. For information about which fields are signed by default, see the documentation for your email client. # Authenticating Email with SPF in Amazon SES Authenticating Email with SPF *Sender Policy Framework* (SPF) is an email validation standard that's designed to prevent email spoofing. Domain owners use SPF to tell email providers which servers are allowed to send email from their domains. SPF is defined in [RFC 7208](https://tools.ietf.org/html/rfc7208). Messages that you send through Amazon SES automatically use a subdomain of `amazonses.com` as the default MAIL FROM domain. SPF authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES. Therefore, in SES, SPF is implicitly set up for you. However, if you don't want to use the SES default MAIL FROM domain, and would rather use a subdomain of a domain that you own, this is referred to in SES as using a *custom* MAIL FROM domain. To do this, it requires you to publish your own SPF record for your custom MAIL FROM domain. In addition, SES also requires you to set up an MX record so that your custom MAIL FROM domain can receive the bounce and complaint notifications that email providers send you. **Learn how to set up SPF authentication** Instructions are given for configuring your domain with SPF and how to publish the MX and SPF (type TXT) records in [Using a custom MAIL FROM domain](mail-from.md). # Using a custom MAIL FROM domain When an email is sent, it has two addresses that indicate its source: a From address that's displayed to the message recipient, and a MAIL FROM address that indicates where the message originated. The MAIL FROM address is sometimes called the *envelope sender*, *envelope from*, *bounce address*, or *Return Path* address. Mail servers use the MAIL FROM address to return bounce messages and other error notifications. The MAIL FROM address is usually only viewable by recipients if they view the source code for the message. Amazon SES sets the MAIL FROM domain for the messages that you send to a default value unless you specify your own (custom) domain. This section discusses the benefits of setting up a custom MAIL FROM domain, and includes setup procedures. ## Why use a custom MAIL FROM domain? Messages that you send through Amazon SES automatically use a subdomain of `amazonses.com` as the default MAIL FROM domain. Sender Policy Framework (SPF) authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email—in this case, SES. If you don't want to use the SES default MAIL FROM domain, and would rather use a subdomain of a domain that you own, this is referred to in SES as using a *custom* MAIL FROM domain. To do this, it requires you to publish your own SPF record for your custom MAIL FROM domain. In addition, SES also requires you to set up an MX record so that your domain can receive the bounce and complaint notifications that email providers send you. By using a custom MAIL FROM domain, you have the flexibility to use SPF, DKIM, or both to achieve [Domain-based Message Authentication, Reporting and Conformance (DMARC)](send-email-authentication-dmarc.md) validation. DMARC enables a sender's domain to indicate that emails sent from the domain are protected by one or more authentication systems. There are two ways to achieve DMARC validation: [Complying with DMARC through SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf) and [Complying with DMARC through DKIM](send-email-authentication-dmarc.md#send-email-authentication-dmarc-dkim). ## Choosing a custom MAIL FROM domain In the following, the term *MAIL FROM domain* always refers to a subdomain of a domain that you own - this subdomain that you use for your custom MAIL FROM domain must not be used for anything else and meet the following requirements: + The MAIL FROM domain has to be a subdomain of the parent domain of a verified identity (email address or domain). + The MAIL FROM domain shouldn't be a subdomain that you also use to send email from. + The MAIL FROM domain shouldn't be a subdomain that you use to receive email. ## Using SPF with your custom MAIL FROM domain Using SPF with your custom MAIL FROM domain *Sender Policy Framework* (SPF) is an email validation standard that's designed to prevent email spoofing. You can configure your custom MAIL FROM domain with SPF to tell email providers which servers are allowed to send email from your custom MAIL FROM domain. SPF is defined in [RFC 7208](https://tools.ietf.org/html/rfc7208). To set up SPF, you publish a TXT record to the DNS configuration for your custom MAIL FROM domain. This record contains a list of the servers that you authorize to send email from using your custom MAIL FROM domain. When an email provider receives a message from your custom MAIL FROM domain, it checks the DNS records for that domain to make sure that the email was sent from an authorized server. If you want to use this SPF record as a way to comply with DMARC, the domain in the From address must match the MAIL FROM domain. See [Complying with DMARC through SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf). The next section, [Configuring your custom MAIL FROM domain](#mail-from-set), explains how to set up SPF for your custom MAIL FROM domain. ## Configuring your custom MAIL FROM domain The process of setting up a custom MAIL FROM domain requires you to add records to the DNS configuration for the 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 also have to publish an SPF (type TXT) record in order to prove that Amazon SES is authorized to send email from your domain. You can set up a custom MAIL FROM domain for an entire domain or subdomain, as well as for individual email addresses. The following procedures show how to use the Amazon SES console to configure a custom MAIL FROM domain. You can also configure a custom MAIL FROM domain using the [SetIdentityMailFromDomain](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityMailFromDomain.html) API operation. ### Setting up a custom MAIL FROM domain for a verified domain These procedures show you how to configure a custom MAIL FROM domain for an entire domain or subdomain so that all messages sent from addresses on that domain will use the this custom MAIL FROM domain. **To configure a verified domain to use a specified custom MAIL FROM domain** 1. Open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the left navigation panel, under **Configuration**, choose **Identities**. 1. In the list of identities, choose the identity you want to configure where the **Identity type** is **Domain** and **Status** is *Verified*. 1. If the **Status** is *Unverified*, complete the procedures at [Verifying a DKIM domain identity with your DNS provider](creating-identities.md#just-verify-domain-proc) to verify the email address's domain. 1. At the bottom of the screen in the **Custom MAIL FROM domain** pane, choose **Edit** . 1. In the **General details** pane, do the following: 1. Select the **Use a custom MAIL FROM domain** checkbox. 1. For **MAIL FROM domain**, enter the subdomain that you want to use as the MAIL FROM domain. 1. For **Behavior on MX failure**, choose one of the following options: + **Use default MAIL FROM domain** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES uses a subdomain of `amazonses.com`. The subdomain varies based on the AWS Region that you use Amazon SES in. + **Reject message** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES returns a `MailFromDomainNotVerified` error. Emails that you attempt to send from this domain are automatically rejected. 1. Choose **Save changes** - you'll be returned to the previous screen. 1. Publish the MX and SPF (type TXT) records to the DNS server of the custom MAIL FROM domain: In the **Custom MAIL FROM domain** pane, the **Publish DNS records** table now displays the MX and SPF (type TXT) records in that you have to publish (add) to your domain's DNS configuration. These records use the formats shown in the following table. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) In the preceding records, + *subdomain*.*domain*.*com* will be populated with your MAIL FROM subdomain + *region* will be populated with the name of the AWS Region where you want to verify the MAIL FROM domain (such as `us-west-2`, `us-east-1`, or `eu-west-1`, etc.) + The number *10* listed along with the MX value is the preference order for the mail server and will need to be entered into a separate value field as specified by your DNS provider's GUI + The SPF's TXT record value usually has to include the quotation marks, but some DNS providers don't require them. From the **Publish DNS records** table, copy the MX and SPF (type TXT) records by choosing the copy icon next to each value and paste them into the corresponding fields in your DNS provider's GUI. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. **Important** The specific procedures for publishing the MX and SPF (type TXT) records depend on your DNS or hosting provider. See your provider's documentation or contact them for information about adding these records to the DNS configuration for your domain. To successfully set up a custom MAIL FROM domain with Amazon SES, you must publish exactly one MX record to the DNS server of your MAIL FROM domain. If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail. If Route 53 provides the DNS service for your MAIL FROM domain, and you're signed in to the AWS Management Console under the same account that you use for Route 53, then choose ** Publish Records Using Route 53**. The DNS records are automatically applied to your domain's DNS configuration. If you use a different DNS provider, you have to publish the DNS records to the MAIL FROM domain's DNS server manually. The procedure for adding DNS records to your domain's DNS server varies based on your web hosting service or DNS provider. The procedures for publishing DNS records for your domain depend on which DNS provider you use. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply they don't support MAIL FROM domain configuration. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) When Amazon SES detects that the records are in place, you receive an email informing you that your custom MAIL FROM domain was set up successfully. Depending on your DNS provider, there might be a delay of up to 72 hours before Amazon SES detects the MX record. ### Setting up a custom MAIL FROM domain for a verified email address You can also set up a custom MAIL FROM domain for a specific email address. In order to set up a custom MAIL FROM domain for an email address, you must modify the DNS records for the domain that the email address is associated with. **Note** You can't set up a custom MAIL FROM domain for addresses on a domain that you don't own (for example, you can't create a custom MAIL FROM domain for an address on the `gmail.com` domain, because you can't add the necessary DNS records to the domain). **To configure a verified email address to use a specified MAIL FROM domain** 1. Open the Amazon SES console at [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/). 1. In the left navigation panel, under **Configuration**, choose **Identities**. 1. In the list of identities, choose the identity you want to configure where the **Identity type** is **Email address** and **Status** is *Verified*. 1. If the **Status** is *Unverified*, complete the procedures at [Verifying an email address identity](creating-identities.md#just-verify-email-proc) to verify the email address's domain. 1. Under the **MAIL FROM Domain** tab, choose **Edit** in the **Custom MAIL FROM domain** pane. 1. In the **General details** pane, do the following: 1. Select the **Use a custom MAIL FROM domain** checkbox. 1. For **MAIL FROM domain**, enter the subdomain that you want to use as the MAIL FROM domain. 1. For **Behavior on MX failure**, choose one of the following options: + **Use default MAIL FROM domain** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES uses a subdomain of `amazonses.com`. The subdomain varies based on the AWS Region that you use Amazon SES in. + **Reject message** – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES returns a `MailFromDomainNotVerified` error. Emails that you attempt to send from this email address are automatically rejected. 1. Choose **Save changes** - you'll be returned to the previous screen. 1. Publish the MX and SPF (type TXT) records to the DNS server of the custom MAIL FROM domain: In the **Custom MAIL FROM domain** pane, the **Publish DNS records** table now displays the MX and SPF (type TXT) records in that you have to publish (add) to your domain's DNS configuration. These records use the formats shown in the following table. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) In the preceding records, + *subdomain*.*domain*.*com* will be populated with your MAIL FROM subdomain + *region* will be populated with the name of the AWS Region where you want to verify the MAIL FROM domain (such as `us-west-2`, `us-east-1`, or `eu-west-1`, etc.) + The number *10* listed along with the MX value is the preference order for the mail server and will need to be entered into a separate value field as specified by your DNS provider's GUI + The SPF's TXT record value has to include the quotation marks From the **Publish DNS records** table, copy the MX and SPF (type TXT) records by choosing the copy icon next to each value and paste them into the corresponding fields in your DNS provider's GUI. Alternatively, you can choose **Download .csv record set** to save a copy of the records to your computer. **Important** To successfully set up a custom MAIL FROM domain with Amazon SES, you must publish exactly one MX record to the DNS server of your MAIL FROM domain. If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail. If Route 53 provides the DNS service for your MAIL FROM domain, and you're signed in to the AWS Management Console under the same account that you use for Route 53, then choose ** Publish Records Using Route 53**. The DNS records are automatically applied to your domain's DNS configuration. If you use a different DNS provider, you have to publish the DNS records to the MAIL FROM domain's DNS server manually. The procedure for adding DNS records to your domain's DNS server varies based on your web hosting service or DNS provider. The procedures for publishing DNS records for your domain depend on which DNS provider you use. The following table includes links to the documentation for a few widely used DNS providers. This list isn't exhaustive and doesn't signify endorsement; likewise, if your DNS provider isn't listed, it doesn't imply they don't support MAIL FROM domain configuration. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/mail-from.html) When Amazon SES detects that the records are in place, you receive an email informing you that your custom MAIL FROM domain was set up successfully. Depending on your DNS provider, there might be a delay of up to 72 hours before Amazon SES detects the MX record. ## Custom MAIL FROM domain setup states with Amazon SES Custom MAIL FROM domain setup states After you configure an identity to use a custom MAIL FROM domain, the state of the setup is "pending" while Amazon SES attempts to detect the required MX record in your DNS settings. The state then changes depending on whether Amazon SES detects the MX record. The following table describes the email-sending behavior, and the Amazon SES actions associated with each state. Each time the state changes, Amazon SES sends a notification to the email address associated with your AWS account. **** | State | Email sending behavior | Amazon SES actions | | --- | --- | --- | | Pending | Uses custom MAIL FROM fallback setting | Amazon SES attempts to detect the required MX record for 72 hours. If unsuccessful, the state changes to "Failed". | | Success | Uses custom MAIL FROM domain | Amazon SES continuously checks that the required MX record is in place. | | TemporaryFailure | Uses custom MAIL FROM fallback setting | Amazon SES attempts to detect the required MX record for 72 hours. If unsuccessful, the state changes to "Failed"; if successful, the state changes to "Success". | | Failed | Uses custom MAIL FROM fallback setting | Amazon SES no longer attempts to detect the required MX record. To use a custom MAIL FROM domain, you have to restart the setup process in [Configuring your custom MAIL FROM domain](#mail-from-set). | # Complying with DMARC authentication protocol in Amazon SES Authenticating Email with DMARC Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol that uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to detect email spoofing and phishing. In order to comply with DMARC, messages must be authenticated through either SPF or DKIM, but ideally, when both are used with DMARC, you'll be ensuring the highest level of protection possible for your email sending. Let's briefly review which each does and how DMARC ties them all together: + **SPF** – Identifies which mail servers are allowed to send mail on behalf of your custom MAIL FROM domain through a DNS TXT record that is used by DNS. Recipient mail systems refer to the SPF TXT record to determine whether a message from your custom domain comes from an authorized messaging server. Basically, SPF is designed to help prevent spoofing, but there are spoofing techniques that SPF is susceptible to in practice and this is why you need to also use DKIM along with DMARC. + **DKIM** – Adds a digital signature to your outbound messages in the email header. Receiving email systems can use this digital signature to help verify whether incoming email is signed by a key owned by the domain. However, when a receiving email system forwards a message, the message's envelope is changed in a way that invalidates SPF authentication. Since the digital signature stays with the email message because it's part of the email header, DKIM works even when a message has been forwarded between mail servers (as long as the message content has not been modified). + **DMARC** – Ensures that there is domain alignment with at least one of SPF and DKIM. Using SPF and DKIM alone does nothing to insure that the From address is authenticated (this is the email address your recipient sees in their email client). SPF only checks the domain specified in the MAIL FROM address (not seen by your recipient). DKIM only checks the domain specified in the DKIM signature (also, not seen by your recipient). DMARC addresses these two issues by requiring domain alignment to be correct on either SPF or DKIM: + For SPF to pass DMARC alignment the domain in the From address must match the domain in the MAIL FROM address (also referred to as Return-Path and Envelope-from address). This is rarely possible with forwarded mail because it gets stripped away or when sending mail through third-party bulk email providers because the Return-Path (MAIL FROM) is used for bounces and complaints that the provider (SES) tracks using an address they own. + For DKIM to pass DMARC alignment, the domain specified in the DKIM signature must match the domain in the From address. If you use third-party senders or services that send mail on your behalf, this can be accomplished by ensuring the third-party sender is properly configured for DKIM signing and you have added the appropriate DNS records within your domain. Receiving mail servers will then be able to verify email sent to them by your third-party as if it was email sent by someone authorized to use an address within the domain. **Putting it all together with DMARC** The DMARC alignment checks we discussed above show how SPF, DKIM, and DMARC all work together to increase trust of your domain and delivery of your email to inboxes. DMARC accomplishes this by ensuring that the From address, seen by the recipient, is authenticated by either SPF or DKIM: + A message passes DMARC if one or both of the described SPF or DKIM checks pass. + A message fails DMARC if both of the described SPF or DKIM checks fail. Therefore, both SPF and DKIM are necessary for DMARC to have the best chance at achieving authentication for your sent email, and by utilizing all three, you'll help to ensure you have a fully protected sending domain. DMARC also allows you to instruct email servers how to handle emails when they fail DMARC authentication through policies that you set. This will be explained in the following section, [Setting up the DMARC policy on your domain](#send-email-authentication-dmarc-dns), that contains information on how to configure your SES domains so that the emails you send comply with the DMARC authentication protocol through both SPF and DKIM. ## Setting up the DMARC policy on your domain To set up DMARC, you have to modify the DNS settings for your domain. The DNS settings for your domain should include a TXT record that specifies the domain's DMARC settings. The procedures for adding TXT records to your DNS configuration depend on which DNS or hosting provider you use. If you use Route 53, see [Working with Records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) in the *Amazon Route 53 Developer Guide*. If you use another provider, see the DNS configuration documentation for your provider. The name of the TXT record you create should be `_dmarc.example.com`, where `example.com` is your domain. The value of the TXT record contains the DMARC policy that applies to your domain. The following is an example of a TXT record that contains a DMARC policy: | Name | Type | Value | | --- | --- | --- | | \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" | In the preceding DMARC policy example, this policy tells email providers to do the following: + For any messages that fail authentication, send them to the Spam folder as specified by the policy parameter, `p=quarantine`. Other options include doing nothing by using `p=none`, or reject the message outright by using `p=reject`. + The next section discusses how and when to use these three policy settings—*using the wrong one at the wrong time can cause your email to not be delivered,* see [Best practices for implementing DMARC](#send-email-authentication-dmarc-implement). + Send reports about all emails that failed authentication in a digest (that is, a report that aggregates the data for a certain time period, rather than sending individual reports for each event) as specified by the reporting parameter, `rua=mailto:my_dmarc_report@example.com` (*rua* stands for Reporting URI for Aggregate reports). Email providers typically send these aggregated reports once per day, although these policies differ from provider to provider. To learn more about configuring DMARC for your domain, see the [Overview](https://dmarc.org/overview/) on the DMARC website. For complete specifications of the DMARC system, see [Internet Engineering Task Force (IETF) DMARC Draft](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/). ## Best practices for implementing DMARC Implementing DMARC It's best to implement your DMARC policy enforcement in a gradual and phased approach so that it doesn't interrupt the rest of your mail flow. Create and implement a roll-out plan that follows these steps. Do each of these steps first with each of your sub-domains, and finally with the top-level domain in your organization before moving on to the next step. 1. Monitor the impact of implementing DMARC (p=none). + Start with a simple monitoring-mode record for a sub-domain or domain that requests that mail receiving organizations send you statistics about messages that they see using that domain. A monitoring-mode record is a DMARC TXT record that has its policy set to none `p=none`. + Reports generated through DMARC will give the numbers and sources of messages that pass these checks, versus those that don't. You can easily see how much of your legitimate traffic is or isn't covered by them. You'll see signs of forwarding, since forwarded messages will fail SPF and DKIM if the content is modified. You'll also begin to see how many fraudulent messages are being sent, and where they're sent from. + The goals of this step are to learn what emails will be impacted when you implement one of the next two steps, and to have any third-party or authorized senders get their SPF or DKIM policies into alignment. + Best for existing domains. 1. Request that external mail systems quarantine mail that fails DMARC (p=quarantine). + When you believe that all or most of your legitimate traffic is sending domain-aligned with either SPF or DKIM, and you understand the impact of implementing DMARC, you can implement a quarantine policy. A quarantine policy is a DMARC TXT record that has its policy set to quarantine `p=quarantine`. By doing this, you're asking DMARC receivers to put messages from your domain that fail DMARC into the local equivalent of a spam folder instead of your customers' inboxes. + Best for transitioning domains that have analyzed DMARC reports during Step 1. 1. Request that external mail systems not accept messages that fail DMARC (p=reject). + Implementing a reject policy is usually the final step. A reject policy is a DMARC TXT record that has its policy set to reject `p=reject`. When you do this, you're asking DMARC receivers not to accept messages that fail the DMARC checks—this means they won't even be quarantined to a spam or junk folder, but will be rejected outright. + When using a reject policy, you'll know exactly which messages are failing the DMARC policy as the rejection will result in a SMTP bounce. With quarantine, the aggregate data provides information about the percentages of email passing or failing SPF, DKIM, and DMARC checks. + Best for new domains or existing domains that have gone through the prior two steps. ## Complying with DMARC through SPF For an email to comply with DMARC based on SPF, both of the following conditions must be met: + The message must pass an SPF check based on having a valid SPF (type TXT) record that you've to published to your custom MAIL FROM domain's DNS configuration. + The domain in the From address of the email header must align (match) with the domain, or a subdomain of, that's specified in the MAIL FROM address. In order to achieve SPF alignment with SES, the domain's DMARC policy must not specify a strict SPF policy (aspf=s). To comply with these requirements, complete the following steps: + Set up a custom MAIL FROM domain by completing the procedures in [Using a custom MAIL FROM domain](mail-from.md). + Ensure that your sending domain uses a relaxed policy for SPF. If you haven't changed your domain's policy alignment, it uses a relaxed policy by default as does SES. **Note** You can determine your domain's DMARC alignment for SPF by typing the following command at the command line, replacing `example.com` with your domain: ``` dig TXT _dmarc.example.com ``` In the output of this command, under **Non-authoritative answer**, look for a record that begins with `v=DMARC1`. If this record includes the string `aspf=r`, or if the `aspf` string is not present at all, then your domain uses relaxed alignment for SPF. If the record includes the string `aspf=s`, then your domain uses strict alignment for SPF. Your system administrator will need to remove this tag from the DMARC TXT record in your domain's DNS configuration. Alternatively, you can use a web-based DMARC lookup tool, such as the [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) from the dmarcian website or the [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx) tool from the MxToolBox website, to determine your domain's policy alignment for SPF. ## Complying with DMARC through DKIM For an email to comply with DMARC based on DKIM, both of the following conditions must be met: + The message must have a valid DKIM signature and passes the DKIM check. + The domain specified in the DKIM signature must align (match) with the domain in the From address. If the domain's DMARC policy specifies strict alignment for DKIM, these domains must match exactly (SES uses a strict DKIM policy by default). To comply with these requirements, complete the following steps: + Set up Easy DKIM by completing the procedures in [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). When you use Easy DKIM, Amazon SES automatically signs your emails. **Note** Rather than use Easy DKIM, you can also [manually sign your messages](send-email-authentication-dkim-manual.md). However, use caution if you choose to do so, because Amazon SES does not validate the DKIM signature that you construct. For this reason, we highly recommend using Easy DKIM. + Ensure the domain specified in the DKIM signature is aligned to the domain in the From address. Or, if sending from a subdomain of the domain in the From address, ensure that your DMARC policy is set to relaxed alignment. **Note** You can determine your domain's DMARC alignment for DKIM by typing the following command at the command line, replacing `example.com` with your domain: ``` dig TXT _dmarc.example.com ``` In the output of this command, under **Non-authoritative answer**, look for a record that begins with `v=DMARC1`. If this record includes the string `adkim=r`, or if the `adkim` string is not present at all, then your domain uses relaxed alignment for DKIM. If the record includes the string `adkim=s`, then your domain uses strict alignment for DKIM. Your system administrator will need to remove this tag from the DMARC TXT record in your domain's DNS configuration. Alternatively, you can use a web-based DMARC lookup tool, such as the [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) from the dmarcian website or the [DMARC Check Tool](https://mxtoolbox.com/dmarc.aspx) tool from the MxToolBox website, to determine your domain's policy alignment for DKIM. # Using BIMI in Amazon SES Using BIMI in SES Brand Indicators for Message Identification (BIMI) is an email specification that enables email inboxes to display a brand’s logo next to the brand’s authenticated email messages within supporting email clients. BIMI is an email specification that's directly connected to authentication, but it’s not a standalone email authentication protocol as it requires all your email to comply with [DMARC](send-email-authentication-dmarc.md) authentication. While BIMI requires DMARC, DMARC requires your domain to have either SPF or DKIM records to align, but it’s best to include both SPF and DKIM records for additional security, and because some email service providers (ESPs) require both when using BIMI. The following section goes over the steps to implement BIMI in Amazon SES. ## Setting up BIMI in SES You can configure BIMI for an email domain that you own—in SES that's referred to as a *custom* MAIL FROM domain. Once configured, all of the messages that you send from that domain will display your BIMI logo in [email clients that support BIMI](https://bimigroup.org/bimi-infographic/). Enabling your emails to display a BIMI logo requires some prerequisites to be in place within SES—in the following procedure, these prerequisites are generalized and will reference dedicated sections that cover these topics in detail. The steps specific to BIMI and what is necessary to configure it in SES will be detailed here. **To set up BIMI on a custom MAIL FROM domain** 1. You must have a custom MAIL FROM domain configured in SES with both SPF (type TXT) and MX records published for that domain. If you don't have a custom MAIL FROM domain, or would like to create a new one for your BIMI logo, see [Using a custom MAIL FROM domain](mail-from.md). 1. Configure your domain with Easy DKIM. See [Easy DKIM in Amazon SES](send-email-authentication-dkim-easy.md). 1. Configure your domain with DMARC by publishing a TXT record with your DNS provider with the following enforcement policy specifics required for BIMI similar to either of the two examples: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-bimi.html) In the preceding DMARC policy example as required for BIMI: + `example.com` should be replaced with your domain or subdomain name. + The `p=` value can be either: + *quarantine* with a *pct* value set to *100* as shown, or + *reject* as shown. + If you're sending from a subdomain, BIMI requires that the parent domain must also have this enforcement policy. Subdomains will fall under the parent domain’s policy. However, if you add a DMARC record for your subdomain in addition to what is posted for the parent domain, your subdomain must also have the same enforcement policy to be eligible for BIMI. + If you've never set up a DMARC policy for your domain, see [Complying with DMARC authentication protocol in Amazon SES](send-email-authentication-dmarc.md) ensuring that you only use the DMARC policy values specific to BIMI as shown. 1. Produce your BIMI logo as a Scalable Vector Graphics (SVG) `.svg` file—the specific SVG profile required by BIMI is defined as SVG Portable/Secure (SVG P/S). In order for your logo to display in the email client it must conform exactly to these specifications. See the [BIMI Group's](https://bimigroup.org/) guidance on [creating SVG logo files](https://bimigroup.org/creating-bimi-svg-logo-files/) and recommended [SVG conversion tools](https://bimigroup.org/svg-conversion-tools-released/). 1. (Optional) Obtain a Verified Mark Certificate (VMC). Some ESPs, such as Gmail and Apple, require a VMC to provide evidence that you own the trademark and content of your BIMI logo. Although this isn't a requirement for implementing BIMI on your domain, your BIMI logo will not display in the email client if the ESP you send mail to enforces VMC compliance. See the BIMI Group's references to [participating certificate authorities](https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/) to obtain a VMC for your logo. 1. Host your BIMI logo's SVG file on a server you have access to making it publicly accessible through HTTPS. For example, you could upload it to an [Amazon S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html). 1. Create and publish a BIMI DNS record that includes a URL to your logo. When an [ESP that supports BIMI](https://bimigroup.org/bimi-infographic/) checks your DMARC record, it will also look for a BIMI record containing the URL for your logo's `.svg` file, and if configured, the URL for your VMC's `.pem` file. If the records match, they'll display your BIMI logo. Configure your domain with BIMI by publishing a TXT record with your DNS provider with the following values as shown—sending from a domain is represented in the first example; sending from a subdomain is represented in the second example: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-bimi.html) In the preceding BIMI record examples: + The name value should literally specify `default._bimi.` as a subdomain of `example.com` or `marketing.example.com` which should be replaced with your domain or subdomain name. + The `v=` value is the *version* of the BIMI record. + The `l=` value is the *logo* representing the URL pointing to your image's `.svg` file. + The `a=` value is the *authority* representing the URL pointing to your certificate's `.pem` file. You can validate your BIMI record with a tool like the BIMI Group's [BIMI Inspector](https://bimigroup.org/bimi-generator/). The final step in this process is to have a regular sending pattern to the ESPs that support BIMI logo placement. Your domain should have a regular delivery cadence and should have a good reputation with the ESPs that you're sending to. BIMI logo placement may take time to populate to ESPs where you don’t have an established reputation or sending cadence. You can find more information and resources pertaining to BIMI through the [BIMI Group](https://bimigroup.org/) organization.