A customer says your invoice email landed in spam. Your team checks the sent folder, sees it left successfully, and has no clear answer. One of the first checks is whether the recipient could validate the message's DKIM signature. Knowing how to validate DKIM signatures tells you whether your email was signed correctly, whether the public key is available in DNS, and whether the signed content survived delivery unchanged.
DKIM stands for DomainKeys Identified Mail. It adds a digital signature to outgoing email. Receiving mail servers use that signature to check that a message was authorized by the sending domain and was not altered after it was signed.
The straight answer: validate DKIM by reviewing the message headers, finding the `DKIM-Signature` header, retrieving the matching public key from Domain Name System (DNS), and confirming the receiving server's authentication result. A `dkim=pass` result means the signature validated. A failure tells you where to investigate.
What DKIM validation actually checks
When your mail server sends a message, it creates a private-key signature. It places that signature in a `DKIM-Signature` header. The matching public key is published in DNS under a record selected by the message header.
The recipient server reads the signature, looks up that public key, and uses it to verify two things: the selected headers are still intact and the signed message body still matches its original hash. A hash is a short mathematical fingerprint of data. If the fingerprint no longer matches, validation fails.
DKIM validation does not prove that every part of a message is trustworthy. It does not assess whether the content is wanted, whether a link is safe, or whether the sender will reach the inbox. It confirms a narrower but valuable fact: the message was signed by a domain with access to the private key, and the signed portions were not changed in a way that breaks verification.
How to validate DKIM signatures step by step
You can validate a single received email from its full headers. This is useful when a specific customer, vendor, or employee reports a delivery problem.
1. View the original message headers
Open the message in your email application and choose the option commonly labeled “View original,” “Show source,” or “View message headers.” Copy the full headers, not just the visible sender address.
Look for a line beginning with `DKIM-Signature:`. It may wrap across multiple lines. That is normal. You will also usually find an `Authentication-Results:` header added by the receiving mail system.
2. Read the receiving server's result first
The fastest answer is usually in `Authentication-Results`. Look for language similar to:
`dkim=pass header.d=example.com`
A pass means the recipient successfully found the public key and verified the signature. A line such as `dkim=fail`, `dkim=neutral`, `dkim=temperror`, or `dkim=permerror` needs investigation.
Treat this header as the recipient's record of what happened. Do not rely only on the fact that your sending platform says DKIM is enabled. A setting can be enabled while the DNS record is missing, a key has been rotated incorrectly, or another system changes the message after it is signed.
3. Match the selector and signing domain
Inside the `DKIM-Signature` header, find `d=` and `s=`. The `d=` value is the signing domain. The `s=` value is the selector, which identifies the specific DKIM key used.
For example, this portion:
`d=example.com; s=mail2026;`
means the recipient should look up this DNS name:
`mail2026._domainkey.example.com`
The `_domainkey` portion is required. If you query only the domain or selector, you are checking the wrong record.
4. Check the DKIM record in DNS
The DNS lookup should return a TXT record, or sometimes a CNAME record that points to the service managing your DKIM key. A TXT record normally includes `v=DKIM1` and `p=`, followed by the public key.
A basic record may look like this:
`v=DKIM1; k=rsa; p=MIIBIjANBg...`
The exact public-key value will be much longer. Do not edit or reformat it manually unless your sending provider gives you replacement instructions. Extra quotes, copied spaces, missing characters, or split-record errors can make a valid-looking key unusable.
If the lookup returns no record, the selector in the email and the DNS configuration do not match. Check whether you published the record under the right domain, whether your DNS provider has completed the change, and whether your email platform is using an old selector.
5. Confirm that the signature aligns with your visible sender
A message can pass DKIM while signing with a domain unrelated to the address shown in the From field. That may be acceptable for some operational mail, but it is less useful for your domain's authentication policy.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, checks whether the domain visible to the recipient aligns with either DKIM or SPF. SPF stands for Sender Policy Framework. It authorizes servers that can send mail for a domain.
For DKIM alignment, compare the visible From domain with the `header.d=` domain in the authentication results. Exact matching is simplest. A related subdomain may also align, depending on your DMARC policy.
6. Check for changes made after signing
A DKIM failure is often not a bad key. It can mean a system modified the message after the signature was applied. Common examples include a forwarding service adding content, a gateway rewriting message formatting, or a mail server appending a footer or disclaimer.
Review the `h=` tag in the signature to see which headers were signed. Review `bh=` for the body hash. If the failure says the body hash did not verify, focus on systems that could have changed the message body. If the public key could not be found, focus on the selector and DNS record instead.
What common DKIM results mean
A `dkim=pass` result means the signature verified. It is the outcome you want, but it is not a complete deliverability grade. Recipient filtering can still consider sending reputation, content, user engagement, and other signals.
A `dkim=fail` result means the recipient found the signature but could not verify it. The public key may be wrong, the message may have changed, or the signing configuration may be inconsistent.
A `dkim=temperror` usually indicates a temporary lookup problem. Check DNS availability and retry with another message before making major changes.
A `dkim=permerror` indicates a configuration issue that will not resolve on its own. Typical causes include a malformed record, an invalid key, or a selector that does not exist.
A `dkim=neutral` means the receiver could not make a positive validation decision. Read the adjacent diagnostic text. Different providers use this result differently, so the reason matters more than the label alone.
Fixes that solve most DKIM validation failures
Start with the exact selector shown in a failed message. Do not guess based on a record you remember creating months ago. Then compare the selector, domain, and public key against the current instructions from the system that actually sent that message.
If your DNS record is missing, publish the required TXT or CNAME record precisely as provided. If it exists but has the wrong key, replace it with the current value. If you recently changed email platforms, make sure old systems are not still sending with retired selectors.
If message modification is the issue, decide where signing should happen. Signing after a footer, security gateway, or routing service makes sense when that service changes the message. Signing before it does not. The right order depends on your mail flow, so your IT team may need to map every system that touches outbound email.
Use a sufficiently strong current key based on your sending provider's guidance. Many organizations use 2048-bit RSA keys where supported. Key length alone will not fix a selector mismatch or a modified message, but outdated key settings can create avoidable problems.
Validate DKIM as part of a wider email check
DKIM works best alongside SPF and DMARC. SPF confirms whether the sending server is authorized. DKIM protects a signed message and identifies the signing domain. DMARC applies alignment rules and tells receivers what to do when authentication fails.
Other records can support your broader email security posture, but they solve different problems. BIMI, or Brand Indicators for Message Identification, can support brand display in participating inboxes when its requirements are met. MTA-STS, or Mail Transfer Agent Strict Transport Security, helps require encrypted delivery between mail servers. TLS-RPT, or Transport Layer Security Reporting, provides reports about failures involving that encrypted transport.
Validate DKIM after any mail-platform migration, DNS change, domain acquisition, or new sending-tool rollout. Also test each meaningful mail stream separately. Your marketing system, invoicing software, help desk, and individual employee mailboxes may use different selectors and different signing domains.
For a clear starting point, run MailArrive's free email health check and review the Report Card. It grades your domain's public email records and points you to the exact fix before a small authentication error becomes a harder-to-explain delivery problem.