Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DKIM › AWS Route 53

Add a DKIM record in Route 53

Route 53 has one rule that no other DNS (Domain Name System) console shares, and getting it wrong is the reason most DKIM (DomainKeys Identified Mail) records fail here: a TXT (Text) value goes into the Value field wrapped in double quotes, and a CNAME (Canonical Name) target goes in with none. Both entries save without complaint either way, so a record with the wrong quoting sits in the hosted zone looking finished while DKIM never validates.

What Route 53 does, and what it cannot do

Route 53 is the DNS host for the domain. It publishes whatever record the mail platform hands over, generates nothing on its own, and holds no private key for your domain.

The signing happens at the mail platform. It creates a key pair inside its own console, keeps the private half, signs each outgoing message with it, and gives you the public half plus a short label called a selector. A receiving server reads the selector from your message’s DKIM-Signature header, queries <selector>._domainkey.yourdomain.com, and checks the signature against whatever key answers. The DKIM guide covers what the receiver does with the result.

One AWS-specific shortcut is worth knowing before you start typing. For a domain whose DNS is already in Route 53, Amazon SES can offer to write its three Easy DKIM CNAME records into the hosted zone directly. Adding them by hand is optional in that case, so if SES is your sender, check whether it has already done the work.

Make sure you are editing the live hosted zone

Open the Route 53 console, go to Hosted zones, and select the domain. Read the four NS values shown there and check they match the nameservers set at the registrar.

This check matters more in Route 53 than in most consoles. Several hosted zones for the same domain, or more than one AWS account, make it easy to edit a zone that is not the live one, and the console gives no hint which is which. The four NS values are the test. If the live nameservers point elsewhere, the record has to go there instead of into this zone.

The record, and the quoting rule

Laid out the way Route 53 expects it, the two record types look like this:

TXT    "v=DKIM1; k=rsa; p=..."
CNAME  selector1-yourdomain._domainkey.yourdomain.onmicrosoft.com

Record name takes the selector alone, such as google._domainkey or selector1._domainkey, because Route 53 appends the zone itself and shows the domain beside the field. Record type is set to TXT or CNAME to match exactly what the mail platform issued. The Value field takes a TXT key wrapped in double quotes or a CNAME target host with no quotes at all. TTL (Time to Live) is left at the Route 53 default.

The selector has to match the one the platform signs with, letter for letter, because a receiver builds its lookup from the s= tag in the signature. selector1 and selector2 are two different keys.

Add the record in Route 53

Copy both pieces from the platform’s DKIM or email authentication page and keep that tab open until the check at the end passes.

  1. In the Route 53 console, choose Hosted zones from the left menu.
  2. Click the name of the domain to open its hosted zone.
  3. Click Create record to open the record form.
  4. If a routing-policy wizard appears, switch to Quick create record.
  5. In Record name, type only the selector, for example google._domainkey or selector1._domainkey.
  6. Set Record type to TXT for a Google Workspace key or to CNAME for a Microsoft 365 or Amazon SES key.
  7. In Value, paste a TXT key wrapped in double quotes, for example "v=DKIM1; k=rsa; p=...", or paste a CNAME target with no quotes.
  8. Click Create records, then repeat the same steps for every remaining record the mail platform issued.

Traps specific to Route 53

Your SPF record lives in the same hosted zone as a TXT record at the zone apex, and it follows the same quoting rule as the DKIM TXT value.

Save, wait, then check

The TTL left at the Route 53 default governs how long a cached answer survives elsewhere, so a check run immediately after saving can read as absent while the record is correct. Once saved, the record appears in the hosted zone’s record list under the name and type just created. Reopen that list and confirm the new entry shows the selector name, the correct type, and the value exactly as pasted, quotes included or excluded as the type requires.

With the entry confirmed, run the free scan against your domain. It makes the selector query a receiving mail server makes and reports whether a readable key answered from the live zone.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

A check from the mail side proves the platform is signing as well as that the key is there. Send a message from the domain to an address outside it and read the Authentication-Results header on what arrives. dkim=pass with your domain in header.d= means the key in the hosted zone verified the signature the platform applied.

When it does not pass

Check the quoting first, because it is the failure this console produces that no other console can. Then confirm you edited the hosted zone whose NS values match the registrar. Then the Record name for a doubled host. Then whether every record the platform issued is present, all two for Microsoft 365 or all three for SES. Then the tail of the value.

If all of that is right and a scan still reports nothing, the cause may be how checking works. There is no way to list the DKIM records on a domain, so any checker has to ask for selectors by name and can only ask for the ones it knows to try. A key under a selector the checker doesn’t try is invisible to it, so this scan records that case as not determinable, never as absent. The census has the same limit: of the 76,563,365 domains where the October 2026 census could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%).

Finding your DKIM selector shows how to read the live selector out of a message already sent, which settles it for your own domain.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.