Why is my CPanel DKIM record failing validation?
Published 26 May 2025
Updated 6 Oct 2026
12 min read
Summarize with
Updated on 6 Oct 2026: We updated our cPanel DKIM troubleshooting steps for DNS formatting, key mismatches after migrations, and message verification.
Your cPanel DKIM record usually fails validation because the TXT record in authoritative public DNS does not match the DKIM key that cPanel generated. Common causes include external DNS that was never updated, a split TXT record copied incorrectly, extra quote characters inside the key, a DNS host altering long TXT strings, the wrong selector being checked, or cPanel signing being disabled after its own validation failed.
The confusing part is that cPanel can look normal and still produce a failing result outside cPanel. Treat the public DNS answer as the source of truth, not the zone editor screen. A record containing v=DKIM1 and a non-empty p= value still needs valid tag syntax and a decodable RSA public key. Literal quotes or backslashes in the returned data, conflicting TXT records, or a truncated key can cause validation failure. A readable public key must also match the private key used to sign the message.
Two fields in cPanel are not automatically wrong. DNS TXT records are made of character-strings, and each string holds up to 255 octets. Long DKIM keys are often stored as multiple strings inside one TXT record, then joined by DKIM validators before parsing.
Check the cPanel DKIM selector
When cPanel DKIM fails after the Email Deliverability page says the record is valid, check the exact TXT answer for default._domainkey at the authoritative nameservers. cPanel usually uses default as the selector, so the record name is default._domainkey.example.com. Replace the domain with your real domain when testing.
- Split TXT: Multiple chunks inside one TXT record are normal. Publishing different DKIM keys as separate TXT records at the same selector creates an ambiguous lookup.
- Bad quotes: Quotes that wrap DNS strings are fine. Quote characters embedded inside the DKIM key corrupt the key.
- Wrong DNS: The record can look right in cPanel but fail if the domain uses another authoritative DNS provider.
- No signature: If cPanel stops signing after validation fails, the message has no DKIM-Signature header. Receivers generally report dkim=none for unsigned mail, rather than a failed signature.
For a quick check, paste the selector and domain into Suped's DKIM checker. If you want SPF, DKIM, and DMARC checked together, run the domain health checker after you make the DNS change.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
When cPanel cannot repair the record
cPanel's Repair option can update a DKIM record only when the cPanel server controls the domain's authoritative DNS. If the option is unavailable or cPanel says the system does not control DNS, installing the suggested record locally does not change the answer that receivers query. Publish the suggested Name and Value at the authoritative DNS host instead. If Email Deliverability is missing entirely, ask your hosting provider to enable it in WHM's Feature Manager.
- Open the domain: Go to Email Deliverability, select Manage, and compare the current record with the Suggested DKIM (TXT) Record.
- Choose the right view: Use Full when the DNS host automatically splits long values. Use Split when it requires 255-character strings.
- Publish externally: Copy the suggested host and value into the DNS service named by the domain's NS records. If the host automatically appends example.com, enter default._domainkey rather than default._domainkey.example.com to avoid publishing at default._domainkey.example.com.example.com. Keep the chunks in one TXT record.
- Recheck DNS and caches: Query every authoritative nameserver as soon as the edit is published, then check a recursive resolver. Old answers and no-record responses remain cached until their existing TTL expires; lowering the TTL after the edit does not clear them.
Do not generate a new local DKIM key merely because external DNS is stale. Regenerating the key changes the expected public value and can create another mismatch. First publish the Suggested DKIM value that matches the key cPanel will use for signing. Publish only the public TXT value, never the private key.
Why the split field is normal
DKIM public keys are long, especially 2048-bit RSA keys. A DNS TXT record handles that by storing several quoted strings under the same record. DKIM validators concatenate those strings without adding anything between them. The chunks must remain in one TXT record and preserve all the public key's base64 data.
Healthy split
- One answer: The selector returns one TXT record, even if that record has several quoted strings.
- Clean key: cPanel's suggested value starts with v=DKIM1 and contains one complete public key. The version tag is recommended, but its absence alone does not invalidate a DKIM key record.
- Intact data: Joining the strings preserves every base64 character without introducing literal quotes or backslashes.
Broken split
- Two records: The same selector returns two separate TXT records instead of one split TXT record.
- Literal quotes: The public key contains quote marks that became part of the value.
- DNS rewrite: A DNS service rewrites, truncates, escapes, or drops a long TXT string.
Split TXT syntax example, placeholder key onlydns
default._domainkey TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq" "hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvpartone" "parttwoIDAQAB" )
Broken TXT syntax with literal quotesdns
default._domainkey TXT ( "\"v=DKIM1; k=rsa; p=MIIBIjAN" "BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA\"" )
The first example illustrates DNS string syntax only; its shortened placeholder key is not usable for signing. The second example stores literal quote characters in the returned value, which breaks DKIM tag or key parsing. A trailing semicolon is a valid tag separator, and +, /, and = are valid base64 characters. Do not remove them from the copied key. An empty p= value is also invalid for active signing because it means the key has been revoked. For a deeper version of the length failure mode, see the explanation of TXT length limits.
RFC 6376 permits folding whitespace within the base64 key data. Spaces between quoted strings in a DNS display are not stored in the TXT value, so whitespace alone is not proof of corruption. Keep cPanel's copied value intact and investigate literal quotes, missing key characters, or separate TXT records instead.
Compare cPanel with authoritative DNS
cPanel Email Deliverability showing DKIM validation status and the default._domainkey TXT record.
Start outside the interface. cPanel can only validate what it sees through its own DNS path. Mail receivers and public checkers use public DNS, often through a different resolver. The fastest way to avoid guessing is to query the authoritative nameservers directly and compare that answer to the value cPanel generated.
- Find selector: Start with cPanel's suggested record, then confirm the actual selector in s= and signing domain in d= on a message's DKIM-Signature header. A modified Exim configuration or external relay can use a different selector.
- Find DNS: Check the domain's authoritative nameservers, not only the DNS zone shown inside cPanel.
- Query TXT: Ask each authoritative nameserver for the selector record and compare the returned value.
- Send mail: After DNS validates, send a real message and inspect the Authentication-Results header.
Command-line DNS checksbash
dig NS example.com +short dig TXT default._domainkey.example.com +noall +comments +answer +authority dig @ns1.example.net TXT default._domainkey.example.com +norecurse +noall +comments +answer +authority
If authoritative servers return different DKIM values, ask the DNS host to repair zone replication. If all return a malformed key, republish cPanel's clean value. A blank +short result does not distinguish a missing record from a DNS error. NXDOMAIN means the queried name does not exist; NOERROR with no TXT answer means no TXT record was returned. SERVFAIL or a timeout needs DNS troubleshooting, including DNSSEC where enabled. For a confirmed missing TXT record, use the no DKIM record troubleshooting path. If the direct authoritative answer is correct but a cached resolver still has the old value or no answer, wait for that cached TTL to expire before judging the change.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Common cPanel DKIM failure causes
Most cPanel DKIM validation failures fall into a small set of causes. The fix depends on whether the DNS record is malformed, missing, duplicated, revoked, or correct but unused by the mail server.
|
|
|
|---|---|---|
Invalid key | Literal quotes or truncated base64 | Republish cPanel's complete TXT value |
No TXT record | Wrong DNS host or record name | Publish at the authoritative DNS host |
Empty p= | Revoked key | Publish active key |
Multiple DKIM keys at one selector | Conflicting TXT records | Keep the key used by the active signer |
Record passes, message unsigned | Signing disabled or wrong sending path | Check cPanel or Exim signing |
Intermittent | DNS mismatch | Fix nameservers |
Record passes, signature fails | Private/public key mismatch or changed message | Compare the active key and inspect the sending path |
Quick mapping for cPanel DKIM validation symptoms.
A 2048-bit key is not the problem by itself. The problem is a DNS system or copy process that cannot preserve the 2048-bit key correctly. RFC 8301 recommends RSA keys of at least 2048 bits. Fix TXT handling or change the DNS host instead of shortening the key. cPanel's key length guidance says the 1024-bit workaround is unsupported and is no longer an option on Enterprise Linux 8 or later.
The cPanel verification instructions check the DKIM record through Email Deliverability. If that check detects an invalid key, cPanel stops signing outbound mail for the domain until the DNS record is corrected. That produces unsigned mail rather than a signature that fails verification.
How to fix it safely
The safest repair is to replace the DNS record with a clean DKIM value, then verify both the DNS key and an actual sent message. Do not edit the base64 key by hand. A missing key character or a literal quote can break validation.
- Copy cleanly: Copy the DKIM value from cPanel Email Deliverability. Choose Full or Split to match how the authoritative DNS host accepts long TXT values.
- Paste raw: In a DNS UI, paste the value field only and follow the host's Full or Split input format. Keep the hostname, TTL, and TXT label out of the value; do not paste zone-file quotes into a field that expects raw text.
- Remove extras: At the selector being repaired, keep only the correct DKIM TXT record. Preserve different selectors used by other active senders.
- Verify public: Check every authoritative nameserver after the change, allow cached answers to expire, then send a real email and inspect the message headers.
cPanel DKIM troubleshooting flow through DNS publication, message signing, and receiver verification.
The message test matters because a valid DNS record only proves the public key is readable. It does not prove cPanel signed the message, that the message used the same domain in the DKIM signature, or that another system did not alter the message after signing.
Header fields to inspecttext
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=default DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default; c=relaxed/relaxed;
Check for a changed or mismatched DKIM key
If validation started failing after a server migration or DKIM key regeneration, compare the current Suggested DKIM value with authoritative DNS. A new private key requires a matching public key. External DNS does not automatically follow local key changes, so an old public key can remain syntactically valid while failing to verify new signatures.
- Compare the complete p= data from the active cPanel server with DNS after joining TXT strings and ignoring permitted folding whitespace. Similar starting characters do not prove that two RSA keys match.
- If a migration preserved the original key pair, keep its matching DNS record. If the active server has a different key, publish that server's suggested public value and allow cached answers to expire.
- If two servers send with the same d= domain and s=default but use different keys, publishing both keys at default._domainkey does not fix the conflict. Ask the hosting administrator to coordinate signing keys or configure distinct selectors.
- After the repair, send new messages through each active sending path. Messages signed with an old private key still need the corresponding old public key to verify.
Monitor cPanel DKIM after the repair
A one-time DKIM lookup tells you whether the selector is valid at that moment. Ongoing monitoring shows which sources are sending with the domain, whether DKIM and SPF pass on real mail, and whether those authenticated domains match the visible From domain for DMARC.
Suped is our DMARC and email authentication platform. After repairing the cPanel record, use Suped to identify cPanel traffic by sending IP in aggregate reports, confirm DKIM pass and DMARC alignment, and watch for failures after a DNS migration or key change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC monitoring helps you review whether reported cPanel traffic continues to authenticate after the validation error is cleared. Aggregate reports cover mail seen by reporting receivers, so continue to test each sending path directly.
When DNS passes but DKIM still fails
A clean TXT answer does not prove that the message was signed. Send mail through the same cPanel account and application that produced the failure, then check for a DKIM-Signature header. If the header is missing, inspect cPanel or Exim signing and confirm that the sending process is attributed to the correct cPanel account. Some PHP application configurations send as a shared system user, so cPanel cannot select the domain's key. Ask the hosting administrator to check the PHP handler and Exim configuration, or send the application mail through authenticated SMTP for the correct account.
If mail leaves through an external relay instead of the local cPanel mail server, configure and test the selector used by that relay rather than expecting a cPanel signature. If the DKIM-Signature header exists but the result is still fail, compare its d= domain and s= selector with the DNS record you repaired. A downstream system that changes signed headers or the body can also break verification; a body hash mismatch points to changed message content. Read the destination receiver's Authentication-Results header rather than relying on a header supplied by the sender.
Frequently asked questions
No. Splitting a long TXT value into multiple strings is normal DNS behavior. Problems arise when chunks become separate TXT records, literal quotes are stored in the value, or public key characters are lost.
Repair is unavailable when the cPanel server does not control the domain's authoritative DNS. Copy the Suggested DKIM Name and Value into the DNS host named by the domain's NS records, then recheck the authoritative answer.
Keep 2048-bit RSA DKIM and fix the DNS host's TXT handling. cPanel's 1024-bit workaround is unsupported and is no longer available on Enterprise Linux 8 or later. A shorter key is not a reliable repair.
cPanel and the receiver can use different DNS paths. A readable DNS key does not prove that mail is signed with the matching private key, or that the message is unchanged after signing. Check authoritative DNS and the destination receiver's message headers; unsigned mail generally has dkim=none.
Yes. Quotes used to display DNS strings are normal, but literal quotes stored inside the DKIM value can break tag parsing or public key decoding. Copy the raw value or the DNS host's required split format without adding embedded quotes.
Check the selector TXT record at the authoritative nameservers. If that answer is clean, send a live test message and inspect Authentication-Results and DKIM-Signature headers.
