Office 365 low hanging security fruits - DMARC

How you do implement basic security policies for your company's Office 365 system? As mail systems are usually the main target for your average cyber criminals, a quick strategy was needed to harden the first line of defense against this attack vector. The measures I came up with are luckily not any kind of rocket science and easy to implement even by not so experienced O365 admins, as they are well established and around for quite a while by now. But they are a great way to harden your network and protect your users against cyber criminals with just a few hours of work. This is a three part series, starting with how to implement DMARC for your Office 365 Exchange Server.

This is a multi part security series for O365 with the following articles:

• Part 1 - DMARC
• Part 2 - Mail tagging
• Part 3 - MFA
• Part 4 - Alerts

Introduction

The first focus will be DMARC (Domain-based Message Authentication, Reporting and Conformance), using DNS Records in connection with SPF and DKIM. The whole protocol is described in the RFC 7489, but it might be overkill to read the whole thing 😉 The general idea of DMARC is to validate if a mail was actually sent by the claimed address. This kind of spoofing/impersonation can be hard to spot, and especially untrained users might fall for these kinds of mails. The main goals of DMARC are

• Validate if the sender is authorized to send a mail from the given domain
• Specify how to handle mails which failed this validation
• How to notify and give Feedback to the owner of the domain

This helps to show that DMARC is not only a Spam protection but also gives you as an administrator an option to check if your domain is used for malicious mails. If both the sender and the receiver domain use DMARC the number of spoofed mails between the two domains should be reduced dramatically. On the technical side DMARC works together with the Sender Policy Framework (SPF) and the DomainKeys Identified Mail (DKIM). You will have to setup up both in order to get DMARC up and running for your O365 Domain. The inbound mail side is already handled by Microsoft, so no further action is required. However if you are using a custom domain (which this article assumes) and not the standard “.onmicrosoft.com” several actions are required for the outbound mail side.

Setup

Configuring SPF

The Sender Policy Framework is based on TXT resource record in the dns zone of your domain. It allows the recieving party of a mail to verify if the sender is authorized to send under the claimed name. Execute the following steps to set up SPF for your domain:

1. Check from what IP addresses the mails of your system are send (e.g. 89.175.3.5)
2. Verify which Microsoft services you are using to send mails (a great table for this can be found here)
3. Update the SPF TXT Record in the DNS Records of your domain according to these records
   • First you form the Record, e.g. if your mail system is hosted in the Office 365 Germany Cloud and you have one outbound mail server the record would look like this:
   spf.ps1

   v=spf1 ip4:89.175.3.5 include:spf.protection.outlook.de ~all
   

   
   In this case I used the soft ~all enforcement rule, because I was sure that there are no other sending servers in the environment, but couldn’t use with the hard -all rule as the goal is, to use in combination with DMARC.
   • Use the record to update the DNS entry for your domain. Keep in mind you only can have one SPF record per domain, so make sure you just update your exiting entry if one already exists.

Configuring DKIM

Next you want to implement DKIM for your domain. DKIM simply adds a digital signature to your mail header based on your domain, in order to proof that the email sender is legit. Opposing to S/MIME or PGP it does not encrypt the mail and is not based on an individual account, but rather the domain in general. O365 automatically sets up a default DKIM setting for your domain, however you need to customize it in order to use it with DMARC. You need to add the public key + configuration to your CNAME DNS entry and then enable it in your O365 tenant. There essentially two main steps for this process:

1. Establish a connection with Exchange Online via Powershell
   • Set your credentials with
   connect.ps1

   $UserCredential = Get-Credential
   

   
   and enter your account details
   • Setup a connection to your tenant with
   connect.ps1

   $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
   

   Keep in mind that the URI might look different, based on what kind of O365 you are using, a good definition for this can be found [here]( https://docs.microsoft.com/de-de/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell?view=exchange-ps)
   

   • Open the session with
   connect.ps1

   Import-PSSession $Session -DisableNameChecking
   

   but make sure to close the connection when you are done with the command
   

   connect.ps1

   Remove-PSSession $Session”
   

   
   
2. Once you have successfully established a connection you can create the CNAME DNS records and set them active in the configuration. Keep in mind that you will have to do these steps for every custom domain you have active. You need to create two key, as these keys require a rollover from time to time. The good thing is that O365 will rotate the keys automatically for you, which saves you a lot of hassle.
   • First you create them with:
   dkim.ps1

   New-DkimSigningConfig -DomainName example.com -Enabled $false
   Get-DkimSigningConfig -Identity example.com | fl Selector1CNAME, Selector2CNAME
   

   
   and
   dkim.ps1

   Get-DkimSigningConfig -Identity example.com | fl Selector1CNAME
   

   • Publish these CNAME records in the DNS record of your DNS hosting provider. These should look like this:
   dkim.ps1

   selector1._domainkey  CNAME 3600  selector1-example-com._domainkey.example.onmicrosoft.com
   selector2._domainkey  CNAME 3600  selector2-example-com._domainkey.example.onmicrosoft.com
   

   • Keep in mind that it might take a few hours until these records are know to all global DNS resolvers. You can check it with:
   dkim.ps1

   Resolve-DnsName -Type cname selector1._domainkey.example.com | fl
   

   • Once these records are known to all DNS providers you can enable it with the command:
   dkim.ps1

   Set-DkimSigningConfig -Identity example.com -Enabled $true
   

   
   Or simply navigate to the DKIM settings in the exchange online web interface and enable it there for your domain.

Enabling DMARC

The third part is to finally setup DMARC for your domain. This is done by adding a DMARC TXT record for your domain. This TXT is valid for all subdomains as well, so you only need to set it once. An example for this would be

_dmarc.example.com 3600 IN  TXT  "v=DMARC1; p=quarantine"

where the TTL is one hour and the mails that fails the check. In this case I have set it quarantine, but you can also set it to reject or none. You can check if you have configured everything correctly by using a tool like this to inspect the header of your mails.