DKIM setup: selectors, keys and the DNS record

· 6 min read

Of the three email authentication methods, DKIM is the most robust because it survives forwarding and is the easiest path to DMARC alignment with almost every provider. Still, it is missing or half finished on many client domains: a selector created but never activated, or a key that the DNS editor chopped into pieces.

How DKIM works

DKIM as defined in RFC 6376 is a digital signature over selected headers and the body of a message. The sending server signs with a private key and attaches the result as a DKIM-Signature header. Among other things it contains the signing domain (d=), the selector (s=) and the list of signed headers (h=).

The receiver reads d= and s= from the signature, fetches the public key from the TXT record at selector._domainkey.domain and verifies the signature. If it checks out, the receiver knows the message came from someone with access to the domain's private key and has not been modified since. Unlike SPF, the verification does not depend on which server delivered the message last.

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Choosing selectors

The selector is a freely chosen name that allows several keys to be published under one domain at the same time. Every sender gets its own: Microsoft 365 uses selector1 and selector2, Google Workspace defaults to google, newsletter tools prescribe names such as k1 or s1. For your own servers pick something descriptive with a date or year, for example mail2026a, which makes rotation easier later on.

Because selectors are independent of each other, any number of services can sign for the same domain without getting in each other's way. That is the big difference to SPF with its single record and lookup limit.

Key length: 2048 bits

RFC 8301 requires receivers to verify RSA keys between 1024 and 4096 bits and recommends that senders use at least 2048 bits. 1024 bits is considered too weak and is already downgraded by some receivers. 4096 bits is not cryptographically necessary and produces a p= value of roughly 700 characters, which some DNS providers and mail systems do not handle cleanly.

A 2048 bit key results in a record of about 400 characters. That is longer than the 255 characters a single TXT string may have. DNS allows several strings in one record, which the receiver concatenates. A good DNS editor does this automatically, a bad one truncates or puts quotation marks in the middle of the key.

s1._domainkey.example.com.  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx2f...firstHalf"
                                    "secondHalf...IDAQAB" )

CNAME delegation with providers

Most services want to manage and rotate the key themselves. For that you do not create a TXT record with the key but a CNAME pointing to a hostname of the provider. Microsoft 365, SendGrid, Mailchimp and Amazon SES work this way. Google Workspace, on the other hand, gives you a ready made TXT record to publish.

The advantage of delegation: the provider can swap keys without you doing anything. The disadvantage: the DKIM record is only valid as long as the CNAME target exists. If the client cancels the service, a dangling CNAME remains and the signature can no longer be verified.

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.tenant.onmicrosoft.com.
s1._domainkey.example.com.         CNAME  s1.domainkey.u1234567.wl123.sendgrid.net.

Testing mode, rotation and revocation

With the tag t=y you mark a key as being in testing. Receivers verify the signature but are asked not to treat a failure differently from a missing signature. That is useful when you set up signing on your own server and are not yet sure whether header canonicalisation is right. Do not forget to remove t=y again, because in testing mode some receivers do not count DKIM as fully valid.

Keys should be rotated regularly, because a private key lives on a server and servers get compromised. Rotation is easy since selectors are arbitrary: publish the new key under a new selector, switch signing over, leave the old record in place for a few days until all messages in transit have been verified, then remove it. For an explicit revocation you publish a record with an empty p=, which tells receivers that the selector is deliberately invalid.

Revoked key:
mail2024a._domainkey.example.com.  TXT  "v=DKIM1; p="

Common mistakes

Most DKIM problems are in DNS, not on the mail server. Before you dig into the server, check the published record with the DMARC checker, which shows whether the selector resolves and the key is valid.

  • Wrongly split key: quotation marks or spaces in the middle of the p= value because the DNS editor mishandled the 255 character boundary
  • Wrong selector: the server signs with s=mail, but DNS has s1._domainkey
  • Record in the wrong place: the selector belongs at selector._domainkey.example.com, not at _domainkey.example.com or at the apex
  • v=DKIM1 missing or not at the start: the tag is recommended by the RFC and, if present, must come first; many validators expect it
  • Public key with header lines: only the base64 block belongs in p=, not BEGIN PUBLIC KEY
  • CNAME and TXT on the same name at the same time, which DNS does not allow
  • DKIM created in the provider portal but never activated, so nothing is signed at all

Alignment with DMARC

For DMARC, DKIM only counts if the d= domain of the signature aligns with the From domain. Many services sign with their own domain by default, which gives DKIM pass but DMARC fail. Only when you set up a custom sending domain in the provider portal and publish the corresponding record does the service sign with d=example.com.

With relaxed alignment it is enough for d= to be a subdomain or the organisational domain. A newsletter with From on news.example.com and a signature of d=example.com is aligned. That allows every service to sign under the main domain with its own selector while sender addresses stay cleanly separated.

  1. Add the domain at the service and note the prescribed selector with its record or CNAME target.
  2. Create the record in DNS; for TXT make sure the split beyond 255 characters is correct.
  3. After the TTL has expired, check the selector with the DMARC checker.
  4. Activate DKIM in the service portal and send a test message to a mailbox at Google or Microsoft.
  5. Check the Authentication-Results header for dkim=pass with the right domain.
  6. Verify in the DMARC reports of the next few days that the sender now delivers an aligned pass.

Frequently asked questions

Do I need DKIM if SPF already passes?
Yes. SPF breaks on every forward, and with many services SPF alignment is not even possible because they use their own Return-Path. For a stable DMARC p=reject, DKIM on every sender is mandatory.
Can I use one key for several domains?
Technically yes, if you publish the same public key under each domain. It is not advisable, because a compromised key then affects all domains. One key per domain and service is cleaner.
What do dkim=neutral or dkim=policy mean in the authentication results?
neutral usually means the signature was syntactically unusable or the key is in testing mode. policy means the receiver rejects the signature for its own reasons, for example keys that are too short or SHA-1. In both cases it is worth looking at key length and record.
Check now

Free DKIM record check and lookup: selector, key type, key length, syntax and revoked keys. Leave the selector empty to try common selectors automatically.

Selector is optional: leave it empty to check common selectors automatically.

A dangling CNAME after a cancellation or a rotated key without a DNS update only becomes visible when mail lands in spam. DomainWarn checks the DKIM selectors of your client domains regularly together with SPF and DMARC and reports every change.

Monitor this domain continuously14-day free trial, no credit card.

More guides