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.


Comments (10)

  1. Alex3425623 says:

    It sounds like requiring the DKIM signature to be the same as (or align with) the domain in the Form: address would be a strong additional anti-spoofing criteria. If this is the case (which maybe it isn’t?), why is it that we cannot set this as a requirement in the Spam filters in Office 365?

    1. tzink says:

      It is legal to send email on behalf of another domain, and it’s quite common for these values not to align. For example, Office 365’s default DKIM signature signs with *.onmicrosoft.com for a domain so this will not align with the From: address (Google Apps does something similar).

      For anti-spoofing, Office 365 does a little more with domain reputation and checking to see when it’s okay to have them diverge vs. when it’s not permitted. What works in Consumer email filtering does not always work in Enterprise filtering.

      1. Alex3425623 says:

        I see. Thanks!

  2. I’d suggest that this might be worth correcting (the Authentication-Results: header, not any action that’s taken in response) as ARC begins to roll out. Having correct telemetry about third-party DKIM signatures will be relevant to downstream receivers, even if Hotmail/Outlook don’t want to make use of this information.

  3. Simon says:

    > the signing domain in the DKIM signature to be the same as (or align with) the domain in the From:

    ^^^ Is this strict or relaxed alignment in the DMARC sense?

    1. tzink says:

      I am not sure, I think it’s strict.

    2. Dennis says:

      Relaxed and strict.
      In DMARC terms Strict means the full domain used in the From: has to sign the message (subdomain.company.com). with Relaxed a signature of only company.com is enough

  4. Pascal says:

    from my side I saw on the same headers:
    dkim = pass
    dkim = fail (body hash did not verify)
    screen shot: https://www.junkboxmonitor.com/img/2016-11-20_19h24_51.png

    1. tzink says:

      I took a brief look, there looks to be a signing problem on the Neolane side, or its going through a routing path that modifies the message in transit before it is delivered to your domain.

      1. pascal says:

        I saw it impacts emails from various companies using Neolane
        But I found a case from smartfocus too:
        https://www.junkboxmonitor.com/img/2016-11-24_02h30_07.png
        They are pretty big companies. Is there a risk for deliverability ?
        What is strange is that there is no problem with other webmails (gmail, aol…)

Skip to main content