Exchange Online is rolling out default DKIM-signing to everyone


If you are a customer of Office 365 (Exchange Online Protection, or EOP), you may have noticed, or will be noticing, that we are adding DKIM signatures to your outgoing email, even if you haven’t explicitly enabled DKIM-signing for your domain (see instructions here: http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx). We are gradually rolling this out to everyone.

If you haven’t enabled DKIM-signing, EOP will create a default signing policy for your domain and use those in the selector and d= field in the DKIM signature. For example, suppose the customer Contoso Organization signed up with an initial domain of contoso.onmicrosoft.com, and one of their provisioned domains is fabrikam.com. An outgoing message with a default signature will look like the following:

From: Second Example <second.example@fabrikam.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795;
    h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
    bh=<body hash>;
    b=<signed field>;

Don’t worry if you see this, it means that DKIM is being affixed properly. Assigning DKIM signatures to your domain will help improve your deliverability around the Internet, and it also means that you can send email over IPv6 even if you don’t publish an SPF record. It also helps receivers roll up domain reputation for your domain, instead of having to live within shared outbound IP space.

For verifiers, there is an algorithm we use to formulate the selector/signing domain:

  1. IF you see d=*.onmicrosoft.com, AND
  2. IF you remove ‘selector1/2-‘, AND
  3. IF you replace any dots in the From: address with dashes (e.g., fabrikam.com –> fabrikam-com) [1] and it matches the unremoved parts in the selector (e.g., selector1-fabrikam-com)
  4. THEN you can consider the message implicitly DMARC aligned.

The idea here is we, as Office 365, know who are customers are and can properly attribute the message but our customer may not publish an SPF record, or may even publish an incorrect one. We don’t have access to their DNS so we can’t publish the required CNAMEs, but we can put information into the headers of a message that uniquely identifies their domain because they have to put something into their DNS records to enable themselves as a customer of ours. As a receiver, you can use the above to unwind it.

I call this an implicit DMARC alignment, somewhat similar to a DMARC Best Guess Pass.

Next, if you enable DKIM manually, the selector and d= domain will change so that it aligns with the From: address:

From: Second Example <second.example@fabrikam.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1; d=fabrikam.com; t=1429912795;
    h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
    bh=<body hash>;
    b=<signed field>;

Every domain gets their own DKIM keys, they are not shared among customers. They are not even shared among domains within the same customer with the exception of when we cannot attribute a message to a particular organization (i.e., you send from a non-provisioned domain and we don’t know it’s your organization).

This is all part of our ongoing quest to ensure the best security experience for all of our customers.


[1] You can also get this information by doing an MX record lookup and using the <domainGUID>. For example, if the domain where fabrikam.com:

fabrikam.com.    3600  IN  MX  5 fabrikam-com.mail.protection.outlook.com.

The <domainGUID> is the part before .mail.protection.outlook.com. It will not always be the same as the dot/dash replacement I say above because the algorithm works a little differently for domains with dashes in it.

Comments (6)

  1. blaughw says:

    Looking great.  I happened to comment on a previous post about DKIM when I noticed this today.

    I do however, wish there was some **advance notice this was happening** (rolled into my tenant on 12/13/2015!).  This seems to be the order of the day in multitenant O365, though.

  2. gmic says:

    I agree advance notice would have been good. Caused us a few issues on 12/14/2015 and nothing out there to say it was going to happen!

  3. Affect on other servers sending mail as our domain says:

    Thanks for this info.

    Is there any expected affect on other servers sending mail as our domain, which we can't route through O365?

    Or 3rd party services sending as our domain?

    e.g., will some recipients see we have DKIM setup an DNS, receive an unsigned message, and score it lower in their incoming mail filtering?

  4. tzink says:

    This shouldn't have much effect on your other unsigned mail streams. While some 3rd parties may notice that some of your domain's email has DKIM and some doesn't, most receivers will still pass you with SPF-authenticated email.

    However, because DKIM has no standard place to publish the DKIM key, or indicate yes/no, it's hard to determine if DKIM is required by a particular domain. The only place you can sort of determine it is with a DMARC record, but even then DMARC lets you authorize with SPF-aligned email.

  5. Mike says:

    Can't wait to see native DKIM signing in on-premises Exchange 2016 as well. There are third-party plugins, but overall there are lots of bugs and added maintenance, so official support is desirable.

    1. tzink says:

      Mike,

      There are currently no plans to add native DKIM signing to any version of on-premise Exchange. The only options are to connect to Office 365 via a connector and rely upon EOP adding a DKIM-signature, or using a 3rd party plugin. The ones that I am aware of are:

      - DkimX, http://www.dkimx.com/
      - DKIM Signing Agent for Microsoft Exchange Server, https://github.com/Pro/dkim-exchange

Skip to main content