Why does DKIM fail for Outlook.com and Hotmail.com?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 Jun 2025
Updated 18 May 2026
10 min read
DKIM fails for Outlook.com and Hotmail.com when the message Microsoft verifies is not the same message your sending system signed, or when Microsoft cannot use the public key needed to verify the signature. The short answer is that most failures come down to one of these causes: MIME encoding changed after signing, the body or signed headers changed in transit, the wrong selector or key is published, the signing domain does not match the visible From domain closely enough for DMARC, DNS lookups fail, or the signer is using an old or malformed DKIM setup.
If the header says dkim=fail with text like signature did not verify or body hash did not verify, I treat it as a message integrity problem first, not a sender reputation problem. Microsoft can be stricter or simply more revealing than another receiver, so a message can pass at one mailbox provider and fail at Outlook.com or Hotmail.com.
Fast test: Check the selector, key, and signing domain with the DKIM checker before changing mail content or DNS.
Fast clue: A body hash error points at encoding, wrapping, tracking, footers, or another content change after DKIM signing.
Fast fix: Sign the final message after all HTML generation, MIME building, link rewriting, and footer insertion are complete.
The direct answer
Outlook.com and Hotmail.com do not usually break DKIM by themselves. They receive a message, fetch the public key from DNS, reconstruct the signed header and body according to the DKIM canonicalization rules, and compare the result with the signature. If the bytes no longer match, DKIM fails. That failure can be caused by your mail server, an ESP, a gateway, a forwarding service, a CRM, a mailing list, or a security appliance that changed the message after the signature was created.
The most common hidden cause is encoding. A message signed as one MIME structure can be re-encoded as quoted-printable, base64, or a slightly different line-wrapped body later in the route. relaxed/relaxed canonicalization reduces damage from simple whitespace changes, but it does not make DKIM immune to new MIME boundaries, changed transfer encoding, appended text, rewritten links, or altered signed headers.
Do not treat all DKIM failures the same
A dkim=none result means Microsoft did not find a usable signature to evaluate. A dkim=fail result means Microsoft found a signature but verification failed. Those two results need different fixes.
None result: Look for missing signatures, unsigned mail streams, or a DKIM signer that skipped the message.
Fail result: Look for a bad key, body mutation, header mutation, encoding changes, or DNS lookup failure.
Outlook.com message header details showing a DKIM failure result.
Why Microsoft exposes the problem
Microsoft consumer mailboxes have a long history of surfacing DKIM edge cases that other receivers do not expose in the same way. The practical reason is simple: a DKIM signature is a cryptographic checksum over selected headers and body content. If any signed part changes, a strict verifier reports the failure. Another receiver can still accept the message, apply local reputation signals, or show a different Authentication-Results detail, but the underlying signature problem remains.
This is why the same email can look fine at one recipient and fail at Outlook.com or Hotmail.com. DKIM is not an end-to-end content approval system. It is proof that the signed content still matches what the signer created. Microsoft only needs one meaningful byte-level change in the signed body, or one missing DNS key, to mark the signature as failed.
DKIM passes
Body state: The body Microsoft receives still hashes to the same value in the bh= tag.
Header state: Every signed header in the h= list still has the same canonical value.
DNS state: The selector resolves to the correct DKIM public key when Microsoft checks it.
DKIM fails
Body state: A footer, tracker, MIME rewrite, or encoding conversion changed signed content.
Header state: A relay rewrote a signed header such as Subject, From, Date, or Message-ID.
DNS state: The selector points to an old key, a malformed TXT record, or no reachable record.
How to read the failing header
Start with the raw headers from the message that arrived in Outlook.com or Hotmail.com. Do not rely only on your sending platform's delivery log, because the log shows what it sent, not what Microsoft verified. I compare the received header, the DKIM-Signature header, and the Authentication-Results header together.
A domain-level scan helps catch DNS mistakes before you inspect a full message route. Suped's domain health checker can check the surrounding DKIM, SPF, and DMARC setup, which is useful when a Microsoft failure is only one symptom of a wider authentication problem.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Encoding and MIME changes
Encoding issues are easy to miss because the message still looks normal to a human. The visible HTML can be identical while the wire-format body has changed. DKIM verifies the canonicalized source, not the rendered email. A platform can build HTML, sign it, then another layer can rewrap long lines, convert line endings, alter MIME boundaries, change content-transfer-encoding, append an unsubscribe footer, or rewrite links. Any one of those changes can invalidate the body hash.
When I see a Microsoft result that says body hash did not verify, I stop looking at sender reputation and start comparing the source message before and after the final outbound hop. That specific error means the bh= tag no longer matches the body. The linked page on body hash failures goes deeper on that specific symptom.
Flowchart showing how message changes after signing cause DKIM failure.
Encoding checks that find real faults
Compare source: Save the message source immediately after signing and compare it with the source received at Microsoft.
Check transfer: Look for changed content-transfer-encoding values, especially quoted-printable and base64 conversions.
Review wrappers: Disable link tracking, open tracking, disclaimers, and footers for one test send.
Move signing: Put DKIM signing at the last system that touches the message body.
DNS and selector problems
If the body did not change, inspect DNS next. Microsoft needs to retrieve the public key at a name built from the selector and signing domain. For a signature with s=s1 and d=example.com, the lookup is at s1._domainkey under that signing domain. A stale selector after key rotation, split DNS behavior, a TXT record copied with missing quotes, or an oversized key published incorrectly can all produce DKIM failure.
DKIM TXT record shapedns
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
Do not test only the DNS record you intended to publish. Test the exact selector and domain in the DKIM-Signature header that Microsoft evaluated. If your ESP signs with a subdomain, a custom bounce domain, or a vendor-controlled domain, the record you check by habit can be the wrong record.
Wrong selector: The header uses selector s1 but DNS only has s2.
Wrong domain: The key exists under the visible From domain, but the signature uses a subdomain.
Bad record: The TXT value has broken quoting, extra spaces inside the key, or copied control characters.
DNS failure: The record works from one resolver but times out or returns inconsistent values elsewhere.
How this affects DMARC
A DKIM failure at Outlook.com does not automatically mean DMARC fails. DMARC passes when SPF passes with the visible From domain, or DKIM passes with the visible From domain. If SPF still passes for the right domain, DMARC can pass even when DKIM fails. If SPF also fails, or SPF passes for a different return-path domain, then the DKIM failure can become a DMARC failure.
This is where aggregate reports matter. A single header tells you one message failed. DMARC monitoring shows whether Microsoft failures are isolated to one stream, one selector, one vendor, or one gateway. That pattern is often the difference between a quick DNS fix and a full sending-path change.
Authentication outcomes to separate
Use DMARC reports to split Microsoft traffic by the result that actually changed.
Pass
DKIM fail
DMARC fail
Other
Suped is the best overall practical choice for most teams when this becomes more than a one-off header check. Suped's platform brings DMARC together with SPF, DKIM, blocklist monitoring (blacklist monitoring), hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and clear fix steps. The useful part here is not only seeing that DKIM failed. It is seeing which sender, selector, IP range, and domain policy created the failure.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A practical diagnostic sequence
The cleanest way to troubleshoot is to separate signing, DNS, and content mutation. If you change all of them at once, you can make the failure disappear without learning which system caused it. I prefer a sequence that moves from the cheapest proof to the most disruptive change.
Capture headers: Send one fresh test to Outlook.com and save the complete raw headers from the received message.
Read the result: Separate dkim=none from dkim=fail before changing anything.
Check DNS: Query the exact selector and signing domain in the failing DKIM-Signature header.
Test plain mail: Send a simple text-only message through the same route to remove HTML and tracking variables.
Disable modifiers: Turn off click tracking, open tracking, content filters, footers, and outbound disclaimers for one send.
Move signing: Make the last mail system that touches the body also be the DKIM signer.
Watch reports: Confirm the fix across Microsoft traffic instead of trusting one successful test message.
A good fix is repeatable
One passing test is useful, but the real proof is repeated Microsoft traffic with DKIM pass and stable DMARC results across the same sender. Suped's automated issue detection and real-time alerts help catch the return of the same failure after a template edit, ESP migration, key rotation, or DNS change.
When the failure is not actually DKIM
Some Outlook.com and Hotmail.com delivery problems mention DKIM even when the root cause is broader. A bounce can reference authentication, policy, or access denied errors while DKIM itself passes. Microsoft also uses composite authentication, reputation, user complaint data, and policy signals in delivery decisions. That means a clean DKIM pass does not guarantee inbox placement, and a DKIM fail does not always explain every rejection.
Separate cryptographic failure from delivery failure. If Authentication-Results says DKIM failed, fix DKIM. If DKIM passes but the message still bounces or lands in junk, inspect SPF, DMARC policy, sending IP reputation, complaint patterns, content, and Microsoft-specific rejection text. The page about Outlook deliverability issues covers the broader delivery side.
Result text
Likely area
Next step
body hash
Content
Compare source
no key
DNS
Check selector
access denied
Policy
Read bounce
dmarc=fail
DMARC
Review SPF
Use the exact Microsoft result text to pick the next step.
Views from the trenches
Best practices
Sign after final MIME generation so Outlook.com verifies the body you sent, not a rewrite.
Use the exact selector from failed headers when checking DNS, not the expected selector.
Keep one plain text test route available so HTML, tracking, and footers can be isolated.
Common pitfalls
Assuming relaxed canonicalization protects against encoding conversions after DKIM signing.
Checking only the parent domain when the DKIM signature uses a sending subdomain.
Treating a Microsoft rejection as DKIM failure before reading Authentication-Results.
Expert tips
Compare pre-sign and post-delivery source to prove whether the body changed in transit.
Rotate selectors slowly and keep old keys live until Microsoft traffic proves the change.
Track DKIM failures by sender and selector so one broken stream does not hide in totals.
Marketer from Email Geeks says Outlook.com and Hotmail.com can fail DKIM when encoding changes after signing, even with relaxed canonicalization.
2017-10-06 - Email Geeks
Marketer from Email Geeks says a DKIM fail result is different from a none result because Microsoft found a signature and could not verify it.
2017-10-06 - Email Geeks
What to do next
When DKIM fails for Outlook.com and Hotmail.com, fix the cause shown by the receiving header. For signature did not verify or body hash did not verify, look for encoding and content changes after signing. For missing or unusable keys, check the exact selector and signing domain in DNS. For DMARC failures, check whether SPF can carry the message while DKIM is being repaired.
The practical end state is simple: sign the final message, publish the correct key, keep the signing domain under the same organizational domain as the visible From address, and monitor Microsoft results over time. Suped helps with that workflow by turning raw DMARC and authentication data into sender-level issues, fix steps, and alerts, so the same DKIM problem does not return unnoticed after a mail-system change.
