DKIM Key Too Short — 1024-bit Signature Flagged or Rejected

What’s actually happening

Mail that passed DKIM for years starts coming back as dkim=neutral or dkim=fail at some providers but not others. Because DMARC can still pass on SPF alignment, you may not notice until placement slips or a report flags it. The signature is structurally valid — the algorithm and selector are fine — the key length is the complaint. It often reads as intermittent because different receivers tightened their minimums at different times.

Common causes

• The DKIM key was generated at 1024-bit RSA, which NIST has deprecated and a growing number of mailbox providers now reject or downgrade to neutral.
• The published TXT record was split across multiple strings during key generation and reassembled wrong, so the public key is truncated and the body hash can't verify.
• DNS provider silently chopped the long p= value at the 255-character per-string boundary without re-quoting it as multiple strings, corrupting the key.
• An old selector with a short key is still being used to sign while a newer 2048-bit selector sits published but unused.
• Key rotation regenerated the private key but the matching public TXT record was never updated, so signatures fail against the stale published key.

How to fix it

1. Regenerate the key at 2048-bitCreate a new 2048-bit RSA DKIM key pair (opendkim-genkey -b 2048 -s selector2026 -d example.com or your ESP's key generator). Use a fresh selector name so you can cut over without breaking in-flight mail signed by the old key.
2. Publish the public key, split correctlyA 2048-bit public key exceeds the 255-char per-string TXT limit. It must be published as multiple quoted strings inside one record — "v=DKIM1; k=rsa; p=MIIBIj..." "...AQAB" — concatenated by the resolver, not as separate records. Many DNS panels handle this automatically; verify the panel didn't break it.
3. Verify the published key resolves intactRun dig TXT selector2026._domainkey.example.com +short and confirm the p= value reassembles to the full key without gaps. Paste it into a DKIM record checker. A truncated key produces the same dkim=neutral 'body hash did not verify' you were trying to fix.
4. Switch signing to the new selector, then retire the oldPoint your MTA or ESP at the new 2048-bit selector. Send test mail, confirm dkim=pass at Gmail and Outlook, and leave the old selector's TXT record published for a few days so already-queued messages still verify. Then remove it.