DKIM selector and record mistakes that break signing

Why DKIM fails even when the key itself is correct

RFC 6376 defines DKIM as a two-part system: a private key your mail server uses to sign outgoing messages, and a public key published in DNS that receivers fetch to verify that signature. Most real-world DKIM failures happen not because the cryptography is wrong, but because the receiver can’t find or correctly parse the published public key — a selector or DNS-formatting problem, not a signing problem.

Mistake 1: the wrong or missing selector

The selector is the piece that tells a receiver where to look. It’s published as part of the hostname:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...AQAB"

A signed message’s DKIM-Signature header includes s=google; d=example.com, which a receiver combines into google._domainkey.example.com to fetch the right record. Common ways this breaks:

• Publishing the record at the wrong hostname — a typo in the selector name, or publishing under a default selector when the provider actually signs with a different one.
• Switching mail providers without updating the selector — the old provider’s selector record is left in place (harmless but unused) while the new provider’s selector was never published at all.
• Multiple services, one selector slot filled — if two sending tools are each told to use the same selector name, only one’s key ends up published, and the other’s signatures fail verification even though that service is sending correctly-signed mail.

Mistake 2: a truncated or malformed TXT record

DNS TXT records have a 255-character limit per individual string, but a DKIM public key (especially a 2048-bit RSA key) is often longer than that. The DNS standard allows a single TXT record to be made of multiple quoted strings that get concatenated back together — most DNS hosting providers handle this automatically when you paste a long value in, but manual zone file edits or some control panels can:

• Truncate the value at a fixed length instead of splitting it into multiple strings.
• Insert an unwanted space or line break when splitting, which changes the concatenated value.
• Drop a closing quote, leaving the record syntactically broken.

Any of these produces a public key that doesn’t match the private key actually used to sign — and from the outside, the record can look present and non-empty while still failing every verification.

Mistake 3: key length and algorithm mismatches

RFC 6376 supports multiple signing algorithms (the k= tag, typically rsa); a key generated with one length or format but published or referenced with a mismatched k=/h= tag combination will fail to verify even if every other field looks correct. This is less common day-to-day than selector or truncation issues, but worth checking if a provider’s DKIM setup wizard was interrupted partway through or a key was regenerated without updating every dependent record.

How to test a fix

1. Confirm which selector your provider actually uses — check the sending service’s own DKIM setup page or the s= tag in a DKIM-Signature header from a real sent message (visible in most email clients’ “show original” or “view source” option).
2. Look up the record directly with AdminKit’s DKIM check, entering your domain and that exact selector — it reads the TXT record from DNS and reports whether it parses as a valid DKIM key.
3. Cross-check with a raw DNS lookup using DNS lookup against <selector>._domainkey.<yourdomain> if you want to see the raw TXT value as published, which helps spot a truncation or formatting issue the parsed check might summarize away.
4. Send a real test message once the record checks out, and inspect its headers for dkim=pass from the receiving server, as a final confirmation that signing and publishing now agree.

If you’re setting up SPF, DKIM, and DMARC together for the first time rather than debugging an existing setup, see SPF, DKIM and DMARC explained for how the three fit together before troubleshooting one in isolation.