Amazon SES is AWS's outbound email service: cheap and reliable for the emails an application sends (confirmations, notices, invoices). But getting the email to go out is not the hard part; the hard part is getting it to reach the inbox rather than the spam folder. For that, Gmail, Outlook and the rest demand three things that are proven in your domain's DNS: DKIM (a cryptographic signature), SPF (which servers may send on your behalf) and DMARC (what to do with anything that fails the other two).

If your domain is in Route 53, in the same AWS account, SES can create most of the records for you. Even so, it is worth knowing what it is putting there and why.

Before you start: what each thing means

SES: Simple Email Service, Amazon's service for your applications to send email (confirmations, notices, invoices).
Route 53: Amazon's DNS service, that is, where you manage which servers your domain points to.
DNS and records: The "phone book" of the internet: it translates your domain into addresses and stores configuration text. Each entry is a record, with a name, a type (TXT, CNAME, MX...) and a value.
Verifying the domain: Proving to Amazon that the domain is yours, by adding to its DNS some records that only the owner can add.
DKIM: A digital signature that SES adds to every email and that the receiver checks against a key published in your DNS. It proves the email has not been altered and comes from your domain.
SPF: A text record in your DNS that says which servers are allowed to send email using your domain.
DMARC: Another text record that tells receivers what to do with emails that fail DKIM or SPF (nothing, quarantine or reject) and where to send you reports.
Custom MAIL FROM: A subdomain of yours that SES uses as the technical sender, so that the checks are made against your domain and not Amazon's.
Sandbox: The test mode every SES account starts in: it only allows sending to verified addresses. There is a separate guide on getting out of it.

Step by step

Choose the SES region

SES works per region and verified identities are not shared between regions. Pick one close to your users or where you already have everything else (for example Europe - Ireland, eu-west-1) and stick with it for good: your application will have to send to that region.
Create the domain identity

In the SES console, Identities, Create identity, type Domain. Enter the domain without "www" (midominio.com). In the DKIM section leave Easy DKIM with the key length SES proposes. If the domain is in Route 53 in this account, you will see the box to publish DNS records to Route 53 automatically: tick it. Create the identity.

SES generates three CNAME records of the form xxxx._domainkey.midominio.com. With the box ticked they are already in Route 53; if not, copy them and create them by hand in the hosted zone. Verification takes anywhere from minutes to a few hours; the identity will switch to "Verified" on its own.
Set up a custom MAIL FROM domain (for SPF)

By default, SES emails go out with a technical sender at amazonses.com, which is what SPF looks at. For the check to be made against your domain so that DMARC can "align", set up a custom MAIL FROM domain: inside the identity, Custom MAIL FROM domain tab, Edit, and enter a subdomain you use for nothing else, for example correo.midominio.com. Choose to have SES use the amazonses.com default if the MX lookup fails, so that a DNS error does not stop you sending.

SES asks you for two records on that subdomain (again, with Route 53 it can add them itself):

Name Type Value

correo.midominio.com MX 10 feedback-smtp.eu-west-1.amazonses.com (replace the region with yours)

correo.midominio.com TXT "v=spf1 include:amazonses.com ~all"
Add SPF to the main domain too

If you send email from other places (your mail server, a newsletter provider), your root domain will already have a v=spf1 TXT record. Add include:amazonses.com to that same record; never create a second TXT record starting with v=spf1, because two SPF records invalidate both. If you have none, create it in Route 53:
```
Nombre: midominio.com    Tipo: TXT
Valor:  "v=spf1 include:amazonses.com ~all"
```
If you also use Google Workspace or Microsoft 365, the value will carry their corresponding include as well, separated by spaces.
Publish the DMARC policy

DMARC is a TXT record on the _dmarc subdomain. Start in monitoring mode (p=none) so that nobody rejects your email while you fine-tune, and request reports to an address you actually read:
```
Nombre: _dmarc.midominio.com    Tipo: TXT
Valor:  "v=DMARC1; p=none; rua=mailto:dmarc@midominio.com"
```
In Route 53: Create record, name _dmarc, type TXT, value in quotes. After a few weeks with no surprises in the reports, move up to p=quarantine and then to p=reject. Gmail and Yahoo require DMARC from anyone sending a lot of email, so do not skip it.
Verify and send a test

In the SES identity everything should show green: identity verified, DKIM correct and MAIL FROM configured. Send a test email to a Gmail account and open "Show original": it should say SPF: PASS, DKIM: PASS and DMARC: PASS. If you are still in the SES sandbox, you will only be able to send to verified addresses; the guide to getting out of the sandbox is in this same section.

What can go wrong

DKIM has been "pending" for hours

Check that the three CNAMEs are exactly as SES gave them, without the DNS panel having appended the domain twice (xxx._domainkey.midominio.com.midominio.com is the classic mistake outside Route 53). And make sure the domain's NS servers at the registrar are those of the Route 53 zone you are editing; if the domain is managed elsewhere, Route 53 is no use.

SPF passes but DMARC fails

Alignment is missing: SPF was evaluated against amazonses.com, not against your domain, because you have not set up the custom MAIL FROM (step 3). Aligned DKIM is usually enough for DMARC to pass, but set up MAIL FROM anyway.

Email lands in spam with everything on PASS

Authentication is necessary, not sufficient. Content, the domain being new, and the number of bounces and complaints all matter. Start with low volume, remove the addresses that bounce and always give a clear way to unsubscribe. And check reputation in the SES dashboard.

My domain is in another AWS account

SES will not be able to publish the records on its own. Copy them from the identity and create them by hand in the Route 53 zone of the other account. It works just the same, only manually.

In Simplio

In Simplio the Email (SES) screen shows your domains by region and tells you which records are missing (DKIM, SPF, DMARC, MAIL FROM) with the exact value of each one. If the domain is in Route 53, it adds them with one button. You also see the quota, what has been sent, the bounce and complaint rates, and you get a notice if an identity stops being verified.

The same task, in AWS and in Simplio

	In the AWS console	In Simplio
Find out which records are missing	Compare SES with Route 53 by hand, one by one	The Email screen tells you what is missing (DKIM, SPF, DMARC, MAIL FROM) with the exact value
Create the records	Up to 7 records in Route 53, with long names that are easy to copy wrong: 30 minutes	"Add records" button if the domain is in Route 53: 1 click
If it stops being verified	Nobody warns you until email fails	Notice by email

Try it free for 15 days See how it works

How to verify a domain in Amazon SES and set up DKIM, SPF and DMARC in Route 53

Before you start: what each thing means

Step by step

Choose the SES region

Create the domain identity

Set up a custom MAIL FROM domain (for SPF)

Add SPF to the main domain too

Publish the DMARC policy

Verify and send a test