How DKIM Works and Why It Fails
DKIM, or DomainKeys Identified Mail, helps receiving servers verify that an email was authorized by the domain owner and not altered in transit.
When DKIM is not working, the problem usually comes from a mismatch between the public key in DNS and the signature added by the sending server.
The good news is that most DKIM failures are traceable.
With the right checks, you can identify whether the issue is in DNS, the mail platform, message formatting, or a misconfigured selector.
Check the DKIM Record in DNS First
The first step in learning how to fix DKIM not working is verifying that the DNS record exists and is published correctly.
A missing or malformed TXT record is one of the most common causes of authentication failure.
- Confirm the selector name matches what your mail system is using.
- Check that the record is published in the correct DNS zone for the sending domain.
- Make sure the TXT value is complete and not truncated by your DNS provider.
- Verify there are no extra spaces, line breaks, or quotation issues in the record.
Many providers use selectors such as default, s1, or google.
If the selector in the DNS record does not match the selector in the DKIM-Signature header, verification will fail even if the key itself is valid.
Verify the Selector and Domain Alignment
DKIM signatures include a selector and a signing domain.
Both must align with the published DNS key.
If you changed email services, migrated to Microsoft 365, Google Workspace, SendGrid, Mailchimp, or another ESP, old selectors may no longer apply.
What to compare
- s= in the DKIM-Signature header, which identifies the selector.
- d= in the DKIM-Signature header, which identifies the signing domain.
- The DNS query format: selector._domainkey.example.com.
If the sender is signing with one domain but the DNS record is published under another, the receiver cannot retrieve the correct public key.
This is especially common when subdomains are used for sending but the DKIM record is only published at the root domain.
Inspect the Full Email Header
Email headers show whether DKIM passed, failed, or was not evaluated.
Look for the Authentication-Results header and the DKIM-Signature header in the message source.
Useful indicators include:
- dkim=pass: the signature verified successfully.
- dkim=fail: the signature did not verify.
- dkim=neutral or none: no valid signature was present or it could not be checked.
If the message passes in one mailbox but fails in another, the issue may be related to message alteration by a gateway, forwarding service, or security appliance rather than your original DKIM setup.
Look for Message Changes After Signing
DKIM signs selected parts of an email.
If anything changes after the message is signed, verification can fail.
Common changes include rewritten headers, modified footers, altered MIME boundaries, or attachments being scanned and changed by a security gateway.
Typical causes of post-signing changes:
- Forwarding through a mail list or alias that rewrites the body.
- Outlook or server-side tools modifying message headers.
- Spam filters inserting disclaimers or banners.
- File conversion or attachment rewriting by security software.
If your emails pass internally but fail after forwarding, consider whether the forwarding path is breaking DKIM.
In some cases, Sender Policy Framework and Domain-based Message Authentication, Reporting, and Conformance can help, but DKIM remains vulnerable when the content changes.
Confirm the Private Key Is Installed Correctly
DNS alone is not enough.
Your sending platform or mail server must also use the matching private key to generate the signature.
If the private key is missing, rotated, expired, or installed in the wrong service, DKIM will fail.
Check whether your server is:
- Using the current private key for the active selector.
- Signing outgoing messages from the correct domain or subdomain.
- Applying the signature to all outbound routes, not just one mailbox or application.
- Restarted or reloaded after configuration changes.
For self-hosted systems like Postfix, Exim, or OpenDKIM, a configuration typo in the key path or table file can prevent signing entirely.
Managed platforms usually expose logs or status panels that confirm whether signing is active.
Check DNS Propagation and Caching
After creating or updating a DKIM record, it may take time for DNS changes to propagate.
Some receivers also cache DNS responses, which can delay verification after a fix.
If you just updated the record, test the domain using multiple lookup tools and wait for the TTL window to pass.
A record may appear correct in one region but still return the old value elsewhere.
Helpful checks
- Use dig or nslookup to confirm the TXT record publicly resolves.
- Test from different DNS resolvers to see whether caches are stale.
- Compare the published key against what your mail server expects.
Validate the DKIM Key Length and Format
Older systems sometimes use weak or outdated key lengths.
While DKIM verification failures are not always caused by key size, some receivers reject weak keys or malformed records.
A modern RSA key is typically 2048 bits where supported.
Make sure the public key in DNS is properly encoded and not corrupted.
Problems often appear when a key is copied with missing characters, line wrapping, or unsupported formatting.
Test with a DKIM Checker Tool
Before changing multiple variables at once, use a DKIM testing tool to isolate the failure.
These tools can parse the email header, validate the selector, and compare the public key in DNS against the signature.
Good checks usually show:
- Whether the message is signed.
- Whether the signature matches the body and headers.
- Whether the DNS record is discoverable.
- Whether the selector and domain are correct.
If a test message passes from one sender but not another, compare the outbound path, envelope domain, and message content between the two systems.
Review Common Platform-Specific Issues
Different email platforms fail in different ways.
Microsoft 365 may need DKIM enabled per domain.
Google Workspace requires the correct selector records before signing can start.
Third-party email service providers often require you to publish two CNAME or TXT records and then activate signing in the account dashboard.
Common platform mistakes include:
- Publishing the record but never enabling DKIM in the admin console.
- Using the wrong domain in the “from” address.
- Rotating keys in DNS without updating the sender configuration.
- Sending from a subdomain that does not have its own DKIM setup.
For transactional email systems, API-based sending can also complicate authentication if different applications use different return-paths or sending identities.
Use a Step-by-Step Fix Order
If you are troubleshooting how to fix DKIM not working, use a consistent order so you do not miss the root cause:
- Confirm the message is actually being signed.
- Check the selector and signing domain in the email header.
- Verify the public key exists in DNS and matches the selector.
- Inspect the private key installation on the sender.
- Look for message changes after signing.
- Test DNS propagation and caching.
- Recheck platform settings in the sending service.
This sequence solves most DKIM problems without guesswork.
It also helps distinguish between an authentication failure and a delivery issue caused by spam filtering or mailbox policy.
Prevent DKIM Failures Going Forward
Once DKIM is fixed, put controls in place to keep it stable.
Track selector changes, document where keys are stored, and test authentication after any migration, DNS update, or mail provider switch.
- Maintain a record of selectors, domains, and key rotation dates.
- Use monitoring to catch DKIM failures early.
- Test outbound mail after infrastructure changes.
- Keep SPF, DKIM, and DMARC aligned across all sending sources.
Good email authentication hygiene reduces spoofing risk and improves inbox placement.
It also makes future troubleshooting faster because you will know exactly which system signs each message and which DNS record supports it.