DKIM fails for Outlook.com and Hotmail.com when the message Microsoft receives no longer matches the message that was signed, or when Microsoft cannot connect the signature to the right public key and signing domain. The common Outlook.com and Hotmail.com symptom is dkim=fail with a note like signature did not verify or body hash did not verify. That means Microsoft found a DKIM signature, fetched or attempted to fetch the key, and then the cryptographic check failed.
The fastest first step is to validate the selector, public key, and syntax with a DKIM checker. If the DNS record is valid, the next step is to compare the message source before and after delivery, because Outlook.com and Hotmail.com often expose MIME, encoding, footer, or tracking rewrites that other receivers do not flag as visibly.
The short answer
The direct answer is this: DKIM usually fails at Outlook.com and Hotmail.com because the signed bytes changed after signing. Encoding changes are the first thing I check, especially when the same message fails at both consumer Microsoft domains but passes elsewhere. The message body can change through quoted-printable wrapping, base64 conversion, line ending normalization, footer injection, click tracking, open tracking, unsubscribe rewriting, or an MTA that modifies MIME boundaries after the DKIM signature has already been added.
- Encoding: Quoted-printable, base64, 8bit conversion, and line wrapping can change the body hash.
- Rewrites: Footers, tracking links, open pixels, and unsubscribe headers must be added before signing.
- Selector: A stale selector, wrong key, malformed DNS TXT record, or bad key split breaks verification.
- Domain: The DKIM signing domain must be intentional and compatible with the visible From domain.
Do not treat Outlook.com and Hotmail.com failures as random receiver behavior. If both fail in the same way, there is usually a repeatable difference in the delivered message, the DNS key, or the signing identity.
What dkim=fail means at Microsoft
The distinction between dkim=none and dkim=fail matters. None means Microsoft did not find a usable DKIM signature for the domain it evaluated. Fail means a signature existed, but the signature could not be verified against the public key and canonicalized message. That points you toward message mutation, a bad key, a selector issue, or a signing bug.
Example Microsoft authentication resulttext
Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=fail (body hash did not verify) header.d=example.com; dmarc=fail action=none header.from=example.com
A public Microsoft Answers case describes the same type of Hotmail-only body hash symptom. A Plesk forum case also shows the classic pattern: DKIM appears configured, yet Hotmail reports that the body hash does not verify.
Outlook.com message details showing a DKIM body hash failure.
Common causes
When Outlook.com or Hotmail.com reports DKIM failure, I separate the causes into two groups: the message changed, or the signature/key cannot be trusted. That split keeps troubleshooting practical and stops the investigation from bouncing between DNS and content without evidence.
|
|
|
|---|---|---|
Encoding changed | Body hash fails | Sign last |
Footer added | Body hash fails | Move rewrite |
MIME altered | Body hash fails | Freeze MIME |
Wrong selector | Key fails | Publish key |
Stale key | Key fails | Rotate safely |
Header rewritten | Header fails | Reduce headers |
Domain mismatch | DMARC fails | Match domain |
Common Outlook.com and Hotmail.com DKIM failure causes.
The table is intentionally compact because the real work is confirming which category you are in. A valid DNS key does not prove the delivered message still matches the signed body. A matching From domain does not prove the signature itself verified. Keep those facts separate.
Encoding and body hash problems
The body hash is the DKIM hash of the canonicalized body. If Microsoft says the body hash did not verify, the body Microsoft evaluated is not the body your signer hashed. Relaxed canonicalization reduces sensitivity to whitespace at line ends and empty lines at the end of the body, but it does not protect you against real body changes. It also does not protect against every MIME or transfer encoding change.
What to inspect first
- Transfer encoding: Check whether a hop changed quoted-printable, base64, or 8bit content.
- Line endings: Confirm CRLF handling is stable through the final outbound MTA.
- MIME boundaries: Check whether multipart boundaries or content-transfer headers changed.
- Late changes: Move link tracking, footers, and unsubscribe text before DKIM signing.
If this is your exact error, use a focused body hash guide after you capture the raw source. Do not rely on the rendered email view. You need the raw delivered message, including headers and MIME parts.
DKIM signature fields to comparetext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date:mime-version:content-type; bh=Qm9keUhhc2hFeGFtcGxlMTIzNDU=; b=U2lnbmF0dXJlRXhhbXBsZTEyMzQ1...
Pay close attention to the h list. If your signer includes headers that later change, the signature fails even when the body is stable. For most marketing and product email, signing From, To, Subject, Date, MIME-Version, Content-Type, and Message-ID is common, but the exact set needs to match your mail flow.
Domain matching is not the same problem
A domain mismatch can break DMARC even when DKIM passes, but it is a different failure than signature verification. If your visible From domain is website.com and your DKIM signing domain is sub.website.com, relaxed DMARC domain matching normally treats that as related under the same organizational domain. Strict domain matching requires an exact match. Microsoft consumer inboxes also have a history of being sensitive to signing-domain choices, so I still prefer signing with the same organizational domain the user sees whenever that is practical.
Signature verification
This answers one question: did the signature verify against the public key and the canonicalized message?
- Pass: The signed content and key match.
- Fail: The signature, body hash, header hash, or key check failed.
DMARC domain match
This answers a separate question: does the authenticated domain match the visible From domain under your DMARC policy?
- Relaxed: A subdomain relationship usually passes.
- Strict: The authenticated domain must exactly match the From domain.
This is why I do not stop at domain matching when the result says signature did not verify. Matching domains answer the DMARC identity question. They do not prove that the DKIM signature is valid.
A practical diagnostic flow
The best diagnostic sequence is boring and repeatable. I start with DNS because it is fast to rule out, then move to message source comparison because that is where Outlook.com and Hotmail.com body hash failures usually become obvious.
Flowchart for diagnosing DKIM failures at Outlook.com and Hotmail.com.
- Read the result: Capture the full Authentication-Results header from Outlook.com or Hotmail.com.
- Check DNS: Confirm the selector exists, the key is current, and the TXT record is not malformed.
- Compare source: Save the signed outbound source and the delivered Outlook.com source, then compare MIME and encoding.
- Remove rewrites: Disable late footers, tracking, and gateway modifications, then send a clean test.
- Retest receivers: Send the same message to Outlook.com, Hotmail.com, Microsoft 365, Gmail, and one mailbox you control.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a wider check across DMARC, SPF, DKIM, DNS, and reputation signals, run the domain health checker after the focused selector test. That helps catch an adjacent problem, such as a broken SPF record or missing DMARC rua address, without distracting from the DKIM root cause.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Fixes that work
Once you know the failure category, the fix is usually direct. The main rule is simple: the last system that changes the message must run before the DKIM signer, not after it. If an ESP signs the message and then another gateway adds legal text, tracking, a security banner, or a MIME conversion, the DKIM body hash no longer describes the final message.
Troubleshooting signal strength
Use the receiver result to decide which fix path deserves attention first.
Strong body signal
Inspect rewrites
The result says body hash did not verify.
Strong DNS signal
Fix DNS
The selector or key cannot be found or parsed.
Strong identity signal
Fix domain match
DKIM passes, but DMARC fails.
Healthy signal
Monitor
DKIM passes and DMARC passes at Microsoft.
- Sign last: Move DKIM signing after content generation, tracking, footer insertion, and MIME assembly.
- Stabilize encoding: Set one transfer encoding policy and stop later hops from converting it.
- Simplify signing: Avoid signing headers that downstream systems routinely add or rewrite.
- Rotate keys: Publish the new selector before traffic uses it, then retire the old selector after queues clear.
- Retest Microsoft: Do not close the incident until Outlook.com and Hotmail.com both show a DKIM pass.
DKIM DNS record shapedns
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
If your failure only appears around Microsoft 365 rather than consumer Outlook.com or Hotmail.com, use the Office 365 DKIM path as a separate investigation. The symptoms overlap, but hosted Microsoft 365 mail and consumer Outlook.com mail do not always expose the same failure mode.
Where Suped fits
Suped is our DMARC reporting and email authentication platform. For this specific problem, the practical workflow is to use Suped to watch which sources fail DKIM at Microsoft receivers, separate verified and unverified senders, and turn the failure into a concrete DNS or mail-flow fix. That matters because one failing source can hide inside otherwise healthy aggregate DMARC numbers.
For most teams, Suped is the stronger practical choice because it brings DMARC monitoring, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, real-time alerts, and source-level issue detection into one place. The point is not just seeing a red DKIM result. The point is knowing which sender caused it and what to change next.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A good operating model is to pair one-off DKIM tests with continuous reporting. Use direct tests to prove the DNS and message source, then use Suped to catch the next Outlook.com or Hotmail.com spike before it becomes a deliverability incident.
Views from the trenches
Best practices
Sign after final MIME, footer, and tracking changes so DKIM covers the final bytes.
Test with Outlook.com and Hotmail.com seed inboxes before increasing DMARC enforcement.
Keep selector records simple, current, and documented so stale keys are easy to spot fast.
Common pitfalls
Assuming dkim=fail means DMARC domain matching failed, when the signature did not verify.
Rotating DKIM keys without checking old selectors still used by queues or ESP pools.
Letting an MTA convert quoted-printable, base64, or line endings after DKIM signing.
Expert tips
Compare the signed source with the delivered source and inspect body hash differences first.
Use relaxed body canonicalization, but remove rewrite steps that alter MIME structure.
Monitor aggregate DMARC reports for receiver-specific failure spikes by sending source.
Marketer from Email Geeks says Outlook.com and Hotmail.com failures often start with the signing domain, especially when an ESP signs with a domain that differs from the visible From domain.
2017-10-05 - Email Geeks
Marketer from Email Geeks says dkim=none and dkim=fail need different investigations because dkim=fail means Microsoft found a signature but could not verify it.
2017-10-05 - Email Geeks
What to fix first
If Outlook.com and Hotmail.com both fail DKIM, start with the result string. Body hash errors point to encoding, MIME, footer, tracking, or other content changes after signing. Signature verification errors without a body hash clue point to selector, key, header, and signing configuration checks. DMARC failures with DKIM pass point to domain matching rather than the DKIM signature itself.
The fix that closes most of these incidents is signing the final message, not an earlier version. After that, validate the selector, send fresh tests to both Microsoft consumer domains, and keep monitoring aggregate reports so the same source does not quietly regress later.
