A hosting panel can show DKIM enabled for its own mail service while WordPress sends through a different SMTP provider. DKIM passes only when the actual sender signs the message and the matching public key is published at authoritative DNS.
Read one delivered header to identify the signer before changing records.
Confirm whether a signature exists
Inspect the message’s DKIM-Signature and Authentication-Results headers. Record the signing domain (d=), selector (s=), result and provider message ID.
If no signature exists, DNS cannot create one after delivery; the sending service must be configured to sign. If a signature exists but fails, continue with selector, key and message-integrity checks.
Protect recipient and internal routing details when sharing the header.
Identify the real mail transport
Determine whether WordPress uses the local hosting mail server, external SMTP or a transactional API. A cPanel or Plesk DKIM switch normally controls mail sent by that server, not Microsoft 365, Google Workspace or another provider.
Check active mail plugins, constants and custom PHPMailer hooks. The test tool and real form may use different From addresses or even different transports.
Search the actual provider log for the controlled message.
Query the exact selector
The public key belongs at:
selector._domainkey.signing-domain.exampleReplace both selector and domain with the s= and d= values from the message. Query authoritative DNS and compare the returned key with the sender’s current setup instructions.
Do not query a guessed default selector just because the hosting panel uses that name.
Check where DNS is authoritative
Review the domain’s nameservers. A DKIM key displayed in the hosting panel is ineffective when DNS is actually managed in Cloudflare or elsewhere.
Publish the provider’s public TXT or CNAME record exactly at the active DNS service. DNS interfaces may append the zone name automatically, so verify the final fully qualified hostname.
Never publish the private signing key or copy it between providers.
Look for stale or rotated keys
Providers rotate DKIM selectors or keys. The sender may sign with a new selector while DNS still contains only the old one, or a migration may restore obsolete values.
Keep old selectors only for the provider’s recommended overlap period, then remove unused records. Avoid combining two DKIM keys into one TXT value.
Allow for DNS TTL and provider verification before the retest.
Check signing-domain alignment
A valid provider signature can pass DKIM but fail DMARC if its d= domain does not align with the visible From. Configure a verified custom sending domain when the provider supports one.
Use a fixed authenticated From domain and put visitors in Reply-To. Do not switch From domains dynamically across public form fields.
Record DKIM pass and DMARC alignment as separate results.
Investigate message modification
DKIM can fail when a gateway, forwarding service or plugin modifies signed headers or body content in a way the signature did not permit. Compare provider acceptance evidence with the version received after forwarding.
Test direct delivery to a controlled mailbox before a distribution list or helpdesk. Avoid unnecessary post-signing footers and forwarding rewrites.
Do not weaken signing configuration until the modifying hop is identified.
Verify the full form route
After correcting sender signing or DNS, submit the real form with a new reference. Confirm the provider adds DKIM, the recipient reports dkim=pass, DMARC aligns and the message reaches the business mailbox.
Test visitor confirmations and other From domains separately. Document selector ownership so a future migration does not rely on the wrong panel.
Request urgent repair when multiple senders sign differently, the selector is unclear or forwarding breaks valid signatures. Share public DNS and redacted authentication results—never private keys or credentials.