DKIM Signature Failing? Fix Selector and Key Issues

Your SPF and DMARC records look perfect, mail is still landing in spam, and the bounce message says something like "signature verification failed" or "body hash did not verify". That's not an SPF problem — it's DKIM, and it fails in ways that don't show up until you go looking for the actual selector.

Symptom: DKIM shows as fail or none in headers

You'll usually spot this in one of these places:

• Google Postmaster Tools or a mail-tester.com report shows DKIM: fail or DKIM: neutral even though you enabled it in cPanel
• The raw email headers show dkim=fail (body hash did not match) or dkim=none
• Mail sent through your website's contact form or WooCommerce passes SPF but fails DKIM
• Everything worked fine until you migrated hosts, switched to Google Workspace, or added a marketing tool like Mailchimp — then DKIM broke

DMARC and SPF checks are simple pass/fail against a single DNS lookup. DKIM is where most people get tripped up, because the record itself is easy to get subtly wrong and near-impossible to eyeball.

Cause: it's almost never "DKIM is missing"

In four years of support tickets, we've seen the same handful of root causes over and over. Missing DKIM entirely is actually the rare case — most sites have a record, it's just wrong in one of these ways:

1. Selector mismatch

DKIM doesn't live at one fixed DNS name. It lives at <selector>._domainkey.yourdomain.com, where the selector is whatever string the signing server chooses — cPanel uses default, Google Workspace uses google, Mailchimp uses something like k1 or k2, Microsoft 365 uses selector1/selector2. If the sending server signs with selector mandrill but you only published a TXT record for default, the receiver looks up a selector that doesn't exist and DKIM fails — even though a DKIM record technically exists on the domain.

2. Multiple senders, one selector slot forgotten

This is the most common one we see: a site uses cPanel for the website and staff inboxes, but sends marketing mail through Mailchimp and transactional mail through an SMTP relay. Each of those needs its own selector TXT record. Adding Mailchimp's DKIM record doesn't replace cPanel's — you need both to coexist, at different selector names, at the same time.

3. Long keys get truncated or misquoted

A 1024-bit DKIM public key fits in one 255-character DNS string. A 2048-bit key (the current default, and what cPanel/Exim generates now) is longer than that limit, so it has to be split into multiple quoted strings inside one TXT record:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA" "QEFAAOCAQ8AMIIBCgKCAQEAv3v..."

If you copy this out of cPanel and paste it into a third-party DNS panel as one giant unquoted string, or the panel's UI silently strips the quotes, the key gets mangled and every signature fails verification. This is the single most common cause when DKIM "was working, then broke" right after a DNS migration to Cloudflare or a registrar's DNS panel.

4. Stale record left behind after migration

If a site moved from another host to Getwebup, the old host's DKIM selector record sometimes stays live in the zone (especially if nameservers didn't fully cut over, or an old zone file was re-imported). Now two DKIM records exist for the same selector name, DNS returns both, and mail clients can't tell which is authoritative.

5. Mailing lists and forwarders break the body hash

DKIM signs the message body and specific headers at send time. If a mailing list, forwarder, or security gateway rewrites the subject line, adds a footer, or alters the body in transit, the signature no longer matches — you'll see body hash did not verify. This isn't a DNS problem at all; it's the intermediary breaking a signature that was valid when it left your server.

Fix: find the real selector, then verify the record

Step 1: Find out what selector is actually signing your mail

Send a test email to an address you control (Gmail is easiest) and open "Show original." Look for the DKIM-Signature header — it contains s= followed by the selector name:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=default; ...

That s=default is the selector you need to check in DNS. If you're sending from multiple platforms (cPanel + Google Workspace + Mailchimp), repeat this for each one — each will report a different selector.

Step 2: Query DNS directly for that selector

dig TXT default._domainkey.yourdomain.com +short

If this returns nothing, the record isn't published (or isn't published where your domain's authoritative nameservers actually point). If it returns a value, check that it starts with v=DKIM1 and that the p= value isn't cut short or contains stray characters from a copy-paste error.

Step 3: Get the exact record from cPanel and republish it correctly

In cPanel, go to Email → Email Deliverability, find your domain, and click the small triangle to expand it. This shows the exact DKIM record cPanel expects, selector included. If the status shows anything other than "Valid," click Repair Now — this regenerates the DKIM key pair and rewrites the record in the local zone, if cPanel manages your DNS.

If your nameservers point elsewhere (Cloudflare, GoDaddy, another registrar), you have to copy that record manually. Two things trip people up here:

• Copy the p= value exactly, including both quoted segments if it's split. Most DNS panels accept a single TXT value up to 255 characters per string automatically — if yours has one text box instead of two, check whether it supports multi-string TXT input; don't just concatenate the two halves into one string without the quotes, since some resolvers will read it as invalid.
• Set the record type to TXT, name to default._domainkey (or whatever selector applies), not default._domainkey.yourdomain.com.yourdomain.com — a lot of panels auto-append the domain, so a name field that already includes the full domain creates a duplicate suffix.

Step 4: Add every selector you actually use, don't replace

If you're sending from three platforms, you should end up with three separate DKIM TXT records at three different selector names, all coexisting:

Step 5: Clean up duplicates from old migrations

If dig in Step 2 returns two conflicting values for the same selector, you've got a leftover from a previous host. In cPanel → Zone Editor, search for _domainkey and remove any TXT record that doesn't match what Email Deliverability currently shows as valid. Only ever remove the stale one — confirm which is current first via the Repair/Valid status before deleting anything.

Prevention

• Whenever you add a new sending platform (a new ESP, a CRM, a form plugin using an external SMTP relay), check its docs for the DKIM selector it wants and add that record before you start sending through it, not after deliverability drops.
• After any DNS or hosting migration, re-run the dig TXT check on every selector you use — don't assume the new host carried the record over correctly.
• Use mail-tester.com or Google Postmaster Tools monthly if you send any volume of transactional or marketing email — DKIM failures are invisible until a receiving server starts silently dropping mail.
• Keep DMARC in p=none with reporting on while you're adding new selectors, so a misconfigured DKIM record shows up in aggregate reports instead of costing you real mail.