DKIM Key Too Short (Published Material Truncated or Incomplete)

Validators raise “key too short” when the decoded RSA modulus is smaller than expected—or when they cannot read enough bits because the published TXT was clipped. Registrar panels occasionally cap per-string length; hurried admins publish only the first fragment of a multi-part base64 blob. Another scenario: migrating keys, uploading the new p= text, but the UI silently truncated trailing characters. The outcome matches a weak key even if you intended 2048-bit material. This page covers publication integrity; pair it with broader cryptographic rotation guidance when you are intentionally upgrading bit strength. Many issues come down to a missing DKIM record or a selector mismatch in DNS.

Updated for 2026 to reflect current Gmail, Outlook, and Yahoo behavior.

If signatures fail, check the DKIM selector troubleshooting guide.

Learn the bigger picture in our Email Authentication Explained guide and compare SPF vs DKIM vs DMARC to understand how these protocols work together.

Quick answer

Full RSA 2048 public keys often exceed 256 characters and need multiple TXT chunks.
Order of concatenation matters for oversized records.
Some APIs report ‘short’ when base64 padding was dropped.
Truncation after rotation looks like a passive attack fingerprint—filters react harshly.

One-Minute Fix

Re-export the key, verify the complete base64 length against the vendor checksum if provided, republish using your DNS provider’s recommended chunked TXT workflow, and query with `dig TXT` to ensure the recombined string equals the source string character for character.

Compare published vs source length

Plain text

Source file line length: N characters
dig TXT selector._domainkey.domain | wc -c   → should match N + DNS framing

If counts diverge, you are still truncating or splitting incorrectly.

Run free check

Free live DNS check. No signup required.

Wrong vs correct setup

Wrong setup

DNS TXT

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Ellipsis placeholders or human-trimmed samples in live DNS are invalid and yield effectively short keys.

Correct setup

DNS TXT

Two TXT strings on the same name that concatenate to the full p= without omissions.

Every base64 character from the signer’s export appears in DNS, rebuilt in order by resolvers.

Why truncation mimics weak crypto

Cryptographic routines attempt to parse whatever bits arrive. Incomplete moduli decode into smaller integers—indistinguishable in logs from deliberately tiny keys—so receivers refuse or downgrade accordingly. In practice it usually traces back to a missing selector or an invalid DKIM key in DNS.

Operational symptoms

Intermittent DKIM pass if older full record still cached in one region.
Security scanners flag mismatched key lengths between rotations.
Alignment gaps when only some mail paths hit stale full records.
Helpdesk confusion between ‘too short’ crypto policy vs literal truncation.

Deliverability angle

Even a perfect sending reputation cannot compensate if DKIM material never fully propagates—chunks of mail fail outright until DNS integrity restores. Providers tend to trust domains with a stable DKIM record and clean DKIM signatures far more than those with intermittent failures.

Common causes

DNS UI pasting limits without multi-string support.
Accidental use of ellipsis or Markdown from internal wikis.
Automated sync jobs that strip trailing `=` padding bytes.
Parallel edits where two admins publish halves of different rotations.

What we checked

We fetch DKIM TXT and measure whether the published key material matches plausible key sizes after decoding. Structural truncation surfaces here in addition to RSA bit-count heuristics.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

How is this different from upgrading 1024 → 2048?

Upgrading is a deliberate cryptographic choice. Truncation is a delivery defect—you must fix DNS fidelity first, then evaluate bit strength.

Does Route53 / Cloudflare chunk automatically?

They split strings but you must verify merged output via dig, not only the UI preview.

Will doubling selectors help?

Staged selectors help rotation, but truncated TXT breaks every selector until length is corrected.

Next steps

Capture a canonical export file from the signer and treat it as the single source of truth.
Republish with verified chunking; flush local caches.
Compare decoded modulus bit length using openssl or your ESP tooling.
Send traffic only after two independent DNS vantage points agree.
Document chunk layout for future rotations.
Review the full troubleshooting guidance in the DKIM Hub.
Explore sender authorization issues in the SPF Hub.
Review alignment and policy issues in the DMARC Hub.