What is this signed by onmicrosoft.com?
Microsoft has introduced a new feature called DomainKeys Identified Mail (DKIM). What this does is it takes the body of the email and uses that content to sign the email with a digital signature. This then allows a receiving mail server to verify that the message has arrived unaltered.
Ok, that’s all well and good and great, but I don’t want my recipients to see the tenant.onmicrosoft.com name. Afterall I send my email out with my domain name, why can’t I have it say signed by that domain?
The good news is that you can. The procedure is actually quite simple. There are just two steps involved for Office 365 administrators.
Step 1: Create the required DNS records
In DNS you will need to create two CNAME records:
- selector1._domainkey.<emaildomain> is a CNAME for selector1-<emaildomain with dashes>._domainkey.<tenant>.onmicrosoft.com
- selector2._domainkey.<emaildomain> is a CNAME for selector2-<emaildomain with dashes>._domainkey.<tenant>.onmicrosoft.com
So for example for us at Nero Blanco, we send all outbound email as @neroblanco.co.uk and our tenant is neroblancoit so we created:
- selector1._domainkey.neroblanco.co.uk is a CNAME for selector1-neroblanco-co-uk._domainkey.neroblancoit.onmicrosoft.com
- selector2._domainkey.neroblanco.co.uk is a CNAME for selector2-neroblanco-co-uk._domainkey.neroblancoit.onmicrosoft.com
Once you have created this you need to wait for DNS propagation to take place. It is safest to just leave it for 24 hours and then you can be pretty assured that it has all propagated.
EDIT: The emaildomain with dashes is actually the first part of your MX record. So for us our MX from Microsoft is:
neroblanco.co.uk MX preference = 10, mail exchanger = neroblanco-co-uk.mail.protection.outlook.com
So we use neroblanco-co-uk. Just take whatever is before mail.protection.outlook.com for your domain. This way if your domain has dashes in it you will have the right value
Step 2: Enable DKIM on your outbound email domain
Here you have two options:
- Use PowerShell to connect to your Office 365 tenant and run
New-DkimSigningConfig -DomainName '<emaildomain>' -Enabled $True
- Use the Exchange Admin Console to go to Protection and then click on the DKIM ‘tab’. Choose your outbound domain and click on Enable in the right hand pane.
If your DNS records have propagated then no error will be shown, otherwise you will see a message similar to the below
CNAME record does not exist for this config. Please publish the following two CNAME records first. selector1-neroblan-co-uk._domainkey.neroblancoit.onmicrosoft.com selector2-neroblan-co-uk._domainkey.neroblancoit.onmicrosoft.com
If you get the above error and you used PowerShell to create the DKIM Signing Config then use Set-DkimSigningConfig next time instead of New-DkimSigningConfig and use the same parameters.
If you did not get an error then you will have to wait for these settings to replicate around Office 365.
How do I know this worked?
If the above two steps worked for you and you waited for replication then when you send an email it should now show the correct mail domain as signing the email.
That was a quick run down on DKIM and how to configure it for Office 365
Hope you enjoyed the post! Below are some questions that often come up (or that I had myself)
Frequently Asked Questions
Does DKIM prevent SPAM?
No by itself DKIM does not prevent SPAM, but it does allow a recipient to check if the message came from your server and was not altered. So your next question will be, ok but if I can check that why can’t my server check that? The answer is it can but it would need to use either Author Domain Signing Practices (ADSP) or Domain-based Message Authentication, Reporting & Conformance (DMARC). Both ADSP and DMARC use DNS TXT records to suggest what to do with messages that do not pass validation. ADSP is purely for DKIM messages and is now marked as a historic standard, DMARC creates policies to verify both DKIM and SPF.
How does DKIM relate to SPF?
DKIM is all about protecting the message content, whereas SPF indicates which servers you are using to send email. Together they can be leveraged by Domain-based Message Authentication, Reporting & Conformance (DMARC) to publish policies in a DNS TXT record saying what should be done when DKIM and/or SPF fail.
Why are there two Selector records?
Because DKIM relies on public/private keys and with sufficient intercepted email and brute force it is possible to break the DKIM encryption, keys should be rotated on a regular basis. Rotated meaning that we use a new key for signing messages periodically. The message itself contains the name of the DNS selector record so as long as we leave the record in DNS then messages can still be validated.
In the case of Office 365 Microsoft rotate the keys for us. I am not sure how often this is but it could be as often as weekly. i.e. in Week 1 they sign messages using selector1 (it is the active selector). Selector2 contains the new key intended to be used in week 2. When week 2 starts Microsoft begin to use selector2 as the new signing key, and after a period of a few days it creates a new key for selector1 and publishes that in DNS. After the new key has been published then any email received by mail servers after that time won’t validate with DKIM, so it is important to leave enough time to ensure mail has been delivered.
How does DKIM actually work?
DKIM relies on private/public keys. The mail server has the private key and guards it with its life (ok well not literally) and the public key is published in a TXT record in DNS. Below we see the result of a DNS query for our current DKIM key.
> selector1._domainkey.neroblanco.co.uk Server: UnKnown Address: fddf:c06f:c0de:0:7e4c:a5ff:fecd:7ba8
Non-authoritative answer: selector1._domainkey.neroblanco.co.uk canonical name = selector1-neroblanco-co -uk._domainkey.neroblancoit.onmicrosoft.com selector1-neroblanco-co-uk._domainkey.neroblancoit.onmicrosoft.com text =
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCgsF84G1lgP5mwo mkX9Qfqodu3DFZZiKoGmsLEHy6yjg33jp8sw5GkBwdbmPLORJJPrhUo8ciLpainwU6mMy7ILIWXbpFHD EtLRsSkNYbnLovr1rDX7YB3E9V4NMeGlwqYdiMV9FvV/G24ygwUjegmo9OqkcMhukzDgrG56CG+8QIDA QAB; n=1024,1449795610,1" >
The p= portion of the TXT record is the public key in base64 encoded format. The receiving server uses this to validate the signature. Now where is the signature? If you open up an email in its raw format you will see the email headers and one of those headers will look something like the below.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neroblanco.co.uk; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=afqQX7XtPjxF74R5KLNPSIAJUS+2Z8A3xcZHbaGlYiM=; b=ZKzekwgXgq8yMNMi2CxPVxZFDozponS94wuV/XimXOyMrmtzevr82ZXVu2WN7HiZ3JvA08UK9KQ1/4IyuPPG5BL90NMWi1xVONkdhDUJxS2xLy+HR1BEEnRlaVFEa3xtahVu6XdzHr0hr4kATzc+LV6iFLkGda6lZ5lPGgrfyqc=
Here you can see that the DIM-Signature has many parts to it. Explaining each one we have
|c||canonicalization algorithm(s) for header and body||relaxed/relaxed|
|s||Selector Record in DNS that holds the public key||selector1|
|h||Header fields included in the signing process||From:To:Date:Subject:Message-ID:Content-Type:MIME-Version|
|bh||Hash of the email body||afqQX7XtPjxF74R5KLNPSIAJUS+2Z8A3xcZHbaGlYiM=|
|b||Digital signature of the selected headers and email body||ZKzekwgXgq8yMNMi2CxPVxZFDozponS94wuV/XimXOyMr…|
So the receiving server uses the public key to decrypt the signature, and also uses the public key to generate a hash value for the email body. If the hash value of the email and the bh value match then the first part of the test passes. The decrypted signature should include the header fields indicated by the ‘h’ value plus the body hash. If the header fields all match and the body hash matches the ‘bh’ value (and also the calculated value) then second part passes and DKIM as a whole will show a pass.
In the raw email we will see something to the effect of
Authentication-Results: mx.google.com; dkim=pass firstname.lastname@example.org; spf=pass (google.com: domain of email@example.com designates 220.127.116.11 as permitted sender) firstname.lastname@example.org
What about bulk mailing?
If you are using 3rd Parties to send bulk email, e.g Mailchimp then you will want to ensure that you have set up your SPF and DKIM appropriately. The simplest way to do this is to use a subdomain for bulk mail. That way your SPF and DKIM DNS records are totally separate from your normal mail delivery. If you don’t want to do that then you will need to ensure that you carefully combine the SPF for O365 with your bulk mail provider’s requirements taking care to not exceed the number of DNS lookups needed to resolve the SPF, and you’ll need to add the required DKIM records taking care that there are no name conflicts.
For MailChip they want you to set a CNAME k1._domainkey.<emaildomain> pointing to dkim.mcsv.net and a TXT record for SPF which contains v=spf1 include:servers.mcsv.net -all. Luckily MailChimp uses k1 and Office 365 uses selector1 and selector2 so we’re good from a DKIM point of view. For SPF you could make it ‘v=spf1 include:spf.protection.outlook.com include:service.mcsv.net -all’ however since both spf.protection.outlook.com and service.mcsv.net have a TXT record with yet more DNS lookups, this exceeds the number allowed. To resolve this you’d need to resolve one of the SPFs all the way down to IP ranges and put those in your DNS record. This of course then puts you at risk of the provider changing those IP ranges without notice.
Take my advice and use a subdomain, it is so much easier to manage and keeps the bulk email away from production email.
What about On Premise Exchange?
For On Premise Exchange you need a 3rd party product which is a transport agent that does the signing. There is even an open source one DKIM Signing Agent for Microsoft Exchange Server. You would need to distribute and manage the keys yourself, so it is a lot more cumbersome to set up than on Office 365. Who knows perhaps in Exchange 2020… :o)