When a DKIM key appears in a DNS control panel but verification fails, inspect the answer the verifier actually retrieves. Screenshots can hide a truncated value, a duplicated domain suffix or multiple independent records. The task is to establish the exact owner name and key bytes before changing the signer.
Start from the received signature
Read d= and s= from the affected DKIM-Signature. The lookup name combines them as selector._domainkey.signing-domain. A synthetic message with d=example.com and s=notify therefore uses notify._domainkey.example.com. A key published at notifications._domainkey.example.com will not repair it.
Record the signature's algorithm and the receiver's exact reason. Missing key, malformed key, unsuitable algorithm, signature mismatch and body-hash mismatch are not interchangeable diagnoses. If multiple signatures exist, keep their selectors and outcomes separate.
Reconstruct one TXT record correctly
DNS TXT records can contain multiple character strings. RFC 6376 §3.6.2.2 requires those strings within a single record to be concatenated without added whitespace before use. Splitting a long key across strings in one record differs from creating multiple TXT records, each containing a piece. The latter is not a safe way to publish one DKIM key. Section 3.6.2.2 requires a unique TXT record for the selector and leaves multiple-record results undefined; the verifier choices in section 6.1.2 do not make fragments composable.
Quoted chunks shown by a DNS tool are a presentation of the record. Do not assume display quotes are literal key bytes, and do not remove characters indiscriminately from the DNS interface. Follow its supported entry format, query authoritative DNS and compare the reconstructed value with the generated public value. RFC 1035 §3.3.14 defines the TXT character-string representation.
Inspect for truncation at interface limits, pasted line labels, missing separators and accidental edits to the base64 value. Long records need exact comparison, not visual inspection of the first and last few characters. Preserve the original generated public value for that comparison; never substitute a private-key file.
Validate tags and key material together
Under RFC 6376 §3.6.1, the p= tag carries the public-key data. An empty value means revoked, not a partially completed setup. The k= tag identifies the key type, with RSA as the default in RFC 6376; Ed25519 uses the extension defined by RFC 8463 §4.2. RFC 6376 section 3.6.1 formally marks the key-record v= tag RECOMMENDED, with DKIM1 as the default when it is absent. If included, it must be the first tag and its value must be exactly DKIM1; that value is case-sensitive.
Use a maintained DKIM-aware validator to parse the complete record and confirm that decoded public material is appropriate for the stated key type. Valid base64 alone does not prove that the content is a suitable RSA or Ed25519 public key. Likewise, a syntactically valid record can hold the wrong public key for the active private signer.
Isolate the publication layer from the signing layer
An illustrative failure involves a 2048-bit RSA public key copied into two separate TXT records. Repair the representation to the DNS provider's supported multi-string single-record form, then read back the answer. Do not shorten the key to silence the interface error without reviewing the cause and security implications.
If the correct public key resolves intact but a message still fails, investigate the active selector mapping, matching key pair, algorithm and signed-message changes. Do not keep republishing identical DNS data while the evidence points elsewhere. A provider-managed CNAME should be traced to its final key record; it should not be replaced with a local copy as a generic syntax workaround.
Prove the repair on a fresh message
Record authoritative and recursive results, accounting for cached old or negative answers. Send through the affected application and inspect the trusted recipient's result. Retain the corrected owner name, reconstructed public value or its digest, generated-value comparison and test evidence. A repair is complete when the retrieved key and actual signer agree, not merely when the DNS editor accepts the form.
Check structure without a real key
Illustrative one-record presentation: "v=DKIM1; k=rsa; p=AB" "CD". Concatenation produces v=DKIM1; k=rsa; p=ABCD, with no inserted space between AB and CD. ABCD is deliberately not a valid usable RSA public key; this example demonstrates TXT structure only and must not be published. Two separate records ending in p=AB and containing CD are not equivalent. After reconstructing the real generated value, a DKIM-aware parser must still validate its tags and decoded key material.
Related reading
DKIM TXT and CNAME publishing: follow the provider's key-management model · DKIM key length and algorithms: check current receiver support.