DKIM CNAME Record Setup for Microsoft 365, SES, and More

What a DKIM CNAME record does

One wrong DNS field can make every signed message look unsigned. That is why DKIM CNAME records deserve more care than a quick copy and paste.

A DKIM CNAME record is a pointer. It usually lives at a host name like selector1._domainkey.example.com. It points to a host name owned by your mail provider. The provider hosts the DKIM public key there, signs your mail with the matching private key, and can rotate keys without asking you to edit DNS every time.

Classic DKIM records often use TXT records at the selector host. Provider managed DKIM often uses CNAME records instead. Microsoft 365, Amazon SES Easy DKIM, and many email platforms use this model. Your DNS does not hold the long public key. It points to the place where the provider publishes it.

The selector matters. A receiving mailbox reads the DKIM-Signature header, finds the s= selector and d= domain, then checks DNS at selector._domainkey.domain. If the CNAME is missing, proxied, typed with the wrong domain, or still waiting on DNS, DKIM can fail even when the platform says signing is on.

How to add the record

Use the exact names and targets from the sending platform. Do not build the target by memory unless the official setup screen tells you to.

• Open the DKIM setup page for the platform that sends mail as your domain.
• Copy each DKIM host name into DNS as the record name or host. Common hosts look like selector1._domainkey or a generated token under _domainkey.
• Set the record type to CNAME when the provider says CNAME. Do not change it to TXT.
• Paste the target exactly as shown. Some DNS hosts add your root domain for you. Check the final full name before saving.
• Turn off DNS proxying for these records if your DNS provider offers it. Mail receivers need normal DNS, not a web proxy.
• Wait for DNS to publish, then return to the mail platform and enable or verify DKIM signing.
• Send a real test message to a mailbox you control and inspect the headers for dkim=pass and DMARC alignment.

For Microsoft 365 custom domains, Microsoft shows two CNAME records, commonly using selector1 and selector2. Publish both, then enable DKIM for the domain in the Microsoft Defender portal. Microsoft says detection can take a few minutes or longer after the records exist.

For Amazon SES Easy DKIM, SES shows three CNAME records for the identity. AWS says Easy DKIM signs mail for that identity and uses provider hosted records. Copy all three records from the SES console or API. Some regions use region specific DKIM domains, so trust the values SES gives you for that identity.

Other platforms follow the same pattern. The left side is a selector under your domain. The right side is a provider host. The provider owns the key and signing process. You own the DNS pointer and the decision to let that provider sign for your domain.

How DKIM fits SPF and DMARC

A DKIM CNAME record can fix signing, but it does not fix every spam folder problem by itself.

SPF says which servers may send mail for a domain. It is a TXT record that starts with v=spf1. Use one SPF record at the root or sending subdomain. RFC 7208 limits SPF mechanisms and modifiers that cause DNS lookups to 10 during a check, so keep includes under control. A soft fail ending like ~all is common while you are proving the setup. A hard fail like -all is stricter and should wait until every sender is known.

DKIM adds a signature over selected headers and the message body hash. The private key stays with the sender. The public key is found through DNS, either directly in TXT or through a CNAME target. DKIM can survive forwarding better than SPF when the message is not changed in ways covered by the signature.

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. A simple starting record is often v=DMARC1; p=none; rua=mailto:dmarc@example.com. Move from p=none to p=quarantine or p=reject only after reports show that real mail is passing. DMARC aggregate reports, sent to rua, show who is sending as your domain.

MX records matter for receiving mail. They do not authorize outbound mail by themselves. Blocklists can still affect delivery if the sending IP or domain has a poor history. Gmail and Outlook.com also look at spam complaints, bad list hygiene, suspicious content, broken unsubscribe flows, and user engagement. Authentication gets you past identity checks. It does not force inbox placement.

Checks before you call it done

The best test is boring: DNS resolves, headers pass, and DMARC reports show the right provider.

• Run a DNS lookup for each selector host. It should return the provider target as a CNAME.
• Check that the CNAME target resolves to a DKIM TXT record when followed.
• Confirm the platform is signing with your domain in the d= value, rather than only with the provider domain.
• Confirm DMARC passes through SPF alignment or DKIM alignment. For provider managed DKIM, DKIM alignment is often the key result.
• Keep SPF below the 10 lookup limit. Remove dead includes before adding new ones.
• Use p=none DMARC reports to find old systems before enforcing quarantine or reject.
• Check the domain with the free InboxRadar scorecard after DNS has had time to publish.

If a check fails, read the exact host name first. Many DKIM CNAME mistakes are one label off: selector1._domainkey was added under the wrong zone, the DNS host appended the root twice, or the value was pasted into the name field. If the record looks right but still fails, wait for the TTL, then test from a public resolver.

For official details, use the provider setup page and the standards: RFC 6376 for DKIM, RFC 7208 for SPF, RFC 9989 for current DMARC rules (with RFC 7489 as the older base spec), plus Google sender guidelines and Outlook.com Postmaster policies. Provider screens change. The DNS shape stays simple: selector host on your domain, CNAME target at the sender, signing enabled in the mail platform.