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:
- IF you see d=*.onmicrosoft.com, AND
- IF you remove ‘selector1/2-‘, AND
- 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)
- 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.