A new WordPress mail provider reports that DKIM is enabled, yet received messages show dkim=fail. DNS still contains the old selector, the replacement public key was copied incorrectly, and no one has checked which domain appears in the actual signature.
DKIM is proven in a delivered message, not by an enabled switch. Publish the exact public selector record, keep the private key with the signing service, and inspect the signature’s domain and selector before considering the setup complete.
What it means
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to selected headers and the message body. The sending service holds the private key. Receivers read the d=signing domain and s=selector from DKIM-Signature, then retrieve the corresponding public key from DNS.
A valid signature shows that the signed content survived transit and that the signer possessed the matching private key. It does not automatically satisfy DMARC: the d=domain must also align with the address visible in From.
A realistic WordPress example
After a provider migration, the administrator pastes a long DKIM key into DNS but loses characters at a line break. The provider signs with the new selector, so receivers find a malformed public key and return dkim=fail.
The DNS value is republished exactly as the provider specifies. Once authoritative DNS is consistent, a new WordPress message shows the expected d=and s=values and dkim=pass. The old selector remains available during the documented overlap for delayed mail.
Why it matters and when to use it
DKIM protects the integrity of signed content and gives receiving systems a stable domain identity for reputation and DMARC evaluation. Missing, invalid, or unaligned signatures can reduce trust even when SMTP delivery itself succeeds.
Different WordPress events may use different providers, streams, or sender identities. A passing generic test does not prove that password resets, forms, orders, and bulk notifications all use the same signing domain.
Use DKIM for maintained production mail streams whose provider supports an owned or delegated signing domain and a clear selector-rotation process.
A straightforward route for beginners
- Record the mail provider, visible From domain, expected
d=domain, selector, DNS owner, and rotation owner. - Generate or obtain the provider’s current DKIM record. Publish the TXT value or CNAME delegation exactly at the required selector name; never publish the private key.
- Query the selector at the authoritative DNS servers and confirm that every server returns the intended value.
- Enable signing only as directed by the provider. Send a controlled WordPress message and inspect raw
DKIM-SignatureandAuthentication-Resultsheaders. - Confirm
dkim=pass, the expectedd=ands=, and DMARC alignment. Test more than one business-critical WordPress event.
The advanced route
Check DNS TXT chunking and quoting, or the target of a CNAME delegation, exactly as the provider requires. Inspect canonicalization, signed-header list, optional body-length tags, key strength, TTL, and whether mailing-list or security tooling modifies signed content.
Use unique selectors for unrelated services and environments. During rotation, publish the new public key before the signer uses it, then keep the old selector until the longest possible delayed message and DNS cache period have passed. Confirm that new mail no longer uses the retired selector before removing it.
Record a complete header sample for each relevant stream, including the visible From domain, d=, s=, algorithm, and receiver result. A pass on a provider-owned domain may be valid DKIM but still fail DMARC alignment.
Risks, common mistakes, backup, and rollback
Never expose the private signing key in WordPress, DNS, logs, tickets, or screenshots. Do not delete the previous selector before queues drain, reuse one selector across unrelated services, or assume that any dkim=passauthenticates the visible From domain.
Save the previous selector records, provider setting, TTL, and activation time before rotating. If authoritative DNS is inconsistent, signatures fail, an unexpected domain signs, or critical event types remain unsigned, return the signer to the last verified selector while keeping the corresponding public key available.
How AIOWS helps:
AIOWS SMTP Manager
AIOWS SMTP Manager keeps the WordPress-side provider route, sender identity, and controlled test available while DKIM is configured. The delivered test message can then be inspected to see which service signed it and which d=and s=values were used.
Repeat the check with representative WordPress-generated mail on the same route. Compare the raw headers with the provider configuration and authoritative selector record. Keep credentials and any private key outside WordPress content, logs, and support material.
AIOWS does not generate the provider’s DKIM private key, publish its DNS selector, perform key rotation, or guarantee that every external mail stream uses the same signer. It also cannot create DMARC alignment when the signing and visible From domains differ. Those responsibilities remain with the provider and DNS owner.
Related AIOWS articles
- How to Set Up SPF for WordPress Email Delivery
- How to Set Up DMARC for WordPress Emails
- WordPress From Address Mismatch: Causes and Fixes
Conclusion and recommended route
Keep signing keys with the provider, publish the exact public selector under the intended domain, and verify d=, s=, and Authentication-Resultson real WordPress mail. Rotate selectors with enough overlap for DNS caches and delayed messages.
