Provider setup

Amazon SES SPF, DKIM and DMARC: custom MAIL FROM and Easy DKIM

Why SES mail passes SPF for amazonses.com, the MX and TXT records a custom MAIL FROM domain needs per Region, Easy DKIM's three CNAMEs, and DMARC.

By Updated Last verified

On this page
  1. Why SPF passes for amazonses.com, not your domain
  2. Set up a custom MAIL FROM domain
  3. Regions and identities
  4. Easy DKIM: the three CNAME records
  5. DMARC for an SES sender
  6. Check your domain
  7. Sources

Amazon SES (Simple Email Service) does not need a line in your root SPF record to pass SPF. By default SES uses a subdomain of amazonses.com as the MAIL FROM domain (opens in a new tab), so SPF is implicitly set up for you, but that pass is for Amazon's domain, not yours. To get SPF that counts for your domain, set up a custom MAIL FROM domain (opens in a new tab): a subdomain such as bounce.example.com with one MX record pointing to feedback-smtp.<region>.amazonses.com and a TXT record v=spf1 include:amazonses.com ~all. For DKIM, add the three CNAME records Easy DKIM (opens in a new tab) gives you, then publish a DMARC record (opens in a new tab) as a TXT record at _dmarc.example.com.

Why SPF passes for amazonses.com, not your domain

Every message SES sends has two sender addresses (opens in a new tab): the From address the recipient sees, and the MAIL FROM address, also called the envelope sender, bounce address or Return Path. Mail servers use the MAIL FROM address to return bounces and other error notifications, and SES sets the MAIL FROM domain to a default unless you specify your own. The default is a subdomain of amazonses.com, so SPF (Sender Policy Framework) validates the message because the MAIL FROM domain belongs to the service that sent it.

DMARC (Domain-based Message Authentication, Reporting and Conformance) asks a second question. On SES's DMARC page (opens in a new tab), SPF only checks the domain in the MAIL FROM address, and for SPF to pass DMARC alignment, the domain in the From address must match the domain in the MAIL FROM address. RFC 9989 (opens in a new tab) requires the domain behind the SPF or DKIM pass to be aligned with the From domain. Under RFC 9989 section 4.4 (opens in a new tab), relaxed alignment means the same organizational domain and strict alignment means an identical domain. A subdomain of amazonses.com is neither for example.com, so the default SPF pass does nothing for your DMARC result. A custom MAIL FROM domain gives you the choice of SPF, DKIM or both for DMARC.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Set up a custom MAIL FROM domain

The custom MAIL FROM procedure (opens in a new tab) sets three rules for the subdomain: it has to be a subdomain of the parent domain of a verified identity (email address or domain), it shouldn't be a subdomain you also send email from, and it shouldn't be one you receive email at. This page uses bounce.example.com.

In the SES console, under Configuration, choose Identities, then pick an identity whose type is Domain and whose status is Verified. In the Custom MAIL FROM domain pane choose Edit, select Use a custom MAIL FROM domain, and enter the subdomain. You can also set it with the SetIdentityMailFromDomain API operation. The Publish DNS records table then shows two records. For an identity in us-east-1 they look like this:

Name Type Value
bounce.example.com MX 10 feedback-smtp.us-east-1.amazonses.com
bounce.example.com TXT "v=spf1 include:amazonses.com ~all"

The region part of the MX value is the AWS Region where you verify the MAIL FROM domain, such as us-west-2, us-east-1 or eu-west-1. The 10 is the preference, which your DNS host may ask for in a separate field. The TXT value usually needs its quotation marks, though some DNS providers don't require them. If Route 53 provides DNS for the MAIL FROM domain and you are signed in to the same account, you can choose Publish Records Using Route 53.

Publish exactly one MX record on the MAIL FROM subdomain: with more than one, the setup fails. SES may take up to 72 hours to detect the MX record. The setup stays pending while SES looks; after 72 hours without the record it moves to Failed, and SES stops checking until you restart the setup. Once it succeeds, SES keeps checking that the MX record is in place.

