DKIM Setup and Troubleshooting: Selectors, Key Length, Rotation

DKIM puts a cryptographic signature on each outgoing message so the receiver can check that it came from a server holding your private key and was not altered in transit. When it works, nobody notices. When it fails, you get dkim=fail or dkim=none in message headers, DMARC reports full of unaligned sources, and mail drifting into spam. This guide covers the moving parts and the failure modes in practical order. The concepts of SPF and DMARC are in the complete authentication guide.

How DKIM works in one minute

1. Your mail system holds a private key and signs selected headers and the body, adding a DKIM-Signature: header.
2. You publish the matching public key in DNS as a TXT record.
3. The receiver reads d= (the signing domain) and s= (the selector) from the signature, looks up <selector>._domainkey.<domain>, and verifies.

A signature header looks like this (shortened):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2026;
 h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=AuzW8e...long base64...

• d=example.com is the signing domain. DMARC alignment compares this to the visible From domain.
• s=mail2026 is the selector. It tells the receiver which key to fetch, so one domain can have many keys.
• h= lists the signed headers; From must be among them.
• bh= is the body hash; b= is the signature.

Selectors: naming and where the record goes

The record name is <selector>._domainkey.<signing domain>. Selectors are arbitrary labels. Providers pick their own (google, selector1, s1, k1, and so on) and you can choose your own for self-hosted mail.

mail2026._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Tags: v=DKIM1 (optional but conventional), k=rsa (the default key type), p= (the base64 public key). An empty p= means the key has been revoked.

Many hosted senders ask for a CNAME instead, pointing at a key they host and can rotate for you:

s1._domainkey.example.com.  3600  IN  CNAME  s1.domainkey.u0000000.provider.example.

Both patterns are valid. For a CNAME setup, you cannot also have a TXT record at the same name.

A good habit is a date-based selector (2026a, mail2026) for keys you manage yourself, which makes rotation easy to reason about.

Key length

• 2048-bit RSA is the sensible default today. Verifiers are required to support at least 1024 and 2048 is widely supported.
• 1024-bit still verifies almost everywhere but is considered weak enough that you should upgrade when you next rotate.
• Anything below 1024 should not be used and may be rejected.
• Ed25519 (k=ed25519, RFC 8463) produces much shorter records but receiver support is incomplete, so if you use it, dual-sign with RSA too.

The 255-character DNS string limit

A 2048-bit public key is longer than 255 characters, and a single TXT string is limited to 255. DNS software handles this by splitting the value into multiple quoted strings, which receivers concatenate:

mail2026._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
  "...rest of the key..." )

Most DNS control panels split automatically when you paste the whole value. Some do not, and some break the key by adding spaces, line breaks or smart quotes. If a key shows as invalid, this is the first thing to check.

Publishing and testing

1. Generate the key pair in your mail platform (or with opendkim-genkey -b 2048 -s mail2026 -d example.com).
2. Publish the TXT or CNAME record at <selector>._domainkey.example.com.
3. Query it:

dig +short TXT mail2026._domainkey.example.com

1. Enable signing in the sending system. Many platforms have a separate "start signing" button after the DNS record verifies.
2. Send a test message to the Email Deliverability Test and read the authentication result. You want dkim=pass with header.d=example.com.

You can also use the Email DNS Checker with a selector to confirm the key record is present and well-formed, and the DNS Checker to see whether different resolvers return the same answer while a change propagates.

Why DKIM fails: a diagnostic table

Content modified after signing

This is the most common "mystery" failure. Anything that edits a signed header or the body between the signer and the receiver breaks the hash:

• Gateways that add a legal disclaimer or "[EXTERNAL]" tag to the subject
• Outbound link rewriting or tracking inserted after signing
• Mailing list software that appends a footer or rewrites the subject
• Line-ending or encoding conversion by a relay

The fix is to ensure signing happens last, at the final outbound hop. If you add a footer in a gateway, sign in or after the gateway, not before it. Use c=relaxed/relaxed canonicalization, which tolerates whitespace changes, and avoid the l= body-length tag, which can be abused to append content.

DNS host oddities

• Some panels want only mail2026._domainkey, not the full name. If you enter the full name, the panel may create mail2026._domainkey.example.com.example.com.
• Records added to the wrong zone (for example, while DNS is hosted elsewhere) never resolve. Check which nameservers are authoritative with the DNS Checker.
• TXT records beyond the provider's length limit may be silently truncated.

Multiple systems, one domain

Each sender should use its own selector and key. Never share one private key across vendors. Having ten selectors on a domain is normal.

Rotation

Keys should be rotated periodically and immediately if a private key could have leaked. There is no required interval, but yearly or twice yearly is a common practice. The safe pattern is overlap:

1. Create a new key with a new selector (mail2026b) and publish its record.
2. Wait for DNS to propagate; confirm with dig.
3. Switch the signer to the new selector.
4. Keep the old record published for at least a few days, so messages still in transit or queued can verify.
5. Remove the old record, or publish it with an empty p= to mark it explicitly revoked.

If your provider manages DKIM through CNAMEs, rotation is typically handled on their side, but check their documentation for how and when.

Verifying in message headers

In Gmail choose "Show original"; in Outlook, view message source or headers. Look at the Authentication-Results: line:

Authentication-Results: mx.receiver.example;
 dkim=pass header.i=@example.com header.s=mail2026 header.b=AuzW8e;
 spf=pass smtp.mailfrom=bounce.example.com;
 dmarc=pass (p=REJECT) header.from=example.com

header.d or header.i shows which domain signed, and that is what must align with the header.from domain.

Next steps

• Check your published key with the Email DNS Checker.
• Send a signed test through the Email Deliverability Test.
• Plan enforcement in the DMARC rollout guide.
• Setting up a transactional provider? Use the transactional email DNS checklist.
• If SPF is also failing, review SPF lookup limits.

FAQ

Do I need DKIM if I already have SPF?

Yes. DKIM survives forwarding where SPF often does not, and DKIM alignment is the most dependable way to pass DMARC across many senders.

Can a domain have more than one DKIM record?

Yes. Each selector has its own record, and a domain can have as many selectors as it needs. That is how multiple services and key rotation coexist.

Why does my DKIM record work in a checker but fail at the receiver?

Usually the signature was applied to a message that changed afterward, or the sender signs with a different selector or domain than the one you published. Compare the s= and d= values in a real message header to your DNS.

Is 1024-bit DKIM still acceptable?

It generally verifies, but 2048-bit is the recommended standard. Upgrade at your next rotation.

How long should the old selector stay in DNS after rotation?

Several days is the usual practice, to cover delayed and queued mail. Then remove it or revoke it with an empty p=.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.