Del via

Exchange Online is rolling out default DKIM-signing to everyone

  • Artikel

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: https://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

  • Anonymous
    December 16, 2015
    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.

  • Anonymous
    December 21, 2015
    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!

  • Anonymous
    January 07, 2016
    The comment has been removed

  • Anonymous
    January 11, 2016
    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.

  • Anonymous
    July 02, 2016
    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.

    • Anonymous
      July 05, 2016
      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

  • Anonymous
    November 13, 2017
    Thanks, but no thanks Microsoft! Now our mail is about to being marked as spam!Stop thinking for your customers but think with your customers...Somehow it is has been activated just now and it is surely an unwanted change.