What causes invalid RSA public key errors in DKIM records and how can I fix it?
Updated on 5 Oct 2026: We corrected the RSA key format advice and added DNS and local key checks to help diagnose invalid DKIM public keys.
An invalid RSA public key error in a DKIM record means the value inside the p= tag cannot be decoded and parsed as the required RSA public key. The usual cause is a damaged DNS value: one missing character, one extra quote, literal zone-file syntax, a truncated paste, or a DNS migration that changed the long TXT value.
The fix is direct. Get the original DKIM public key from the system that signs mail for the domain, republish that exact value at the selector hostname, wait for DNS to update, then test a real message. Do not rotate every key immediately when this error appears. First compare the published p= value against the expected key, because a one-character paste error is enough to break validation.
What the error means
DKIM works by placing a signature in the message header and publishing the matching public key in DNS. The receiver reads the selector s= and signing domain d= from the DKIM-Signature header, looks up the TXT record at selector._domainkey.example.com, then decodes the public key in the p= tag. If the receiver cannot decode and parse that public key, it cannot verify the signature.
A message such as bad base64 decode means the public key failed decoding before the receiver could verify the message signature. It does not diagnose a change to the signed message body.
Fast diagnosis
Remove permitted whitespace before checking the p= value. A non-Base64 character or a character count with remainder 1 when divided by 4 proves the text cannot decode as Base64. Other lengths can be valid when padding is omitted, so always decode and parse the result instead of judging by length alone.
This is different from a DKIM signature mismatch. With a mismatch, the DNS public key is readable, but the signature does not match the signed headers or body. An old but readable key that does not match the signing private key also causes a signature mismatch. A wrong selector can instead produce a no-key error.
An empty p= value has a separate meaning: it revokes that selector. A receiver should treat signatures that reference the revoked key as an error, but the record is not a malformed Base64 key.
Invalid public key
- Failure point: The DNS value cannot be decoded into a usable RSA public key.
- Usual cause: The long TXT value was truncated, altered, wrapped incorrectly, or encoded in the wrong key format.
- Best fix: Replace the entire public key with the original value from the signing system.
Signature mismatch
- Failure point: The key loads, but the message signature does not validate.
- Usual cause: Signed content changed in transit, or DNS contains a readable key that does not match the signing private key.
- Best fix: Compare the public key with the active signer and inspect the final message after all modifications.
Common causes of invalid DKIM public keys
Compare the published DNS value with the signing system's source record first. DKIM public keys are long, and DNS control panels display long TXT records in different ways. A record that was valid in the old DNS interface can be broken when someone copies the displayed value into a new provider.
- Missing character: A single lost character in the middle of p= makes the Base64 string invalid or changes the decoded bytes.
- Truncated paste: The DNS form accepts only part of the value, or the operator copies only one visible segment.
- Literal zone syntax or copied quotes: A web DNS form stores parentheses, backslashes, or quote marks that belonged to a zone-file presentation.
- Wrong key encoding: The p= value is valid Base64 but contains an OpenSSH key, a certificate, or another structure instead of a usable RSA public key.
DKIM public key sanity checks
Quick signals that help separate a damaged key from a normal DKIM TXT record.
Length mod 4 = 1
Bad
Invalid after permitted whitespace is removed.
Quoted chunks
Check
Normal in zone-file format if DNS joins them correctly.
1024-bit RSA key
Minimum
RFC 8301 minimum for signing, but 2048 bits is recommended.
2048-bit RSA key
Preferred
Recommended RSA choice when DNS publishes every character correctly.
DNS provider limits are another common source of confusion. One DNS TXT character-string can contain up to 255 octets, but a TXT record can contain multiple strings. DKIM requires those strings to be joined with no added whitespace before the record is used. If a provider stores the chunks incorrectly, or if someone copies the visible chunks into another provider with quote marks and separators included, DKIM breaks. This related guide on DNS TXT limits goes deeper into that specific failure mode.
Whitespace allowed by DKIM's folding whitespace syntax is different from literal escape sequences or unsupported characters. Spaces and tabs are permitted inside p=; a CRLF must be followed by a space or tab. Avoid pasting bare line breaks, non-breaking spaces, or smart quotes into the key.
Check the RSA key encoding
Base64 validity is only the first layer. A p= value can decode successfully and still trigger an invalid RSA public key error because the decoded bytes use the wrong structure. For k=rsa, RFC 6376 names a DER-encoded PKCS#1 RSAPublicKey, but its Appendix C example publishes SubjectPublicKeyInfo (SPKI). Reported RFC 6376 errata describe this inconsistency; they are not an approved standards change. Do not reject a signer-generated RSA key solely because it uses SPKI.
- Signer-generated DKIM value: Use this complete record whenever it is available because it has the key format generated by that signing system.
- OpenSSH or SSH2 key: A value beginning with ssh-rsa AAAAB3 uses an SSH-specific structure and does not belong in a DKIM p= tag.
- PEM public key: Do not paste the BEGIN and END lines. A BEGIN PUBLIC KEY file normally wraps SPKI, which is widely used for RSA DKIM. Use the signing system's documented DNS export.
- Certificate or private key: Neither belongs in DNS. If private key material was published, replace the key pair, move to a new selector, and revoke the exposed selector.
Key wrappers that must not appear in p=text
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... -----END PUBLIC KEY-----
Removing PEM headers does not convert the bytes inside to a different ASN.1 structure. SPKI itself is not proof of a broken key. If the signing system cannot export a DKIM-ready TXT value, use its documented public-key export format and confirm that the RSA modulus matches the private key used for signing.
Use the signing system as the source
Do not choose a key format by how the Base64 prefix looks. Retrieve the DKIM DNS value generated for the active selector, or create a new selector and key pair when that source value is unavailable.
Check the algorithm before applying RSA diagnostics. A signature using a=ed25519-sha256 needs a k=ed25519 record containing a raw Ed25519 public key, not an RSA key. This key type is defined in RFC 8463.
How to fix an invalid RSA public key
Fix the record by replacing the whole public key. Do not try to guess the missing character. Do not paste around the broken part. A DKIM public key is generated by the signing system, and the public DNS record must match that generated value exactly.
- Find selector: Open a failing message and read the s= and d= values in the DKIM signature. The lookup name is s._domainkey.d. Do not substitute the visible From domain for d=.
- Get source key: Copy the public key from the mail platform, MTA, or signing service that owns that selector.
- Replace record: Update the TXT record at the exact selector hostname and paste the complete value. If the sender requires a CNAME, preserve that alias and check the TXT record at its target; do not add TXT alongside the CNAME.
- Preserve value: Use the provider's TXT field format, but keep the actual key characters unchanged.
- Retest mail: Confirm DNS returns the repaired value, then send a new message and inspect the receiving server's authentication result.
Valid split DKIM TXT record exampledns
selector1._domainkey.example.com. 300 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11JrgESgQrNusxgvN5BPllMehZnUVZRflQbDJFZqQb+Qq41SZq5BDZif1evF43h1Ywron8VqqfgA9hTzucLUuX5xyRrN04kokxhGe1U7R41alzBHxDhhRSM3CvxsmLyL7hhgee+XOZDwm+omtiTddwZUq22e" "tsQJnEXboLqEBmmBqvWK2meUUouU3lJ/gJRBd8m1AF9mFVeiCXJgVNe//57kAyrA/xMgZLA9h1vQwkZmSU8ll8X3ukCgraLjYyso56BDvhEPPNyc7GsAsqvMNkAismrmVUXdsCuQCTZP82F+ZfYRWLRgwFUpdqxePSJgdVrbzjqqyEgGHBYMGWKZPQIDAQAB" )
The quoted split above is normal zone-file presentation. DNS does not return the quote marks as part of the key, and DKIM joins the strings without spaces. The example contains a complete 2048-bit RSA public key for demonstration; publish your own signer's key. In many web DNS panels, the right input is a single TXT value, not a zone-file style block. That mismatch is where many DKIM records get damaged.
Do not drop to a 1024-bit key solely because a DNS form rejects a 2048-bit value. RFC 8301 requires at least 1024 bits for RSA signing and recommends at least 2048 bits; receivers must reject signatures using RSA keys below 1024 bits. First confirm the panel's split-string syntax or move authoritative DNS to a provider that can publish the full TXT record correctly.
Do not patch the key manually
If one character is missing, adding a random Base64 character only creates a different invalid or wrong key. The correct repair is to retrieve the original public key or generate a new key pair and publish the new public key.
If the signing system no longer shows the old key, generate a new DKIM key pair, publish and validate the new public key, then switch the sender to the new selector. Keep the old public key available until no sender uses it and queued messages signed with it have cleared. If the old private key was exposed, revoke its selector instead of retaining an overlap.
Query DNS and parse the RSA public key locally
Use the failing message's selector and signing domain in these commands. Replace the example hostname and ns1.example.net with your actual selector hostname and authoritative nameserver. The dig documentation explains the answer and recursion options.
Compare resolver and authoritative DNS answersbash
dig TXT selector1._domainkey.example.com +noall +answer dig CNAME selector1._domainkey.example.com +short dig NS example.com +short dig @ns1.example.net TXT selector1._domainkey.example.com +norecurse +noall +answer
Quoted chunks in one TXT record are joined without separators. Separate TXT records must not be joined into one key. Follow any CNAME to the target TXT record. If authoritative DNS has the repaired key but the resolver still returns the old value, retest after the cached record's remaining TTL expires. A newly created selector also needs cached no-record responses to expire.
Copy only the concatenated Base64 value after p= into dkim-public-key.b64, excluding other tags and display quotes. Decode it and ask OpenSSL to load an RSA public key using the options in the OpenSSL RSA documentation.
Decode and inspect the published RSA public keybash
tr -d ' \t\r\n' < dkim-public-key.b64 | openssl base64 -d -A > dkim-public-key.der openssl rsa -pubin -inform DER -in dkim-public-key.der -text -noout
A readable RSA key displays its bit length, modulus, and exponent. A decoding or loading failure directs you back to the source key and published value. Successful loading does not prove the DKIM tags are valid or that the key matches the active signer. If only one receiver still reports an invalid key, compare its DNS answer and verifier logs before replacing keys again.
Validate the key before changing more DNS
After republishing the record, validate the selector itself before touching DMARC policy or sender configuration. A clean key lookup tells you that the DNS value can be decoded and parsed. It does not prove every outbound message is signed correctly, but it removes the public key as the failure point.
Suped's DKIM checker tests the selector and domain without waiting for a new campaign or automated send. If the selector passes but messages still fail, move to message-level troubleshooting.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the checker says the selector has no record, verify the hostname. A DKIM TXT record lives under _domainkey, and a single missing label changes the lookup entirely. Some DNS panels append the zone name automatically, so check that a full hostname has not become selector._domainkey.example.com.example.com. The troubleshooting path for a no DKIM record error is related, but the fix is different because DNS lookup fails before key parsing starts.
DKIM troubleshooting flowchart for selector lookup, RSA public key decoding, DNS replacement, and email retesting.
Once the selector validates, send a fresh test message and inspect the receiving server's Authentication-Results header for dkim=pass. Confirm that the signing domain is the one expected. DMARC requires a passing SPF or DKIM result whose authenticated domain matches the visible From domain under the configured domain matching mode. DMARC can pass through SPF while DKIM still fails. A valid key does not fix unsigned mail, wrong signing domains, body hash failures, or forwarding changes.
What to check in the DNS record
The DKIM TXT record is a tag-value list. The public key sits in p=, and the rest of the record gives receivers context. Most broken RSA public key errors come down to the p= tag, but check the whole TXT value because surrounding syntax can hide the real mistake.
|
|
|
|---|---|---|
Version | v=DKIM1 first if present, or omitted | Wrong value or position |
Type | k=rsa or omitted for RSA | Type and signature algorithm disagree |
Key | p= with a complete usable public key | Missing or damaged; an empty value revokes the key |
Host | s._domainkey.d | Wrong selector or signing domain |
Tag names | Each tag appears once | Repeated tags invalidate the tag list |
Compact DKIM TXT record checks.
Multiple quoted strings within one TXT record are normal; multiple TXT records at the same selector are different. RFC 6376 requires a unique TXT record for each selector and leaves results undefined when multiple records exist. Keep one complete current key record at each selector hostname; use separate selectors for key rotation.
Broken DKIM TXT record patterns, keys shortenedtext
v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQAB" v=DKIM1; k=rsa; p=MIIBIjAN*BgkqhkiG9...IDAQAB v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9...IDAQA
Those examples illustrate an extra quote, an illegal Base64 character, and a truncated ending. The ellipses shorten the examples and are not valid key characters. Confirm truncation against the source key, not an expected suffix. The exact visible error varies by validator, but the repair remains the same: replace the key with the clean source value.
Prevent the same failure
The best prevention is to stop treating DKIM TXT records as casual copy-paste text. Long keys need a repeatable change process, especially when moving DNS providers or rotating keys across many domains.
- Store source: Keep the generated DKIM record from the signing platform in a controlled ticket or change log.
- Copy raw: Copy from the provider's raw record value, not a wrapped display view.
- Avoid editors: Do not use word processors or editors that auto-wrap, quote, or reformat text.
- Test selector: Validate the selector immediately after DNS changes and again after propagation.
- Monitor mail: Watch real authentication results after the DNS record looks valid.
Suped is our DMARC and email authentication platform. Teams can use it to identify sending sources in aggregate DMARC data, track DKIM and SPF failure rates, check authentication records, and receive alerts when results change. That workflow connects a repaired selector to the real mail that uses it instead of stopping at a one-off DNS lookup.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
After the repair, compare the affected source's DKIM results in Suped's aggregate reports. Those reports summarize activity and arrive after the reporting interval; they do not identify the exact malformed character in a DNS key. Confirm the immediate repair with DNS and a fresh test message, then watch subsequent reports for recurring failures.
Run a domain health checker after the DKIM record passes for a broader DNS and authentication check. Ongoing DMARC monitoring tracks authentication results by sending source, including failures that a single selector lookup cannot diagnose.
Views from the trenches
Best practices
Compare the DNS key against the source key before rotating selectors or changing mail flow.
Validate the selector after every DNS migration, especially when records were copied manually.
Keep DKIM record copies in change tickets so later DNS edits can be checked byte for byte.
Send a fresh test message after DNS passes because message signing can still fail later.
Common pitfalls
Copying wrapped TXT records between DNS panels can insert literal quotes or escape sequences.
Fixing only the visible error often misses a wrong selector or stale key at the same host.
Assuming a valid DNS lookup proves DKIM passes skips the need to test a real message.
Letting old selectors linger without notes makes future key comparisons slower and risky.
Expert tips
Treat a modulo-four remainder of one as invalid Base64 and fetch the source value again.
Use a new selector when the original key source is gone, then monitor both during overlap.
Check for multiple TXT records at the selector before chasing message-level DKIM failures.
During DNS moves, export raw zone data and avoid copying from formatted browser displays.
Marketer view
Marketer from Email Geeks says bad base64 decode usually means the DKIM public key was malformed before any message signature check happened.
2024-01-26 - Email Geeks
Marketer view
Marketer from Email Geeks says a Base64 length that leaves remainder one is a strong clue that a character was lost during copying.
2024-01-26 - Email Geeks
Frequently asked questions
No. It means the public key published in DNS cannot be decoded or parsed as the expected RSA key. Treat it as a DNS publishing or key-format problem first. If private key material was actually published in DNS, replace the key pair and revoke the exposed selector.
No. Fetch the original public key from the signing system or create a new key pair. Guessing does not reliably recover the original key, even if the text becomes valid Base64.
Long TXT records are easy to copy incorrectly. A DNS panel can show split quoted chunks, and copying that display into another provider can insert quote marks, separators, or missing characters.
A 2048-bit key is longer, so copy and DNS field mistakes are more common. The key length itself is not the problem when the provider stores and returns the complete TXT value correctly.
DKIM public key records have no protocol-level expiration date, although a message signature can expire through its x= tag. Rotate keys on an operational security schedule, use a new selector for each new key pair, and keep the old public key published until messages signed with it no longer need verification, unless the private key was exposed.
Test the selector lookup first, then send a fresh message and inspect the receiver's Authentication-Results header for dkim=pass, the expected signing domain, and the DMARC result. DMARC can pass through SPF even while DKIM fails, so confirm DKIM separately.
