How to set up DKIM on AWS Route 53

Publish your mail provider's DKIM key in your Route 53 hosted zone so your emails carry a tamper-proof signature.

Why this matters to your business

DKIM (DomainKeys Identified Mail) adds an invisible digital signature to every email you send. The receiving mail provider uses a public key you’ve published in your DNS to confirm two things: the message really came from your domain, and nobody altered it on the way.

In plain terms: DKIM is a seal of authenticity on your email. It makes impersonation harder and improves the chance your genuine mail reaches the inbox rather than spam. Like the others, it’s free and it’s a one-time setup.

Important: DKIM has two halves

DKIM is the one record where it really matters who does what:

Your mail provider generates the key. Google Workspace, Microsoft 365, Amazon SES, or whoever runs your sending generates the DKIM key for you, inside their admin console. You cannot make this up — you must get the exact host name and value from them. Route 53 does not generate DKIM keys; it is your DNS host, not your mailbox provider.
Route 53 publishes it. You then add that key to your domain’s DNS in Route 53 (assuming Route 53 runs your DNS — see below).

So: generate in the mail platform, publish in the DNS host.

First, confirm Route 53 runs your DNS

A DKIM record only works if Route 53 is answering DNS for your domain. In the Route 53 console, open Hosted zones, select your domain, and note the four NS (nameserver) values. Those must match the nameservers set at your registrar. If you registered the domain through Route 53 they usually already match; if it’s registered elsewhere — or you have more than one hosted zone for the domain — check carefully. If the live nameservers point to another provider, add the DKIM record there instead; it won’t take effect at Route 53.

Get the key from your mail provider

In your mail provider’s admin area, look for the DKIM or email-authentication setting and generate/enable a key. What you get back depends on the provider, and it changes how you enter it in Route 53:

Google Workspace gives you a TXT record: a selector name like google._domainkey and a long value beginning v=DKIM1; k=rsa; p= followed by a very long string.
Microsoft 365 gives you two CNAME records, with selectors like selector1._domainkey and selector2._domainkey, each pointing to a Microsoft host.
Amazon SES gives you three CNAME records (its “Easy DKIM” feature). If your domain is in Route 53, SES can often offer to add these for you automatically — but you can also add them by hand.

Copy the host names and values exactly.

Step-by-step on Route 53

Sign in to the AWS console and open Route 53.
In the left menu, choose Hosted zones, then click the name of your domain.
Click Create record.
If a wizard with routing options appears, switch to the simple form (look for Quick create record).
In Record name, enter only the selector part — for example google._domainkey or selector1._domainkey. Do not add your domain name on the end; Route 53 appends the zone for you automatically (it shows your domain beside the field).
Set Record type to TXT or CNAME to match exactly what your provider gave you (Google = TXT; Microsoft 365 and Amazon SES = CNAME).
In Value:
- For a TXT key, paste the long value wrapped in double quotes: "v=DKIM1; k=rsa; p=...".
- For a CNAME, paste the target host your provider gave you, with no quotes (e.g. selector1-yourdomain._domainkey.yourdomain.onmicrosoft.com).
Leave TTL at the default.
Click Create records. Repeat for each record (Microsoft 365 needs two; Amazon SES needs three).

Route 53 quirks people get wrong

TXT keys need double quotes; CNAMEs do not. This trips people up constantly. A TXT DKIM value goes in as "v=DKIM1; ... p=..." with the quotes. A CNAME value is just the plain target host, no quotes. Mixing these up breaks the record.
Don’t put the full domain in Record name. If your provider’s instructions show selector1._domainkey.yourdomain.com, you enter only selector1._domainkey in Route 53 — the rest is added for you. Including the domain again creates a broken selector1._domainkey.yourdomain.com.yourdomain.com host.
Paste the whole key — it’s long. TXT DKIM public keys are hundreds of characters. Make sure nothing is cut off and no stray spaces or line breaks crept in during copy-paste.
Add every record your provider asked for. Microsoft 365 won’t validate with only one of its two CNAMEs; Amazon SES needs all three. A partial set leaves DKIM failing silently.
TXT vs CNAME — follow your provider. Don’t convert a CNAME into a TXT or vice versa. Use the type they specify.
Right hosted zone, right account. With several zones or AWS accounts it’s easy to edit the wrong one. Make sure the zone’s four NS values match your live nameservers.
Give it time. DNS changes can take minutes to a couple of hours to propagate before DKIM starts validating.

Verify it worked

After saving and allowing a little propagation time, run the free check on this site. It will confirm in plain language whether your DKIM record is published and readable.

Done? Check your domain free to confirm it worked — and see your full grade across all 34 checks.