DKIM "no key for signature" after switching to a 2048-bit key: the TXT record is probably cut off

You generated a new DKIM key, published the TXT record, and the receiver says one of these:

dkim=fail (no key for signature)
dkim=permerror (bad key)
dkim=neutral (key not found / DNS lookup failure)

Before blaming the mail server, look at what DNS is actually serving.

Why 2048-bit keys break

A 2048-bit public key in base64 is around 390 characters, plus v=DKIM1; k=rsa; p=. A single DNS TXT string can hold at most 255 bytes, so a longer value has to be published as several quoted strings in one record. Resolvers join them back together with no separator. Some DNS editors split the value for you, some do not, and some silently truncate at 255 characters. A truncated key still looks like a perfectly normal record, which is why this takes people hours.

Check what is published

dig +short TXT selector1._domainkey.example.com

A healthy long record comes back as quoted chunks, like "v=DKIM1; k=rsa; p=MIIBIjANBg..." "...AQAB". Warning signs:

• The value ends abruptly, and the last characters are not IDAQAB (the usual end of an RSA public key).
• There are spaces or line breaks inside p=. Whitespace in the key makes it invalid in some validators.
• Smart quotes or a trailing ; pasted from a document or chat.
• The record exists under the wrong name: the host should be <selector>._domainkey, and some panels append your domain automatically so you end up with selector._domainkey.example.com.example.com.

Compare the p= value to the one your mail provider shows, character for character. A quick way: ask the provider's own "check DKIM" button, then confirm with dig from a public resolver such as 1.1.1.1 so you are not reading your own cache.

Fix

1. If your DNS panel shows a character limit, or the value cuts at 255, enter it as two quoted strings: the first 255 characters, a closing quote, a space, an opening quote, and the rest. Cloud DNS APIs and zone-file editors accept this directly.
2. If the panel will not take it at all, you can fall back to a 1024-bit key. Weaker, but a working 1024-bit key beats a broken 2048-bit one. Plan to move to 2048 once your DNS host can store it.
3. Wait for the old TTL to expire before testing; a negative answer can be cached.
4. Send a test message to a mailbox you control and read the Authentication-Results header for dkim=pass header.d=yourdomain.com.

Rotation is where this bites

The key usually breaks on the day somebody rotates it, not on the day it is first set up, and the first sign is mail landing in spam on one provider. If you rotate keys, publish the new selector first, verify it, and only then switch signing. Keep the old one for a few days so in-flight mail still validates.

What to take from this

DKIM can be correct on setup day and broken after a rotation, a DNS migration or a vendor change. The record being present is not the same as the record being valid. Re-check it on a schedule, and after any change to DNS or to the tools that send as your domain.

If you want a live check of your own SPF, DKIM and DMARC, Email Fix Pack has a free scanner (disclosure: I made it).