A customer says your invoice never arrived. Your mail server shows it was sent. The receiving system shows a DKIM failure instead. That gap is where a routine business email can be treated with suspicion.
DKIM failure reasons usually come down to one of three things: the public key is missing or wrong, the message was changed after it was signed, or the signing setup does not match the domain you are sending from. The straight answer is that DKIM is fixable, but the exact fix depends on where the failure occurs.
DKIM stands for DomainKeys Identified Mail. It adds a digital signature to outgoing email so receiving servers can confirm that the message came from an authorized system and was not altered in transit. It works alongside SPF, or Sender Policy Framework, which identifies servers allowed to send for your domain, and DMARC, or Domain-based Message Authentication, Reporting, and Conformance, which tells receiving systems how to handle authentication failures.
Why a DKIM failure affects business email
A DKIM failure does not automatically mean every message will be rejected or sent to spam. Receiving systems evaluate several signals, including SPF, DMARC, sender reputation, message content, and recipient engagement. Still, a failed signature removes a meaningful proof point.
That matters when you send appointment reminders, contracts, payment notices, customer replies, or sales follow-ups. If a recipient cannot verify who sent the message, their provider may filter it, flag it, or apply stricter scrutiny. A passing DKIM record also supports DMARC alignment, which is increasingly expected by major mailbox providers for business and bulk email.
The most common DKIM failure reasons
The DKIM public key is missing from DNS
The most common issue is simple: your sending service signs mail with a selector, but the matching DKIM public key cannot be found in your Domain Name System, or DNS, records.
A selector is a label used to find the correct key. A receiving server looks up a record in a format similar to `selector._domainkey.yourdomain.com`. If that record does not exist, was added under the wrong domain, or contains a typo, verification fails.
The exact fix is to copy the DKIM record provided by your email platform and publish it in DNS exactly as supplied. Check the selector, domain name, record type, and key value character by character. Some providers use a TXT record, while others use a CNAME record, which points one DNS name to another. Use the type your provider requires, not the type used by a different sending tool.
The selector in the message does not match the DNS record
Your email may include a DKIM signature, but the selector named in that signature does not match the selector published in DNS. This often happens after a migration to a new email platform, a change in marketing software, or a key rotation.
For example, an old service may sign with the selector `mail`, while a new service signs with `s1`. If only the old `mail` record exists, messages signed by `s1` will fail verification.
Check a failed message's authentication results and DKIM signature headers. Find the `s=` value, which identifies the selector, then confirm that the corresponding DNS record exists. Keep active records for every legitimate system that sends email on your behalf. Remove old records only after you confirm the old sender is no longer in use.
The DKIM key was copied incorrectly
DKIM keys are long. A single missing character, extra quotation mark, broken line, or pasted space can make the record unusable. DNS control panels sometimes wrap long values visually, which is normal. What matters is whether the stored record contains the full key without unintended changes.
A common mistake is placing the entire hostname in a DNS field that automatically appends your domain. That can create a record such as `selector._domainkey.yourdomain.com.yourdomain.com`. Another is including text such as `k=rsa;` when the provider's instructions say to publish only the value after `p=`.
The fix is to compare the published record against the source record from your sender. Do not rely on how it appears in a cropped DNS screen. Query the live DNS record and compare the returned value. If you are not sure which field your DNS host expects, ask the host or your IT team before changing a working record.
DNS changes have not propagated yet
DNS updates are not always visible immediately. Each record has a time to live, or TTL, which tells other systems how long they may cache it. During that period, some receiving servers may still see the old DKIM record while others see the new one.
This is normal after a planned change. It becomes a problem when teams make several changes in a row without waiting to verify the first one. That makes it difficult to know which version is active.
Publish the corrected record once, then verify the live result. If you replaced an old key, leave the old selector available long enough for previously signed mail and cached DNS lookups to clear. The appropriate wait time depends on your prior TTL and the DNS provider's update behavior.
The message changed after DKIM signing
DKIM signs selected parts of a message, including headers and often the body. If another system changes a signed portion after the signature is applied, verification can fail.
This can happen when mail passes through a forwarding service, security gateway, disclaimer tool, customer relationship management system, or ticketing platform. Adding a footer, rewriting a subject line, converting message formatting, or modifying attachments may be enough to invalidate a signature.
The exact fix is usually to adjust the mail flow, not the DNS record. Configure the final sending system to apply the DKIM signature after modifications are complete. If a gateway must alter outgoing messages, it may need to re-sign them using a properly published DKIM key for your domain. This is an IT-level change because it affects server routing and message handling.
The wrong domain is signing the message
A message can pass DKIM but still fail DMARC alignment. This distinction matters. DKIM checks whether a signature is valid. DMARC checks whether the domain in that valid DKIM signature aligns with the visible domain in the From address.
For example, your visible From address may be `billing@yourcompany.com`, but a third-party platform signs with its own domain. The signature may technically pass, yet it may not help your DMARC result.
The fix is to set up custom domain DKIM in the third-party platform when it is available. That allows the platform to sign using a domain you control, such as `mail.yourcompany.com` or your primary domain, depending on the provider's setup. Confirm the platform's recommended configuration before choosing a subdomain. Different sending streams, such as employee email and marketing email, may reasonably use separate selectors or subdomains.
A private key is missing, outdated, or inaccessible
The public half of a DKIM key lives in DNS. The private half stays on the mail server or with the sending provider. If the private key is missing, corrupted, replaced without updating DNS, or unavailable to the server, your system may stop signing messages altogether.
In this case, the message may have no DKIM signature, or it may use a signature that does not match the public key. The receiving server cannot validate it.
Your email administrator or provider must confirm that DKIM signing is enabled and that the active private key matches the published public key. If keys were rotated, both sides must change together. Do not publish a new public key unless the sending system has been updated to use its matching private key.
How to diagnose a DKIM failure without guessing
Start with a recent message that produced a failure. Review the message headers for `Authentication-Results` and `DKIM-Signature`. You are looking for whether the result says `pass`, `fail`, `none`, or `temperror`.
A result of `none` usually means no usable signature was found. A result of `fail` means a signature was present but could not be verified. A temporary error, often shown as `temperror`, can point to a DNS lookup issue or a temporary receiving-system problem. Test again before making a permanent change.
Then answer three practical questions: Which system sent the message? Which domain and selector did it sign with? Does the live DNS record match that exact selector and the sender's required record type? Those answers narrow most DKIM problems quickly.
Do not treat one test message as the full picture. If your organization sends through Microsoft 365, Google Workspace, a marketing platform, a website form, and an invoicing tool, each system may have its own DKIM setup. A passing signature from employee email does not prove that automated invoices or campaign mail are configured correctly.
Prevent the next DKIM problem
Keep a simple inventory of every approved email sender, the domain it uses, its DKIM selector, and who manages its DNS record. Review that inventory when you add software, change website providers, or move email hosting.
Use long DKIM keys when your sending provider supports them, typically 2048-bit keys. They offer stronger cryptographic protection, though older systems may have DNS limitations that require extra setup. Also avoid reusing one selector for unrelated systems. Separate selectors make troubleshooting and key rotation easier.
After DNS or mail-flow changes, test real messages from each sending source. Confirm both DKIM verification and DMARC alignment. That gives you evidence that the fix works where it matters: on mail actually leaving your business.
If you need a plain-language view of your domain's DKIM, SPF, DMARC, DNS, and reputation signals, run MailArrive's free email health check and review your Report Card. If the correction requires DNS access or mail server changes you cannot safely make, Matano IT can handle the remediation.