Hotmail/Outlook.com evaluates DKIM a little differently than Office 365

If you're a user in Hotmail, Outlook.com, or any other of Microsoft's consumer email services, you may notice that it evaluates DKIM a little differently than you might expect (you would only notice this mostly as someone who is trying to troubleshoot delivery, as an average user you probably wouldn't notice it at all unless you were forwarding email).

Suppose you get a message that is DKIM-signed by a large email provider, let's called them bulksender.com. They are sending email on behalf of a financial institution woodgrovebank.com. Bulk Sender sends the email campaign and sets themselves as the SMTP MAIL FROM, and signs it with their own DKIM key. Woodgrove Bank has neither SPF nor DKIM nor DMARC records set up. So we have the following:

 Return-Path: <notifications+random_guid@bulksender.com>
DKIM-Signature: v=1; s=s1024; d=bulksender.com; q=dns/txt; c=relaxed/relaxed;
From: Woodgrove Bank <notifications@woodgrovebank.com>

Many different email services would evaluate the SPF, DKIM, and DMARC on this message and combine the results afterwards, and put them into the Authentication-Results header. For example, Office 365 would do this:

 Authentication-Results: spf=pass (sending IP is 1.2.3.4)
  smtp.mailfrom=bulksender.com; dkim=pass (signature was
  verified) header.d=bulksender.com; dmarc=none action=none
  header.from=woodgrovebank.com

However, Hotmail/Outlook.com makes a key difference [1] - it will not say that DKIM passed if the signing domain is not the same as the From: domain, for example:

 Authentication-Results: hotmail.com; spf=pass (sender IP is 1.2.3.4)
  smtp.mailfrom=notifications+random_guid@bulksender.com;
  dkim=none header.d=woodgrovebank.com; x-hmca=pass
  header.id=notifications@woodgrovebank.com

Even though the DKIM signature should have passed, Hotmail says that DKIM did not exist even though it has a header.d value.

The reason for this is that Hotmail expects the signing domain in the DKIM signature to be the same as (or align with) the domain in the From: address. Because in this case the signing domain is different than the From: domain, Hotmail does not consider that to be valid.

This is basically an antispoofing mechanism that requires a tighter relationship between what the user sees and who is authenticating the email. Even though DKIM does not require they be the same, and DMARC uses one or the other of either SPF or DKIM, Hotmail takes it a step further by not letting the sender send on behalf of another without the From: domain giving explicit consent (by setting up a public DKIM record). The fix for this is for the domain in the From: address to set up a public DKIM key at the same selector that the email infrastructure is sending with.

So if you do see this behavior in Hotmail, that's what is going on.


[1] I just found out about this recently, so I thought I'd document this behavior in case anyone in the future ever asks.