Why does MXToolBox say my DKIM Signature is not verified?
Published 15 Apr 2025
Updated 23 May 2026
10 min read
Summarize with
MXToolBox says "DKIM Signature is not verified" when the DKIM-Signature header it tested does not validate against the message body and the public key it found in DNS. That does not automatically mean your DKIM DNS record is wrong. In the cases I see most often, the record is valid, but the copied email header has stray whitespace, line wrapping, missing header lines, or a body hash that changed after the message was signed.
The fast answer is this: retest the exact same email using raw source, check the selector and domain in the DKIM-Signature header, confirm the public key resolves, then compare that with the Authentication-Results header at a real mailbox. If Gmail, Microsoft 365, Yahoo, or your own receiving mail server says dkim=pass for the same message, I treat the MXToolBox result as a warning to investigate, not as final proof of a broken setup.
- Most common cause: the pasted header was changed by copying, wrapping, or unfolding.
- Most important check: look at the receiver's Authentication-Results header for the same email.
- Most urgent fix: repair the real signing path if recipient headers show DKIM fail or permerror.
- Most practical workflow: use one-off checks for diagnosis, then monitor DMARC reports continuously.
The direct answer
MXToolBox is checking the DKIM signature, not only the DKIM DNS record. A DNS lookup can show a syntactically valid public key while a message-level DKIM test still fails. DKIM verification depends on five things being consistent at the same time: the signed message body, the selected headers, the d= signing domain, the s= selector, and the public key published at that selector.
That is why the exact wording matters. "DKIM record not found" points toward DNS. "DKIM Signature is not verified" points toward message verification. The public key can be fine, while the signature check fails because the message changed, the header was pasted incorrectly, or the checker parsed a folded line differently than the receiving server did.
Fast triage rule
If MXToolBox is the only place showing a DKIM signature failure, do not rotate keys or change DNS immediately. First confirm the same email's raw headers at the destination mailbox.
- Passing receiver: if the mailbox shows dkim=pass, your production signing path is working for that message.
- Failing receiver: if the mailbox shows dkim=fail, fix the signer, content modification, or DNS key.
- Mixed results: if providers disagree, test a fresh email and compare the exact selector.
- No reports: if you have no receiver evidence, pull DMARC aggregate data before changing policy.
MXToolBox email deliverability screen showing a DKIM signature not verified result.
A public ServerFault case describes the same pattern: DKIM validated elsewhere, but MXToolBox reported the pasted signature as not verified. That is the key distinction to keep in mind.
What DKIM verification checks
DKIM is not a simple DNS lookup. The sending system signs selected headers and a canonicalized version of the message body. The receiver fetches the public key from DNS and uses it to verify that the signature matches the email it received. A small change in the body, a missing header, or a bad copy of the DKIM-Signature line is enough to break a manual verification test.
DKIM verification uses the signed body, signed headers, selector, DNS key, and result.
The body hash is the fastest way to understand many false alarms. The bh= value is a hash of the canonicalized body. If a footer, tracking wrapper, security gateway, or mailing list changes the body after signing, that value no longer matches. If the body did not change but the header was copied with an extra space, the checker can still fail because the input is no longer the same header.
Example DKIM-Signature header fragmentstext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=Base64BodyHashValueHere; b=Base64SignatureValueHere
- Selector: the s= tag tells the receiver which DNS record to query.
- Domain: the d= tag tells the receiver which domain published the key.
- Body hash: the bh= tag proves the signed body still matches.
- Signature: the b= tag proves the selected signed headers still match.
Common causes of the warning
When someone says they configured SPF, DKIM, and DMARC correctly but MXToolBox still says the DKIM signature is not verified, I separate DNS problems from message problems. That saves time because changing DNS will not fix a body hash mismatch caused by a downstream footer.
|
|
|
|---|---|---|
Copied header | Whitespace changed | Use raw source |
Body changed | Hash mismatch | Check gateways |
Wrong selector | Key lookup fails | Match s= |
Old key | DNS stale | Wait TTL |
Bad signing | Signer issue | Rotate key |
Common reasons MXToolBox reports a DKIM signature verification failure.
Long DKIM keys are another common source of confusion. In Amazon Route 53 and many DNS hosts, a long TXT record is displayed as multiple quoted chunks. That is normal as long as DNS returns one continuous string. Quotes in the DNS editor are not the same thing as stray whitespace inside a pasted message header.
DNS record problem
A DNS problem means the public key cannot be found or parsed correctly.
- Selector mismatch: the email signs with one selector while DNS has another.
- Missing TXT: the selector record does not resolve publicly.
- Broken key: the public key has missing characters or bad TXT joins.
- Old cache: the previous key is still visible until DNS TTL expires.
Signature problem
A signature problem means the key exists but the tested message no longer verifies.
- Header copy: line wrapping or extra spaces changed the signature input.
- Body edits: a footer, rewrite, or relay changed signed content.
- Canonicalization: strict signing rules left less tolerance for changes.
- Forwarding path: a downstream system modified the message after signing.
How to test it cleanly
Start with a fresh email to a mailbox you control. Do not forward the message, do not copy it through a rich text editor, and do not paste only the DKIM-Signature line. Open the raw source and inspect the Authentication-Results header added by the receiving system.
Then check the selector and public key with a focused DKIM checker. If you want a broader view of DMARC, SPF, DKIM, and domain readiness, run a domain health check as well. The goal is to verify DNS separately from the message-level signature result.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
The DNS lookup target should be built directly from the message header. If the signature says s=selector1 and d=example.com, query the selector under _domainkey. Do not guess the selector from your email platform settings if the live message uses a different one.
Selector lookup patterntext
selector1._domainkey.example.com Expected TXT starts with: v=DKIM1; k=rsa; p=
- Send fresh mail: send a new message directly to a mailbox with full raw header access.
- Read results: look for dkim=pass, dkim=fail, or dkim=permerror in Authentication-Results.
- Match tags: use the live s= and d= tags to query the public key.
- Retest source: paste raw source only if the checker requires the full email content.
- Check reports: use aggregate DMARC data to see whether recipients report the same failure.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
If the focused selector check passes but message verification fails, move to header and body changes. If the selector check fails, fix DNS before spending time on canonicalization or forwarding behavior. For a broader workflow, the DKIM troubleshooting steps are useful when failures differ by receiver.
What to fix when DKIM really fails
A real failure needs a fix in the signing path, not a cosmetic DNS change. The exact action depends on where the mismatch starts. I check the raw message first, then the sending platform, then DNS. That order keeps the work tied to evidence instead of guesswork.
Example split TXT displaytext
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjAN" "BgkqhkiG9w0BAQEFAAOCAQ8A..."
The split TXT display above is not automatically wrong. DNS software often joins quoted chunks into a single value. It becomes a problem only when the published key has inserted spaces, missing characters, duplicated quotes, or an extra TXT record at the same selector.
Do not break a passing setup
If live mailbox headers pass DKIM, changing the selector or rotating the key can create a new outage. Confirm real receiver failures before making DNS changes.
- Safe change: fix an obvious missing selector or malformed public key.
- Risky change: deleting an old key while mail still signs with that selector.
- Better check: inspect several recent messages across normal sending sources.
- Policy risk: tight DMARC policy can reject mail when SPF also fails domain matching.
How urgent is the DKIM warning?
Use receiver evidence, not one pasted-header result, to decide how fast to act.
Low risk
Monitor
Other validators pass and mailbox headers show DKIM pass.
Investigate
Retest
MXToolBox and mailbox headers disagree on the same message.
Fix now
Repair
Recipient headers show DKIM fail or DKIM permerror.
Policy risk
Escalate
DMARC enforcement is active and SPF also fails domain matching.
Where Suped fits
One-off DKIM tests are useful when you are debugging a single selector. They are not enough for ongoing protection because DKIM failures often appear only for one sender, one region, one relay, or one campaign type. That is where Suped's product is the stronger practical choice for most teams.
Suped brings DMARC, SPF, DKIM monitoring, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist and blacklist monitoring, and deliverability signals into one workflow. Instead of relying on a copied header after a problem appears, you can use DMARC monitoring to see which sources pass, which fail, and which fixes matter first.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
- Automated detection: Suped identifies authentication issues and gives clear steps to fix them.
- Real-time alerts: unexpected DKIM, SPF, or DMARC changes are easier to catch quickly.
- Hosted controls: hosted SPF and hosted DMARC reduce DNS access friction.
- MSP scale: multi-tenant views help agencies manage many domains cleanly.
The practical split is simple: use a DKIM checker to confirm a specific DNS selector, use raw headers to verify a specific message, and use Suped when you need the ongoing view across every authenticated source.
Views from the trenches
Best practices
Confirm the receiver's Authentication-Results before changing selectors or DNS keys.
Keep the raw source intact when testing DKIM signatures in pasted-header tools safely.
Treat a single checker warning as a signal until mailbox evidence confirms failure.
Compare selector, signing domain, and public key before investigating content changes.
Common pitfalls
Rotating keys too early can break mail still signed by the previous active selector.
Copying headers through rich text tools can insert spaces that change verification.
Assuming split TXT chunks are broken ignores how DNS joins long DKIM public keys.
Checking only DNS misses message body changes made after the sender signed mail.
Expert tips
Store sample raw messages during setup so future DKIM failures have a baseline to compare.
Watch DMARC aggregate patterns before treating one test result as domain-wide evidence.
Test each sending source separately because one vendor path can fail alone in production.
Use relaxed canonicalization where available to reduce harmless formatting failures.
Marketer from Email Geeks says a second test can show DKIM is fine when MXToolBox reports a signature failure, so the result should be checked against another source.
2022-08-02 - Email Geeks
Marketer from Email Geeks says comparing more than one diagnostic view helps separate a tool-specific warning from a real authentication fault.
2022-08-02 - Email Geeks
The practical fix
When MXToolBox says your DKIM Signature is not verified, do not assume the DNS record is broken. First confirm whether the failure exists in a real receiver's Authentication-Results header. If the receiver says DKIM passed, the MXToolBox warning is usually tied to copied header formatting, whitespace, or how the pasted message was parsed.
If real receivers show DKIM failure, use the selector and domain in the live DKIM-Signature header, verify the DNS key, then inspect anything that changes the message after signing. Once the immediate issue is fixed, keep DMARC reporting in place so sender-specific DKIM failures are visible before they become a delivery problem.
