In this new mini series we are going to be looking at the tasks we should be undertaking when we first start to use Exchange Online. As with our other guides, we start with the basics and then move on with improving our posture over time as we know we cannot resolve everything at once. Securing our cloud infrastructure is a constantly moving target which we need to be regularly assessing and updating.
Disable Legacy Authentication.
First up let’s disable legacy authentication. As covered within our Securing Azure series Part 3, we can configure a conditional access policy to block legacy authentication however within Exchange online we still need to disable legacy authentication for Outlook clients and authenticated SMPT, as this is not covered by conditional access.
NOTE: If you have Security Defaults enabled, Legacy Authentication should already be disabled for Exchange Online, but it’s best to double-check.
Let’s head over to https://portal.office.com/ > “Settings” > “Org Settings” > “Modern Authentication”.
A side settings page will appear from where we can select the two available settings.
NOTE: We need to ensure that this will not negatively impact users so if you have an active tenant you must review sign in logs to assess where legacy authentication is still in use. This will prevent any mail clients or apps using legacy authentication from accessing email from Exchange. We can see a warning within this page below.
Email Forwarding for Administrative Accounts.
We also want to make sure we are forwarding emails for privileged accounts to a standard user account. We certainly do not want admin accounts being used to access, open and respond to email, so we need to ensure they are forwarded to the relevant standard accounts. Admin accounts receive notifications for all sorts of things within the Azure portal so this is an important step to ensure you are not missing any notifications. All users should have separate accounts for their day-to-day work, and for administrating the Azure portal or other privileged actions.
This can be carried out from https://admin.exchange.microsoft.com/ > Recipients” > “Mailboxes” > then select the privileged account who’s emails we want to forward. From the side menu that pops up enable “Forward all emails sent to this mailbox” then select the internal account we are going to forward the emails to.
Hit Save and that’s it, nice and simple.
Configure Email Authentication
NOTE: If you are using the @*.onmicrosoft.com domain for email then you will not need to set up SPF and DKIM however you will need to manually set up DMARC using the guide here.
In this guide we will be covering how to set up SPF, DMARC and DKIM, but we will not be covering ARC. Authenticated Relay Chain (ARC) is used with third-party services that modify messages in transit. You can find more information on ARC here,
We will also require access to our domain registrars’ DNS administration portal, and the ability to create new records. (This could be GoDaddy, Name Cheap, Google, or another of the thousands of registrars available).
SPF
The Sender Policy Framework is a txt DNS record which identifies valid sources and is designed to combat email spoofing. It allows you to publish a list of trusted IP addresses, which allows verification of which emails should be trusted for your domain.
As we are configuring an SPF record for an email service hosted entirely on O365 we won’t be using a list of IP addresses. If a different service or combination of services are in use, or if there are on-premises email servers then the record will not be the same as we will be using here.
Microsoft provides a nice table to help with configuring our txt record here.
From the above table we can see that numbers 1, and 7 are required with number 2 also relevant for our email infrastructure which is Exchange Online.
Therefore our spf record will be made up of the following lines.
v=spf1 (This states that this is an spf record)
include:spf.protection.outlook.com (Lists our sending servers)
-all (Enforcement setting)
We login to our DNS provider and create the following record
We need an spf record for every domain and subdomain, and in the case of subdomains you’ll need a record similar to the example below from the Microsoft website.
DKIM
Domain Keys Identified Mail (DKIM) is an anti-spoofing control that allows you to cryptographically sign email you send to show it’s from your domain, making it harder for criminals to send fake emails using your domain.
Although by default Microsoft will create keys for your customer domain it is not sufficient as we want to use DMARC. Therefore we will need to manually configure Domain Keys Identified Mail (DKIM).
First we need to head over to https://security.microsoft.com > “Email Collaboration” > “Threat Policies” > “Email Authentication Settings” > then select the domain we will be creating the keys for.
Select “Create DKIM Keys” and we get a pop up which provides the details we require to create the CNAME records within our domain registrars’ DNS administration portal. Add these records as explained, one entry is the hostname, the second is the address the hostname will point to. We need to create two CNAME records as explained within the portal.
Once these records are available, which may take a short while, we can enable DKIM within the same pane.
We select “Enabled” and get a pop up informing us it may not happen immediately.
Default key size is 1024 bit however we can increase this to 2048 bit, the guide to upgrade using PowerShell can be found here.
DMARC
DMARC is the key anti-spoofing control that organisations should implement, working alongside the standards SPF and DKIM. It allows you to set a policy for how receiving email servers should handle email which doesn’t pass either SPF or DKIM checks.
A good way to check if we currently have well configured email authentication records is by using the NCSC email check tool at https://emailsecuritycheck.service.ncsc.gov.uk/ and we will use this at the end to confirm we are correctly configured.
DMARC is a DNS txt record and identifies authorised outbound email servers, and this allows receiving email servers to verify emails have been sent from legitimate servers.
As we use O365 and Exchange online we do not need to configure anything for incoming email as it is already configured to perform certain actions when mail fails DMARC checks. We are able to configure safe senders lists, and other other settings to suit our organisation related to quarantine and rejection.
If you have a complicated email infrastructure then there is some best practice to consider before implementing a DMARC record as you could potentially lose legitimate mail if not configured correctly. We have a listed a few guides that are worth a read below.
We will require an email address which will be published in the txt record which will be the recipient for all DMARC reports.
The information in the reports will show
- Where the outgoing email from your domains originates.
- How it’s being handled by the major recipients. In other words, whether it has passed or failed the DKIM and SPF checks undertaken by the recipient.
We are going to configure our record with the policy set to “quarantine” as we have a very simple set up, however you may want to set the policy to “none” when you initially create the record to avoid losing any email. A policy of “none” sets the record to report only, which you can use to identify potential issues before using a more restrictive setting. Read the links above for more information on this.
Our record will contain the following.
_dmarc.yourdomain.co.uk. (We need to put “_dmarc” in front of our domain.
TTL=3600
IN=TXT (We are creating a text message)
v=DMARC1; p=quarantine (it’s a dmarc record, and the policy is set to quarantine, other options are “none”, and “reject”)
rua=mailto:dmarc-rua@yourdomain.co.uk (this is the email address where any reports will be sent)
We login to our DNS provider and create the following record.
And that’s it, we have now created our SPF, DKIM, and DMARC records.
To check the configurations we can use the NCSC’s free email checker tool here.
Here you can see we green for DMARC and SPF, however DKIM checks require us to send an email using the simple instructions provided on the website. When we do this we receive the following which confirms our records are correct.
We will look into MTA-STS in a future guide, but that’s it for now. In part two we will cover some more of the first tasks we should configure when using Exchange Online.
@2codemonte 