A DKIM failure is not just a technical warning. It can mean a customer never sees an invoice, an appointment reminder is questioned, or a sales email gets filtered before anyone reads it. To repair broken DKIM signatures, first identify whether the problem is your DNS record, the mail system signing the message, or a service changing the message after it is signed.
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outbound email. Receiving mail systems use a public key published in your domain's DNS records to check that signature. When the check passes, it shows that an authorized system signed the message and that key parts of the email were not changed afterward.
The straight answer: do not start by randomly replacing DNS records. Read one failed message header or authentication report, identify the selector and sending system involved, then correct that specific break.
What a broken DKIM signature means
A DKIM signature has two connected parts. Your sending server or email platform signs an email using a private key. It adds a DKIM-Signature header that includes a selector, such as `marketing` or `s1`. The receiving system then looks up a DNS record at a name like `marketing._domainkey.yourdomain.com` and uses the public key there to verify the signature.
A failure generally appears as one of these results: `dkim=fail`, `dkim=neutral`, `dkim=none`, or an error stating that no key was found. Those outcomes are different, and the exact fix depends on which one you see.
A missing key is usually a DNS publishing problem. A bad signature can point to a changed message, an incorrect private key, or a mail server configuration issue. A message with no DKIM signature may be coming from an application, copier, help desk platform, or employee device that is not configured to sign mail.
DKIM works alongside Sender Policy Framework (SPF), which identifies servers allowed to send for your domain, and Domain-based Message Authentication, Reporting, and Conformance (DMARC), which tells recipients how to handle mail that fails authentication. DMARC can pass when either aligned SPF or aligned DKIM passes. That does not make a DKIM failure harmless. Losing DKIM removes one of your most useful authentication checks and can expose gaps in your sending setup.
Start with the failed message, not the DNS record
Open a message that failed at the receiving mailbox. In Gmail, use “Show original.” In Outlook, view the message headers or message source. Look for the `Authentication-Results` header and the `DKIM-Signature` header.
Write down four details: the `dkim=` result, the signing domain after `header.d=`, the selector after `header.s=`, and the sending service or server that sent the message. This tells you which key the recipient tried to find and which system needs attention.
For example, a result such as `dkim=fail header.d=yourdomain.com header.s=mta1` means the recipient found a signature from your domain using selector `mta1`, but verification failed. A result such as `dkim=none` means there was no signature to check. If the header shows another domain after `header.d=`, the message may be signed by a third-party platform rather than your own domain.
Do this for more than one failed message if possible. A newsletter platform, Microsoft 365, Google Workspace, a billing system, and a website contact form can all send on behalf of the same business. One can have working DKIM while another is broken.
Check the DKIM DNS record carefully
Once you know the selector, look up the matching DNS record. It should be a TXT record at `selector._domainkey.yourdomain.com`. The record normally begins with `v=DKIM1` and includes `p=`, followed by a long public key.
Common DNS issues are simple but easy to miss:
- The selector in DNS does not match the selector used by the signing system.
- The record was added under the wrong DNS provider or wrong domain.
- The public key was pasted incompletely or with extra quotation marks or characters.
- A CNAME record required by your email platform was replaced with a TXT record.
- Two conflicting records exist at the same DKIM hostname.
- A recently changed record has not fully propagated yet.
Some providers publish DKIM with CNAME records instead of a visible public key. In that case, do not convert the CNAME to TXT because it looks unfamiliar. The CNAME may direct the lookup to the provider's current key. Follow the provider's required record type, hostname, and destination exactly.
Also check whether your domain uses a DNS proxy or security layer. DKIM records must be publicly available through standard DNS lookups. A proxy setting intended for websites does not apply to mail authentication records.
Repair broken DKIM signatures at the sending source
If the record exists and the selector is correct, the next question is whether the sender still has the matching private key. Public and private keys are a pair. Publishing a new public key in DNS while leaving an old private key on the mail server creates a signature that cannot verify.
For a managed email platform, the exact fix is often to regenerate or re-enable DKIM in that platform's admin console, publish the new records it provides, and turn signing on after DNS is confirmed. Do not reuse records from an old tenant, former vendor, or previous domain setup.
For a self-managed mail server, verify the selector configured in the signing software, the private-key file it references, and the DNS public key for that same selector. This is also where permissions and server restarts matter. A correct DNS record will not help if the mail transfer agent cannot read the key or the signing service is not running.
If your business sends from multiple sources, create an inventory. Include your primary mailbox provider, marketing platform, customer relationship management system, accounting software, website forms, printers, and support tools. For each source, record whether it sends using your domain and whether it signs with DKIM. This prevents a partial repair where routine employee mail passes but invoices or automated notices still fail.
Look for message changes after signing
A DKIM signature can fail even when the keys are correct. Some mail systems or gateways alter an email after it has been signed. Adding a footer, rewriting links, changing the subject line, modifying MIME formatting, or converting message content can invalidate the signed parts of the message.
This often happens when mail travels through more than one system. For example, a server may sign the message, then a separate outbound gateway adds a legal disclaimer. The recipient receives the altered version, and the signature no longer matches.
The best repair is usually to sign as late as possible in the outbound path, after any system that adds footers, scans content, or rewrites messages. Sometimes the safer choice is to configure the modifying gateway to preserve the signed content. It depends on which system you control and which changes are required for your business.
Forwarding creates a related issue. Traditional forwarding can change a message enough to break SPF, while DKIM may remain valid if the signed content is preserved. That is one reason working DKIM is valuable. Do not assume a forwarding-related failure means your DNS is wrong. Compare a directly delivered test message with one that was forwarded.
Avoid these DKIM repair mistakes
Do not delete a current DKIM key until you know every active sender has moved to the replacement selector. Key rotation is good practice, but deleting an old key too early breaks mail signed with that key.
Do not publish the private key in DNS. DNS only contains the public key. If a private key has been exposed, generate a new key pair and update the sending system and DNS record together.
Do not use a single successful test as proof that all email is fixed. Test messages from each sending source and review the results at a mailbox you control. You want to see `dkim=pass` for mail signed with your domain. Then check your DMARC reports, if you receive them, for failures that may affect systems you did not test.
Finally, do not confuse a passed DKIM check with a promise of inbox placement. Authentication is a foundational control. Recipient filtering also considers sending patterns, reputation, message content, and recipient engagement.
Verify the repair and keep it from returning
After changing DNS, allow time for the new record to become available based on its time to live, or TTL, setting. Then send fresh messages. Old messages will not re-verify under a new signing configuration because they were signed before the change.
Check both the technical result and the practical sending path. Confirm that messages from staff, automated systems, and marketing or customer communications are using the expected domain and selector. If a vendor sends mail from its own domain, decide whether that is acceptable for the message type or whether it should be configured to send and sign with your domain.
For your next step, run MailArrive's free email health check and review the Report Card. It can show whether your DKIM record is publicly available and identify related SPF, DMARC, DNS, and domain health issues. If the repair requires changes to DNS or a mail server you do not manage, Matano IT can handle the hands-on remediation.