DKIM in DNS

Per-message cryptographic signature, public key in DNS at a selector subdomain. The two forms (TXT or CNAME), and why multi-selector setups matter for key rotation.

DKIM is the email-auth record that most often looks like it’s working when it isn’t. The wizard publishes a value, the panel saves it, the client sends mail, and the receiver still flags it as failing DKIM because the published key doesn’t match the signature in the message.

The two common causes: wrong selector name, and value-format problems (long-TXT issues). Knowing the selector convention and the verify step prevents the silent-failure pattern.

How DKIM works

The sending mail server signs each outbound message with a private key. The public key is published in DNS so receivers can verify:

The message header includes a DKIM-Signature: field naming the signing domain (d=example.com) and the selector (s=selector1).
The receiver constructs the DNS name selector1._domainkey.example.com and queries for a TXT.
The TXT contains the public key: v=DKIM1; k=rsa; p=<long-base64-string>.
The receiver verifies the signature using the public key.

For helpdesk work, you don’t write DKIM records from scratch. The mail vendor publishes them and gives you values to add to your DNS.

The selector convention

DKIM uses a selector to allow multiple keys per domain. The selector is the leftmost label in the DNS name:

selector1._domainkey.example.com.   IN  TXT  "v=DKIM1; k=rsa; p=MIIBIj..."

Common selectors:

Vendor	Default selector(s)
Microsoft 365	`selector1`, `selector2`
Google Workspace	`google` (configurable)
Mailchimp	`k1`
Mailgun	`mta`

The _domainkey part is fixed. Don’t change it.

The two forms: TXT or CNAME

DKIM (TXT form vs CNAME form)text

1		# Direct TXT: vendor gives you the full public-key value, you publish it
2		google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
3
4		# CNAME: you point your selector to the vendor's published TXT
5		selector1._domainkey.example.com. IN CNAME selector1-example-com._domainkey.example.onmicrosoft.com.
6		selector2._domainkey.example.com. IN CNAME selector2-example-com._domainkey.example.onmicrosoft.com.

In MSP work, the CNAME form is more common for cloud mail vendors because of the long-key handling and the rotation benefit.

Multi-selector for key rotation

Multi-selector setups (M365, others) publish two selectors:

selector1._domainkey.example.com.   IN  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.   IN  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

The mail server signs with one selector at a time. When the vendor rotates the key, they sign with the other for a while. Both selectors are valid at any time so messages during the rotation window verify correctly.

For setup: M365’s wizard gives you two CNAMEs. Don’t skip the second because the first one looks enough. Rotation will silently fail.

Practice: verify a DKIM selector

After publishing M365’s two DKIM CNAMEs, verify they resolve.

dkim-selector-check

Check whether selector1 resolves. The CNAME should point at Microsoft's published key.

$ pick one

What this is NOT

“DKIM is one key per domain.” It’s one key per selector; a domain can have many selectors.
“If dig TXT example.com returns nothing about DKIM, DKIM isn’t set up.” DKIM lives at selector subdomains. Query the selector: dig TXT selector1._domainkey.example.com.
“DKIM verifies the From: address.” DKIM verifies the signing domain (d= field). DMARC aligns this against the visible From.

Decision walkthrough

The second CNAME isn't resolving

A client onboards to M365. The wizard provides two DKIM CNAME records to add. You publish both. Two minutes later, selector1._domainkey resolves correctly, but selector2._domainkey returns NXDOMAIN.

selector2 returns NXDOMAIN. What's the cause?

Next lesson →