In the Pending, TemporaryFailure and Failed states SES sends with your custom MAIL FROM fallback setting; only Success uses the custom domain. Behavior on MX failure decides what happens when the MX record is not set up correctly. Use default MAIL FROM domain sends with a subdomain of amazonses.com, which varies by Region, so mail keeps going out under Amazon's MAIL FROM domain rather than yours. Reject message makes SES return a MailFromDomainNotVerified error and reject what you try to send.

Checked against live DNS, amazonses.com publishes an SPF record of thirteen ip4 ranges ending in -all, with no nested include. Under RFC 7208 (opens in a new tab) an include counts toward the limit of 10 DNS-querying terms and ip4 does not, so include:amazonses.com costs one lookup. It sits on the MAIL FROM subdomain's own record, not your root record. If your root record is near the limit for other senders, see SPF too many DNS lookups.

Regions and identities

SES has two kinds of identity. SES's identity documentation (opens in a new tab) describes them: verify an email address identity and only that address can send; verify a domain identity and you can send from any subdomain or address of that domain without verifying each one. Settings on a verified email address identity override those of its domain.

Identities do not cross Regions. To send from the same domain or email address in more than one AWS Region, you create and verify a separate identity in each Region, and the validation records you add to DNS are different for each Region. The SES Regions page (opens in a new tab) gives an example: a domain verified in US West (Oregon) cannot send in US East (N. Virginia) until you verify it again there. Identity settings such as whether you receive feedback by email or through SNS apply only to the Region you set them in, and using a custom MAIL FROM domain is one of the options you set when you create a domain identity.

The MX value follows the Region too. When you configure a custom MAIL FROM domain, SES fills in the feedback endpoint for the Region where you configure it and shows it in the MX record's value field. The Regions page adds that you can use the same custom MAIL FROM domain for verified identities in different Regions, because bounce and complaint notifications go to a region-specific feedback endpoint. The custom MAIL FROM page (opens in a new tab) separately requires exactly one MX record on the MAIL FROM domain, so compare the MX value SES shows in each Region before you reuse a subdomain. The AWS General Reference (opens in a new tab) lists the feedback endpoints by Region, for example feedback-smtp.us-east-1.amazonses.com for US East (N. Virginia), feedback-smtp.us-west-2.amazonses.com for US West (Oregon) and feedback-smtp.eu-west-1.amazonses.com for Europe (Ireland).

Easy DKIM: the three CNAME records

DKIM (DomainKeys Identified Mail) signs each message so receivers can check it against a public key in DNS. SES's DKIM overview (opens in a new tab) offers Easy DKIM, where SES generates the key pair and signs every message from the identity, and BYODKIM (Bring Your Own DKIM), where you supply the key pair. You only need DKIM for the domain in your From address, not for Return-Path or Reply-To domains. Set up DKIM on a domain and it also applies to its subdomains and to every address on it. If you send from more than one Region, complete the DKIM setup in each of them. The same page also describes Deterministic Easy DKIM (DEED), which keeps DKIM signing consistent across Regions with replica identities that inherit the signing attributes of a parent identity using Easy DKIM; SES's identity setup page lists no additional DNS setup for a replica identity created with DEED.

Easy DKIM (opens in a new tab) adds a 2048-bit key by default; you can pick RSA_1024_BIT instead under the identity's Authentication tab. The identity's Publish DNS records table lists three CNAME records. The Easy DKIM records page (opens in a new tab) shows how they are built from the tokens and the SigningHostedZone that aws sesv2 get-email-identity --email-identity "example.com" returns:

<token1>._domainkey.example.com  CNAME  <token1>.<SigningHostedZone>
<token2>._domainkey.example.com  CNAME  <token2>.<SigningHostedZone>
<token3>._domainkey.example.com  CNAME  <token3>.<SigningHostedZone>

