Hotmail/ evaluates DKIM a little differently than Office 365

If you're a user in Hotmail,, 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 They are sending email on behalf of a financial institution 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: <>
DKIM-Signature: v=1; s=s1024;; q=dns/txt; c=relaxed/relaxed;
From: Woodgrove Bank <>

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; dkim=pass (signature was
  verified); dmarc=none action=none

However, Hotmail/ 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:; spf=pass (sender IP is;
  dkim=none; x-hmca=pass

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 (13)
  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 * 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 ( with Relaxed a signature of only 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:

    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:
        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…)

  5. Greg says:

    Hi Terry,

    Has the DKIM evaluation process changed recently? We are seeing some issues with our users/domain sending to another domain, with Microsoft mail products on both ends of the delivery attempt. Here is an example where the sending and signing domains are the same, DKIM signing is configured and passes with every other provider, yet the authentication-results say “dkim=none”:

    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;
    s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
    From: OUR USER
    authentication-results: RECIPIENTDOMAIN.COM; dkim=none (message not signed)
    header.d=none;RECIPIENTDOMAIN.COM; dmarc=none action=none header.from=OURDOMAIN.COM;
    Reported error: 550 5.7.1 Message rejected.
    Retry count: 1
    DSN generated by:
    Remote server: exchange.RECIPIENTDOMAIN.COM

    In the above, one of our employees is trying to send to a contact at another organization, but the message is bouncing (likely due to failed authentication). The From domain and the d=domain match, so it would seem that this should pass even using Microsoft’s different method for DKIM validation (requiring alignment like DMARC). I see no evidence of SPF checks on the message either, though our domain is configured to allow Microsoft to send on its behalf using SPF, too.

    If it matters, this was a meeting invite sent to a contact, generated by our user’s Outlook calendar by simply adding this contact to the meeting. If you would like to review full headers, just let me know how to get those to you.



    1. tzink says:

      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.

      1. Greg says:

        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.

Comments are closed.

Skip to main content