On this page

Fixing DKIM in AWS Route 53 for Microsoft 365

What this fixes

DKIM lets receiving servers verify your mail hasn't been altered in transit and really came from you. See Fixing DKIM Record Issues for what it does and why it matters.

Important: unlike most DNS-based email checks, Microsoft 365's DKIM record is a CNAME, not a TXT record — and you need two of them.

This assumes you already have a hosted zone in Route 53 for your domain, and IAM permissions to edit it.

Step 1: Get your exact CNAME values from Microsoft

  1. Go to the Microsoft Defender portal (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM tab.
  2. Select your domain. Microsoft shows you the two CNAME records to publish.
  3. Copy the two selector names and their target values exactly as shown — the target format varies by when your domain was added, so copy it directly rather than guessing the pattern.

You'll get two records, typically named selector1._domainkey and selector2._domainkey.

Step 2: Publish both in Route 53

For each of the two records:

  1. Open the Route 53 console and go to Hosted zones → select your domain's hosted zone.
  2. Click Create record.
  3. Record name: the selector Microsoft gave you (e.g. selector1._domainkey).
  4. Set Record type to CNAME.
  5. Value: the exact target Microsoft gave you.
  6. Leave TTL at the default.
  7. Click Create records.
  8. Repeat for the second record.

Step 3: Turn on DKIM signing

  1. Back in the Defender portal's DKIM tab, wait for DNS to propagate, then toggle the domain to Enabled.
  2. Confirm Sign messages for this domain with DKIM signatures is on.
  3. Re-run your scan to confirm.

Common pitfalls

  • Hardcoding a .onmicrosoft.com target instead of copying the exact value from the Defender portal.
  • Publishing the CNAME records but never flipping DKIM to Enabled in the Defender portal.