0123-The Exchange Online Best Practices Checklist
0123-The Exchange Online Best Practices Checklist
This resource corresponds to the Exchange Online Best Practices Checklist and is intended to
be used as a baseline for provisioning new Microsoft 365 tenants according to best practices.
Disclaimers
The instructions described in this book have been prepared with the utmost care. Each IT
environment has its own needs and works with its individual settings and software
configurations. No liability can be accepted for any errors or data loss during the execution of
the described procedures, scripts, and commands. Please evaluate PowerShell scripts and
cmdlets before making any changes in a production environment.
Due to the nature of a modern cloud service, the screenshots depicted herein might be different
from the layout and information displayed when you access the service.
Alex Fields
Having grown up in a family-owned small business, Alex started
adopting Microsoft technology to enhance business operations at
a young age. In his spare time after school, he gained experience
with Windows Server, Exchange Server, and the migration to Small
Business Server. After completing college (including a small detour to obtain a Master’s degree),
he returned to IT with a local Managed Services Provider, where he gained experience with more
modern Microsoft cloud solutions over the better part of a decade.
Today, Alex works independently helping Managed Services Providers and other IT Consultants
to adopt modern technologies and build Managed Services Practices on top of Microsoft cloud
services including Microsoft 365 and Azure. Alex currently lives in the Missouri Ozarks (USA). He
loves to write about technology topics, and shares his ideas, experiences, best practices, and
lessons learned with the community.
E-Mail Alex@itpromentor.com
LinkedIn https://www.linkedin.com/in/alexanderfields/
Twitter https://twitter.com/vanvfields
Blog https://www.itpromentor.com/
I describe the PowerShell commands required to change certain settings in this guide. I also
have some of these documented in my GitHub repository of scripts for Exchange Online.
Note that it can take several hours before the data is available for searching and for alert
policies to take effect. You can also achieve this by connecting to Exchange Online with
PowerShell and running:
Note: If you have Microsoft Defender for Office 365 plans, then this
screen will include many more default (a.k.a. System) alerts. Refer here
for more detail on the default policies included with each subscription.
The person monitoring this alert feed will need to investigate each alert and find out whether it
was an expected activity, or if it was illegitimate, and whether it indicates a breach or insider risk
event.
Consider configuring additional alert policies for monitoring important Azure AD activities, such
as changes to Conditional Access policies and application consent requests. See this script to
install several such policies that I recommend.
If you applied my Best Practices for Azure AD, then you should already have a Conditional
Access policy in place that will Block legacy authentication for all cloud apps, including SMTP.
Another option to disable SMTP auth globally is to run this command in Exchange Online
PowerShell:
See this article for more details on enabling or disabling SMTP auth per mailbox: Enable or
disable SMTP AUTH in Exchange Online.
In the Defender portal under Policies & rules, find Threat policies > Preset Security Policies.
While it is still possible to manage all of your individual policies separately of course, I still
recommend most small and mid-sized customers stick with the Presets. Especially because
Microsoft may update their best practices over time. With the presets in place, you will be
automatically upgraded when Microsoft adds or removes features, or alters settings based on
threats that Microsoft is seeing in the wild.
If you do decide to manage custom policies, then please refer to this Microsoft article for
guidance (and revisit on a regular cadence). It contains the full description of settings in each
policy so that you can re-create them for yourself, and customize from there. I personally hope
that in the future, Microsoft just gives us another easy button to “copy” the Presets to a custom
set of policies.
Regarding policy precedence: Strict overrides Standard overrides Custom overrides Default.
So, what does that mean? It means if you deploy a Preset policy, it will take precedence over
any custom or default policies you have out there. Remember that Strict will always outstrip
Standard; so, if a user falls under the scope of two policies, now you know which one wins.
If you want to configure the existing policies rather than using the Presets, refer to my script
Install-EXOStandardProtection.ps1, which will apply the same settings found in Standard
Protection. Note that you should add custom protected users and domains to the Anti-phish
policy after you run the script.
The Anti-spam outbound policy, which is not included in the Preset security policies, should be
set up to block this by default, but it is always a good idea to explicitly assign this setting value. I
suggest moving it from Automatic to Off (Forwarding is disabled).
The function of the SPF record is to advertise to the world who is allowed to send email on
behalf of your domain. When you build this TXT record, you should try to include as many
“legitimate” sources of email as you can. For example, for email that is hosted at Office 365, with
no other possible senders, then you only need the following:
For third-party software such as Mail Chimp, Constant Contact, etc., you can usually find their
SPF information using a quick Google search, or by contacting their support. For your own on-
premises apps or scan to email devices, you may want to include an ip4 entry for your
company’s external IP addresses.
Let us assume you had a combination of Office 365 for hosted email, Constant Contact for bulk
mailing/marketing emails, and an on-premises copier/scanner internally, with your
organization’s external IP being 87.65.43.21. Then you would have this SPF to publish:
TXT value:
v=spf1 include:spf.protection.outlook.com include:spf.constantcontact.com ip4:87.65.43.21 -all
By default, your “OnMicrosoft” domain already has DKIM configured and working. But if you are
bringing a “vanity” domain name such as contoso.com (most organizations are), then you will
need to setup DNS records for your domain(s), and then enable DKIM message signing in
Exchange Online.
You will need to build two CNAME records per domain for DKIM. The format is:
Next, in the Defender admin center, go to Policies & rules > Threat Policies and scroll down
under Rules to find DKIM. Pick the domain that you want to enable for DKIM signing.
In the right-hand flyout that appears, you can generate your DKIM keys for the selected domain;
you must publish these records via your DNS hosting provider.
NOTE: You should also work with third-party authorized senders get their DKIM
information and enable signing as well.
By way of example, here is what DMARC could look like for contoso.com:
However, when you are first rolling DMARC out, it is best to start with the policy set
to p=none, because this will allow you to take time to find legitimate sources of email and
update SPF and DKIM before moving the DMARC policy up to a setting of quarantine, or even
reject (the strongest setting).
From the Admin center, go to Settings > Integrated apps and click Get apps. From the store,
you can find the Report Phishing add-in here and click Get it now.
Finish the wizard to deploy this add-in for all users but note that it can take up to 12 hours to
appear in Outlook.
Constrain policy to
either Users or
Record types
You can also enable per-mailbox audit log retention values up to 365 days using Exchange
Online PowerShell:
$AuditLogAgeLimit = 365
Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled
$true -AuditLogAgeLimit $AuditLogAgeLimit
In order to enable these “application enforced restrictions,” you must first enable the
Conditional Access policy in Read-only mode via Exchange Online PowerShell:
Once that setting is in place, you must set up a corresponding Conditional Access policy in
Azure AD. Use the templates to deploy the policy called Use application enforced restrictions
for unmanaged devices. This is also described in the Intune Best Practices Checklist.
Set-OrganizationConfig -AutoExpandingArchive
To enable the archive mailbox for all users, connect to Exchange Online PowerShell and run:
Be aware that keeping too much data can be a risk as well for some organizations. I do not
recommend placing mailboxes on hold without an expiration date (or a policy that says: “keep
all items forever”) unless the organization has explicitly signed off on it.
From the Microsoft Purview Compliance center navigate to Data Lifecycle Management >
Microsoft 365. Go to the Retention policies tab and click Inactive mailbox.
When an employee leaves the company, they are typically replaced by a new hire. But when we
remove licenses from user accounts in Microsoft 365, the mailbox is also removed. While it is
possible to recover on short time horizons (e.g., 30 days), retention policies and legal holds will
Microsoft supports two methods for pulling these mailboxes back from the grave:
1. Recover the inactive mailbox (e.g., if the departed user returns to the organization) or
2. Restore the inactive mailbox to an alternate location (merge it into another mailbox)
Conclusion
Thank you for reading this guide! Again, this resource is meant as a baseline for best practices,
and it is not intended to be a comprehensive overview of every setting. Please test and confirm
anything you read here or on ITProMentor.com before implementing in real life.