Office 365 is expanding its DKIM-signing to our consumer brands plus adding default signatures to enterprise email traffic

Here at Office365 and Hotmail/outlook.com, we are making some changes with regards to our DKIM-signing in both services. We believe in sender authentication, especially with regards to DKIM, and plan to sign 100% of all email in both services.

1. First, email traffic from our consumer brands will all be DKIM-signed (eventually)

First, Outlook.com and Hotmail.com are going to start rolling out DKIM-signing for outbound traffic originating out of Office365 for users that have been migrated off the old outlook.com/Hotmail stack and onto the Office 365 stack. We are about 1/3 of the way finished that, so not every email from those domains will have DKIM signatures.

Initially, we will (a) add DKIM signatures only to a handful of domains, e.g., to @gmail.com and @yahoo.com and a couple of others, and (b) it will slowly ramp up from a handful of mail servers to 100% of mail servers. (c) Then, we will start signing for all outbound traffic to all domains. This is to prevent this traffic from going from 0 to millions of new DKIM-signatures overnight.

These domains will sign with d= domains in the DKIM-signatures that match the domains in the From: address (e.g., d=outlook.com, d=hotmail.com) which means they will be DKIM/DMARC aligned.

You can read more about the outlook.com to Office 365 migration here:

- New ways to get more done in Outlook.com
https://blogs.office.com/2015/05/21/new-ways-to-get-more-done-in-outlook-com/

2. Second, all outbound traffic out of Office 365 will add a second signature

Updated on Jan 27, 2016

a) All outbound email for our enterprise traffic in the Office 365 service will start getting a default DKIM signature with d=office365.com for email that originates out of our normal risk delivery pools (i.e., email that is not marked as spam). This means there will be a From: domain that does not align with the d= domain in the DKIM signature.

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=office365.com

This second signature will be added because we use it to aggregate our outbound sender reputation at a service level rather than at an IP-level. We then use it to monitor our service’s spam/non-spam ratio and take action when we observe our users sending high volumes of spam. This helps us maintain good deliverability around the Internet.

This DKIM signature will not be DKIM/DMARC aligned, it is added for outbound spam prevention.

b) For email that originates out of our high risk delivery pools (i.e., email that is marked as spam [before we shut them down], NDRs, other questionable quality email), will have a different d= domain, we haven’t set it up yet but will probably be something like d=somethingAtMicrosoft.net.

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=somethingAtMicrosoft.net

You can read more about our outbound spam strategies here:

- Higher Risk Delivery Pool for Outbound Message
https://technet.microsoft.com/en-us/library/jj200746(v=exchg.150).aspx

- Configure the Outbound Spam Policy
https://technet.microsoft.com/en-us/library/jj200737(v=exchg.150).aspx

This DKIM signature will not be DKIM/DMARC aligned, it is added for the purpose of outbound spam prevention.

c) All traffic out of Office 365 should also have a second signature with either a From/d= aligned signature because the customer has set up DKIM signing, or a default signature we add on their behalf that looks like this:

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1; d=contoso.com

OR

From: Regular User <user@contoso.com>
DKIM-Signature: s=selector1-contoso-com; d=contoso.onmicrosoft.com

You can see we encode the From: domain into the selector in the event that a customer doesn’t set up DKIM in our UX. This is not yet deployed to our entire customer base but we are working on it (we have to update Active Directory for everyone and then publish DNS records and that takes time).

The custom DKIM signature will be DKIM/DMARC aligned. The default custom DKIM signature is not DKIM/DMARC aligned but with a simple adjustment of the DMARC algorithm (which we do internally), you can extract the domain from the DKIM signature and use it as de factor DKIM/DMARC alignment.

For more information:

- Exchange Online is rolling out default DKIM-signing to everyone
https://blogs.msdn.com/b/tzink/archive/2015/12/16/exchange-online-is-rolling-out-dkim-signing-to-everyone.aspx

- Manually hooking up DKIM signing in Office 365
https://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx

3. Third, there are some things to be aware of with these DKIM signatures

a) Some of these DKIM-signatures will be broken because our customers route email through Office 365 and then through other systems which modify the message.

RFC 6376 – the RFC that defines DKIM – specifically says to treat a message with a broken DKIM signature as an unsigned message. This is because a DKIM signature may not survive forwarding along the Internet (headers get added, footers get added, messages get formatted, From: addresses get rewritten, etc.). For this reason, a message with a broken DKIM signature out of Office 365 should definitely not be rejected because there is a lot of legitimate email that may become modified.

DomainKeys Identified Mail (DKIM) Signatures
https://tools.ietf.org/html/rfc6376

6.1. Extract Signatures from the Message

Survivability of signatures after transit is not guaranteed, and
signatures can fail to verify through no fault of the Signer.
Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all.

6.3. Interpret Results/Apply Local Policy

In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any
signature or on an unverifiable signature; such rejection would cause severe interoperability problems.

If a receiver does choose to reject messages on an invalid DKIM signature, they can either disable that functionality, exclude it for messages originating out of Office 365, or accept the false positives associated with this configuration.

b) Finally, our consumer traffic may or may not have the second DKIM signature with d=office365.com.

These are the changes that are coming to both services. For the average user, the changes will be transparent to you, you won’t notice anything different. However, what we as an industry use them for are antispoofing checks; antispoofing failure mitigations (an email that originates out of outlook.com which is forwarded will fail SPF but pass DKIM and therefore DMARC); better sender authentication which means that 3rd parties can block more spam, that is, suspicious email “from” outlook.com; better reputation tracking for email originating out of Office 365; improved deliverability to 3rd party services; and finally, compliance with industry best practices.

Thanks for reading.