In AWS's example the hosted zone is dkim.us-west-2.amazonses.com, giving records such as hirjd4exampled5477y22yd23ettobi._domainkey.example.com pointing to hirjd4exampled5477y22yd23ettobi.dkim.us-west-2.amazonses.com. The hosted zone varies by AWS Region and can differ between identities, so always use the SigningHostedZone returned for your identity rather than a hardcoded zone. SES's identity setup page (opens in a new tab) names two DNS traps: the underscore in the record name is required, but don't add an extra one at the start of the name; and check that your DNS host did not append your domain to the name you entered. Receivers look a DKIM key up at the selector under _domainkey in the signing domain, per RFC 6376 (opens in a new tab), so the token in front of _domainkey is the selector; DKIM selector explains how to find it in a message header.

BYODKIM (opens in a new tab) needs a single DNS record instead of three, selector._domainkey.example.com as TXT with p= followed by your public key, and lets you rotate keys as often as you want. If you move from Easy DKIM to BYODKIM, SES stops signing with Easy DKIM while BYODKIM is pending, so until SES confirms your DNS configuration your emails may be sent without a DKIM signature.

SES's DKIM troubleshooting page (opens in a new tab) covers two things you may notice later. Signed mail can carry a second signature with d=amazonses.com; SES adds it automatically and you can ignore it. And if SES can no longer find the CNAME records, it emails you that your DKIM setup has been or will be revoked; once it is revoked, you restart the setup from the beginning.

DMARC for an SES sender

SES's DMARC page (opens in a new tab) describes two paths, and a message passes DMARC if either check passes. Through SPF: the message passes SPF on your custom MAIL FROM domain, that domain is your From domain or a subdomain of it, and your DMARC record does not set aspf=s. Through DKIM: the message carries a valid DKIM signature whose domain aligns with the From domain, which Easy DKIM provides; if you send from a subdomain of the signing domain, keep DKIM alignment relaxed. RFC 9989 (opens in a new tab) makes relaxed (r) the default for both aspf and adkim, so leaving those tags out keeps both paths open.

Publish the record as TXT at _dmarc.example.com. SES recommends a phased rollout: start with p=none to collect reports, move to quarantine when all or most legitimate mail is aligned through SPF or DKIM, and treat reject as the final step. A starting record from the DMARC generator:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

How to set up DMARC walks the move from none to enforcement. If reports show SES mail failing, DMARC fail explains how to read the result.

Check your domain

The free SPF, DKIM and DMARC check reads the public DNS records of the domain you enter; it changes nothing and sends no email. For DMARC it flags a missing record, a policy of none, no reporting address and subdomains left at none. For DKIM it tries commonly used selectors, and a key under a selector it does not try shows as not verified; compare against the records SES lists for your identity (opens in a new tab). With a custom MAIL FROM domain (opens in a new tab), the SPF record SES relies on is on that subdomain, not your root domain, so a result for the root domain's SPF does not cover it. A DNS finding shows how the domain is set up, not where a particular message landed.

Sources

Tools for this

Frequently asked questions

Do I need include:amazonses.com in my root SPF record?

Not for SPF on mail SES sends. SES uses a subdomain of amazonses.com as the default MAIL FROM domain, and with a custom MAIL FROM domain the v=spf1 include:amazonses.com ~all record goes on that MAIL FROM subdomain, next to its MX record.

Why does SPF pass but DMARC fail for my SES mail?

With the default MAIL FROM domain, SPF passes for a subdomain of amazonses.com, which does not align with your From domain. Set up a custom MAIL FROM subdomain of your domain, or Easy DKIM, so that SPF or DKIM passes for your own domain.

Do I set this up again in each AWS Region?

Partly. To send from the same domain or address in another Region you create and verify a separate identity there. DKIM is set up per Region, either with that Region's Easy DKIM records or with a Deterministic Easy DKIM (DEED) replica identity that needs no additional DNS setup. For a custom MAIL FROM domain SES puts the feedback endpoint for the Region you configure into the MX value, and AWS documents that the same custom MAIL FROM domain can serve identities in different Regions.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account