auth.dkim.unparseable_key
DKIM Key Could Not Be Read
What we check
We decode the public-key data in the p= tag of the DKIM TXT record. If the value can't be decoded as a valid base64 key, verifiers can't check signatures against it and the key's strength can't be assessed.
What this finding means
A DKIM record exists, but its p= value doesn't parse as a valid public key. This is different from a missing key (nothing published) and from a revoked key (an intentionally empty p=) — here something is published, but it's corrupted or malformed.
The usual cause is a key that was truncated or mangled when it was pasted into DNS: a 2048-bit key spans more than 255 characters and must be split across concatenated strings, and a control panel that mishandles that split leaves a broken value.
Why it matters
- Signatures can't verify. A key that won't decode is as good as no key for verification — mail signed against it fails DKIM at the receiver.
- Hides the real state. Because the record looks present, the problem is easy to miss; it takes decoding the value to see it's broken.
- DMARC impact. No verifiable DKIM signature means no DKIM alignment. If SPF alignment is also missing, DMARC fails.
How to fix
Re-publish the key cleanly. Copy the full public key from your signer or provider and paste it exactly, letting the DNS panel split long values into concatenated strings correctly:
selector1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...rest of the base64 key..." )Verify it decodes. After publishing, confirm the
p=value reassembles to a valid key and that a test message's signature verifies.
How it's graded
An unparseable DKIM key carries a 10-point deduction in the Authentication category. See Grading Methodology for the full scoring model.
Evidence example
$ dig +short TXT selector1._domainkey.example.com | tr -d '"'
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF ← truncated: base64 does not decode to a key