SOLVED

DKIM with Office365 Confusion

Iron Contributor

I have some confusion on implementing DKIM/DMARC on our tenant. If I understand this article (https://docs.microsoft.com/en-us/office365/SecurityCompliance/use-dkim-to-validate-outbound-email) correctly; DKIM is enabled by default and only need to be address if you have multiple custom domains, use DMARC (recommended), want to change the CNAME, control the Private Key, or use a 3rd Party.  The later three I do not care about.  Its the first two.  However, we have several custom domains and DKIM appears to be working per the message headers.  (DKIM Signature shows pass and the expected details).  Also under Protection in EOP, DKIM is not enabled. Again, I assume that is expected.  So that is the first confusion. If it is working with multiple custom domains, then why is that the first reason listed on that page?    

Next, it mentions setting up a custom DKIM is recommended with DMARC. I want to enable this to reduce the phishing and spoofing we receive. Why is it recommended? There are no details on that. Since DKIM is working on our custom domains, can I simply skip that and setup DMARC? 

 

Thank you. 

3 Replies
best response confirmed by Jeff Harlow (Iron Contributor)
Solution

Hey Jeff,

Hopefully I can help with atleast some of your questions!

DKIM is configured for your custom domains as well by default, but it is just down automatically by Office 365. Microsoft originally sets up DKIM on your .onmicrosoft domain, and that can cause issues on custom domains if you are using DMARC, or are delivering to an email system that scrutinizes more. (more on this below) So i would expect the headers to show it working, and if you are just wanting to make sure its on, then yes you are good. So hopefully that helps address your first confusion. It is working because O365 does that by default, but its just an automated one they do for you. If you wanted to control it more, or have the same type signature for 3 domains, you would need to control/customize it. 

EOP is for inbound mail, not outbound. So DKIM turned off in EOP just means you are not checking all the messages inbound to make sure they have DKIM going. I would recommend this unless you start to get allot of fake mail from others, as many older/stand alone email systems are not using DKIM, and you will start blocking what is likely legitimate mail that is just not utilizing DKIM.

Finally i have always recommended controlling your own DKIM if you are going to DMARC just because you are then in control of it. I have always looked at it as a step up process. 
1. SPF - says an email should come form this domain in DNS
2. DKIM - says an email did come from a system (via a signature on the email itself)
3. DMARC - Owns the two above in one package, and provides clear instructions on how to handle it

DMARC takes SPF and DKIM a step further, adding a linkage to not only your company, but clear policies about how to handle the message, and messages from your domain. IE - Delete anything that doesn't pass those hurdles.

So if you have DMARC you are basically taking everything as far as you can by not only defining where it should be coming from, and singing the messages leaving your email system, but also providing instructions on how to handle the message, or any failures. Its a more complete package. 

I recommend the custom DKIM as then you are controlling the signature and not some third party, which means you know exactly what it is and it could match your own security policies. It also solves the fact that Microsoft users .onmicrosoft domain first/as the default. You have issues because the default DKIM configuration uses your initial onmicrosoft.com domain as the 5322.From address, not your custom domain. This forces a mismatch between the 5321.MailFrom and the 5322.From addresses in all email sent from your domain. So if you  setup a custom one, you dont have that mismatch.

Do you have to do that to do DMARC? No, but you could have problems without it.
Do you have to do DMARC? No, but if you are having a spoofing problem i would for sure recommend it!

Thank you Adam. You helped clarified the issues. Much appreciated. 

 

@Adam Ochs 

Hi Adam,

DKIM Settings within EOP are for Outbound - not Inbound. If you enable the setting messages from EOP will be added a DKIM Signature. If you want to check the DKIM for Inbound messages you need to create a transport rule for that.

BTW: EOP is for Outbound also - SPAM Check and Antimalware/Antivirus-Checks will be done for Outbound messages also.

1 best response

Accepted Solutions
best response confirmed by Jeff Harlow (Iron Contributor)
Solution

Hey Jeff,

Hopefully I can help with atleast some of your questions!

DKIM is configured for your custom domains as well by default, but it is just down automatically by Office 365. Microsoft originally sets up DKIM on your .onmicrosoft domain, and that can cause issues on custom domains if you are using DMARC, or are delivering to an email system that scrutinizes more. (more on this below) So i would expect the headers to show it working, and if you are just wanting to make sure its on, then yes you are good. So hopefully that helps address your first confusion. It is working because O365 does that by default, but its just an automated one they do for you. If you wanted to control it more, or have the same type signature for 3 domains, you would need to control/customize it. 

EOP is for inbound mail, not outbound. So DKIM turned off in EOP just means you are not checking all the messages inbound to make sure they have DKIM going. I would recommend this unless you start to get allot of fake mail from others, as many older/stand alone email systems are not using DKIM, and you will start blocking what is likely legitimate mail that is just not utilizing DKIM.

Finally i have always recommended controlling your own DKIM if you are going to DMARC just because you are then in control of it. I have always looked at it as a step up process. 
1. SPF - says an email should come form this domain in DNS
2. DKIM - says an email did come from a system (via a signature on the email itself)
3. DMARC - Owns the two above in one package, and provides clear instructions on how to handle it

DMARC takes SPF and DKIM a step further, adding a linkage to not only your company, but clear policies about how to handle the message, and messages from your domain. IE - Delete anything that doesn't pass those hurdles.

So if you have DMARC you are basically taking everything as far as you can by not only defining where it should be coming from, and singing the messages leaving your email system, but also providing instructions on how to handle the message, or any failures. Its a more complete package. 

I recommend the custom DKIM as then you are controlling the signature and not some third party, which means you know exactly what it is and it could match your own security policies. It also solves the fact that Microsoft users .onmicrosoft domain first/as the default. You have issues because the default DKIM configuration uses your initial onmicrosoft.com domain as the 5322.From address, not your custom domain. This forces a mismatch between the 5321.MailFrom and the 5322.From addresses in all email sent from your domain. So if you  setup a custom one, you dont have that mismatch.

Do you have to do that to do DMARC? No, but you could have problems without it.
Do you have to do DMARC? No, but if you are having a spoofing problem i would for sure recommend it!

View solution in original post