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

  • Anonymous
    October 18, 2016
    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?
    • Anonymous
      October 18, 2016
      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.
      • Anonymous
        October 18, 2016
        I see. Thanks!
  • Anonymous
    October 18, 2016
    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.
  • Anonymous
    November 14, 2016
    > 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?
    • Anonymous
      November 14, 2016
      I am not sure, I think it's strict.
    • Anonymous
      December 21, 2016
      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
  • Anonymous
    November 20, 2016
    The comment has been removed
    • Anonymous
      November 21, 2016
      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.
      • Anonymous
        November 23, 2016
        I saw it impacts emails from various companies using NeolaneBut I found a case from smartfocus too:https://www.junkboxmonitor.com/img/2016-11-24_02h30_07.pngThey are pretty big companies. Is there a risk for deliverability ?What is strange is that there is no problem with other webmails (gmail, aol...)
  • Anonymous
    May 10, 2017
    The comment has been removed
    • Anonymous
      May 12, 2017
      This header you copy/pasted:-------authentication-results: RECIPIENTDOMAIN.COM; dkim=none (message not signed)header.d=none;RECIPIENTDOMAIN.COM; dmarc=none action=none header.from=OURDOMAIN.COM;-------That's the header of the message that goes through the spam filter on the way out, but a DKIM signature is applied after that. The true Authentication-Results header should start with the SPF result.You have to send the message and then check it at the recipient to see the full headers for Authentication-Results.
      • Anonymous
        May 12, 2017
        Okay. This was pulled from a rejected email (bounce notification details sent back to the originator), so I will see if I can get one delivered to the receiver and then capture the headers on the receiving side.