DKIM signature failed troubleshooting starts with evidence, not guesswork. A failed DomainKeys Identified Mail (DKIM) check usually points to a mismatch between the message signature, the public key in DNS, or the system that sent the message.
This guide explains how to read the relevant message headers and check DNS safely. The goal is to identify whether the problem involves the selector, key, record formatting, signing service, or domain alignment.
What a DKIM failure actually means
DKIM adds a cryptographic signature to an outgoing message. The receiving mail system uses that signature to find a public key in DNS. It then checks whether the signed message still matches the signature.
The signature normally identifies three important values:
- d= shows the signing domain.
- s= shows the selector used to find the DNS record.
- bh= contains a hash of the signed message body.
A selector is a label that lets one domain publish separate keys for different services. For example, a provider might sign with s=selector1 and publish the key at selector1._domainkey.example.com.
A receiver may report dkim=fail, dkim=permerror, or dkim=temperror. These results do not all mean the same thing. A permanent error often indicates a bad record or signature. A temporary error may involve DNS lookup or receiving-system conditions.
DKIM does not work alone. DMARC, or Domain-based Message Authentication, Reporting, and Conformance, also checks whether an authenticated domain aligns with the visible From domain. Therefore, a message can pass DKIM and still fail DMARC alignment.
Start DKIM signature failed troubleshooting with the headers
Do not begin by editing DNS. First, obtain the original message headers from a message that failed. Ask the recipient for the full headers if the sender’s mail system does not show them.
Look for an Authentication-Results header. It may contain a result similar to this:
Authentication-Results: receiver.example;
dkim=fail (bad signature) header.d=example.com header.s=mail;
spf=pass;
dmarc=fail header.from=example.comThe exact wording varies between mail systems. Focus on the result, signing domain, selector, and stated reason. Record them before making a change.
Next, find the DKIM-Signature header. Compare its d= and s= values with the authentication result. If the receiver reports selector mail, the DNS lookup must use that selector. Checking a different provider’s selector can produce a misleading result.
Save a complete sample that includes the sending date, recipient system, sender address, visible From address, and message route. Remove private message content before sharing it. Headers can contain addresses, internal hostnames, and tracking information.
Good DKIM signature failed troubleshooting also records whether the failure affects one recipient or several. That distinction can separate a message-path issue from a DNS or signing configuration issue.
Check the selector and DNS record
Once you know the selector, construct the DNS name:
._domainkey. For a message signed with s=mail and d=example.com, the lookup name is mail._domainkey.example.com. Query the authoritative DNS service or a trusted DNS lookup tool. You can also use a local command such as:
dig TXT mail._domainkey.example.comThat command is useful on systems with the dig utility, but output and availability vary. Confirm results against the DNS provider that hosts the domain’s authoritative records. A local resolver may cache an older answer.
For background on DNS records and resolution, see Cloudflare’s DNS overview. The key question is simple: does the exact selector from the message return the public key expected by the signing service?
Common selector problems include:
- The selector was typed incorrectly in the provider’s admin panel.
- A DNS record exists under another domain or subdomain.
- A provider changed selectors during a migration.
- The record was deleted after an old email service was retired.
- The message came from a different platform than expected.
Check the record at more than one resolver if timing matters. DNS changes can take time to appear consistently because resolvers cache answers according to the record’s time to live, or TTL.
If the lookup seems inconsistent, compare it with the broader DNS troubleshooting guide and the email delivery problems guide before changing unrelated records.
Inspect the public key and record formatting
A DKIM DNS record is usually a TXT record containing a public key. The value commonly includes v=DKIM1 and a key beginning with p=. The exact content must come from the email provider or signing system.
Do not copy a private key into DNS. The private key stays on the system that signs messages. DNS contains only the public key.
Formatting errors can cause a valid-looking record to fail. Check for:
- Missing or truncated characters in the
p=value. - Extra quotation marks copied into the record value.
- Spaces or line breaks inserted into the wrong place.
- Two TXT records published where the provider expects one key.
- A record created as a CNAME or another type instead of TXT.
- A record entered with the full name when the DNS panel already appends the domain.
Long TXT values may appear as several quoted strings in lookup output. That display does not automatically indicate a problem. DNS software can join multiple character strings into one logical value. Compare the reconstructed value with the provider’s published key.
Also check for duplicate DKIM records at the same selector. Multiple public keys can make the result ambiguous or cause the receiver to reject the lookup. Remove a duplicate only after confirming which service still sends mail.
Confirm that the correct system signs the message
A DNS record can be correct while messages still fail. The sending platform must use the matching private key. If an administrator rotated the key in DNS but the sending server still uses the old private key, the signature will not validate.
Review every service that sends mail for the domain. The list may include a hosted mailbox platform, website forms, a customer relationship system, marketing software, invoicing tools, ticketing systems, and scanners.
For each service, document:
- Service: name and sending address.
- Selector: value shown in its DKIM settings.
- Signing domain: value shown in the message header.
- Whether the service requires a custom return path or CNAME.
- The date of the last key rotation or DNS change.
Send a fresh test message from one system at a time. Do not rely on an old message captured before the change. Compare the new DKIM-Signature header with the DNS record currently published.
Some systems sign only messages that pass through a particular relay. Others sign after a message is modified by a gateway. If a filter changes the body or selected headers after signing, the receiver may report a bad signature.
When DKIM signature failed troubleshooting identifies a relay, test messages before and after that relay. This helps show whether the signing service or message path introduced the error.
Investigate body changes and canonicalization
DKIM can sign selected headers and the message body. The receiving system recalculates the body hash and compares it with bh=. A change after signing can therefore invalidate the message.
Possible changes include footer insertion, disclaimer text, subject rewriting, character conversion, line-ending changes, or attachment processing. These changes often occur when a message passes through a security gateway, mailing list, or forwarding service.
The signature includes canonicalization settings, commonly shown as c=. Simple and relaxed modes handle minor formatting differences differently. Changing this setting without understanding the provider’s process can create new failures.
Compare a direct message with one that passes through the suspected gateway. If direct delivery passes but routed delivery fails, inspect the gateway’s message modification and signing order.
Check DMARC alignment after DKIM passes
Once the DKIM result passes, review alignment. The visible From domain is what recipients see. The DKIM signing domain appears in d=. Under relaxed alignment, related organizational domains may align. Under strict alignment, the domains must match more closely.
For example, a message with From: billing@example.com and d=mailer.example.com may align under one policy but not another. A third-party provider might instead sign with its own domain, which can authenticate the message without aligning it to your From domain.
Review the provider’s custom-domain setup and your DMARC policy before changing enforcement. Microsoft’s email authentication overview explains how SPF, DKIM, and DMARC work together.
Do not weaken a DMARC policy just to hide a configuration error. First identify every legitimate sender, configure its authentication, and review aggregate reports where available.
A safe correction and validation sequence
Use this order when applying a fix:
- Capture the failing headers and record the selector and signing domain.
- Check the exact selector DNS name and confirm the record type.
- Compare the public key with the provider’s current value.
- Check for duplicate, truncated, or incorrectly scoped records.
- Confirm the sending service uses the corresponding private key.
- Test each sending platform separately.
- Verify DKIM, SPF, and DMARC results in fresh headers.
- Monitor delivery and authentication reports after DNS caching settles.
Keep a change record with the old DNS value, new value, provider instructions, test message, and validation result. This makes rollback safer and helps distinguish a DNS delay from a bad configuration.
For broader context, the Google Email Sender Guidelines describe authentication and sender practices that affect delivery.
When to request technical help
DKIM failures become harder when several platforms send mail, a gateway rewrites messages, or DNS is split across multiple providers. Professional help may be appropriate when you cannot obtain full headers, do not control the signing service, or need to change authentication without disrupting active mail.
That evidence makes DKIM signature failed troubleshooting more precise and reduces the risk of changing the wrong DNS record.
Tech Rescue Ops LLC can help collect evidence, map sending systems, review DNS, and validate a controlled correction. Preserve the headers and recent DNS changes before requesting assistance.