Migrating to and Using Microsoft Defender for Office 365

Microsoft Defender for Office 365 (MDO) is Microsoft’s response and feature set when it comes to e-mail security. Maybe some of you remember the previous name Advanced Threat Protection (ATP).

It includes many features starting with prevention and detection technologies for spam, phishing attacks, spoofing, AV and more, as well as a tools set for investigations, and finally responding capabilities to threats.

However, migration to MDO is not just a matter of updating MX records and keeping your fingers crossed! In our world today, there are many things you need to consider and plan for to complete a successful migration project. And here are some important points, to name just a few:

• DNS entries: It’s not only about MX records. SPF, DKIM and DMARC entries are very important as they contribute to your security.
• MDO policies: You need to have a good understanding of available policies and how they play together.
• Report of mail flow: You need to have a detailed and reliable report of your environment. This is crucial for SPF, DKIM and DMARC!
• Planning for end-user: End-users need to be informed or trained for the new solution. Communication is key, but also your support needs to be involved.
• Planning for responsibility: Depending on your structure, you might need to delegate certain permissions and roles in M365 to different departments and teams.

Microsoft recently published a detailed article, which guides you through most of the topics: "Migrate from a third-party protection service or device to Microsoft Defender for Office 365"

But it contains only migration steps from Microsoft's point of view! This means it contains only information about scenarios Microsoft-responsible persons can think of. Also, some important details are not documented (as of today!) in the features documentation.

One example:

Threat policies can be scoped to users, groups or domains. When scoping to domains, MDO evaluates policies ONLY on the user’s primary address and not to any other additional address with another domain:

Microsoft has documented information on creating pilot protection polices and it is important in case you are thinking about a domain for any testing or piloting purposes. You would need to make this domain the primary domain for testing and for the pilot!

DNS, just for resolving names?

That DNS is used only for resolving names has not been true for a long time. It is also used for technologies like Sender Policy Framework (SPF), Domain Key Identified Mail (DKIM) and Domain based Message Authentication Reporting and Conformance (DMARC).

Fellow friend and co-author Jaap Wesselius wrote about this in detail previously, "E-mail Security: How to Protect Against CFO Fraud".

What's important for your migration is that you know your environment. It could get ugly, when your LoB’ e-mails are failing due to missing SPF entries or non-existing DKIM signature. Also, keep an eye on limitation of your SPF record as there is a limit of 10 DNS lookups. Depending on a company's size and infrastructure, you must design this carefully.

When you use DMARC, make sure you use reporting (DNS entry:“rua=mailto:”) as Jaap outlined it. This will help to identify the sender using your domains.

But besides this, you should be aware that MDO supports DKIM, but it also has some limitations. When you’re using DKIM, you can use the same key for signing subdomains.

Assuming you have the following domains:

• contoso.com
• ny.contoso.com
• fra.contoso.com

In theory, you could use the key of the top domain contoso.com for signing both sub domains ny.contoso.com and fra.contoso.com. While other 3rd party security solutions allows you to do so, Microsoft requires that you create for each of your domains a dedicated configuration. Keep this in your mind when you setup a new sub domain!

Scoping policies

As previously mentioned, you can scope policies to users, groups or domains. At the same time, you can include recipients, you can exclude them. This comes into play when you have multiple policies, and you need to assign them to different recipients.

Note: Policies are processed in the order of their priority. If a policy matches a recipient, all other with lower priority policies are not applied and MDO is using ONLY the recipients PrimarySmtpAddress!

If you have recipients, which do not match any of your custom policies, they are covered by the Microsoft built-in policies. You can recognize them as they have “(Default)” in their name.

Tenant Allow/Block list

The feature Tenant Allow/Block List (TABL) allows you to allow or block certain sender or sending infrastructure. This is the part where you can also allow spoofing systems. Important fact: Microsoft distinguishes between internal (your own, registered domains) and external spoofing.

An overview about spoofing for the past 7 days can be found here:

Spoof Intelligence Insight - Microsoft 365 security

I should note that the block feature might not work as you would expect. MDO will not block a sender on SMTP protocol level. Instead, it will accept the message and send out later an NDR. This can be important depending on the laws and/or policies in your country/company.

Note: If you are planning to use the “Block sender” feature, you should be aware that senders won’t be blocked. Instead, the SCL level will be increased to 9 and the action is performed based on the assigned anti-spam policy. Read more about this on my personal blog here.

Non-Exchange online recipients

There might be a good chance that you do not have all of your recipients in Exchange Online or even on Exchange on-premises. Maybe you have some LoB, MTA’s and mail systems (e.g.: Postfix, Cyrus IMAP), where messages need to be routed and protected. If so, you need to take the following into consideration:

• MDO is not able to provide a quarantine for such recipients
• The attributes PrimarySmtpAddress and ExternalEmailAddress of the MailContact MUST have the same value. Otherwise MDO will treat this recipient as external like guest accounts and won’t perform any action

Especially the lack of quarantine options for such recipient can be challenging. Of course, quarantine in general is there, but only admins would have access to. No options for persons, which are responsible for such a contact to check false positive.

Tooling

After you have set up your final configuration across all the capabilities MDO provides, you should do your testing and piloting. There are many tools, which lets you send test mails to your organization.

However, I highly recommend having a look into SWAKS – Swiss Army Knife for SMTP. With this tool you can perform a huge variety of test as you can manipulate headers and mail properties like you want. With this you can perform tests like spoofing, SPAM, PHISH, GTUBE and more.

I can only emphasize that you should invest in MDO Plan 2 licenses for your administrative accounts. The new version is a great tool and gives you good insights:

And don’t forget to check the “Advanced filter”:

Summary

As previously mentioned, a migration to Microsoft Defender for Office 365 is not just a matter of changing DNS entries. In this article I mentioned some important facts, which should be considered in your project in addition to the migration guide provided by Microsoft.

With email being one of the most mission-critical tools for organizations today, how do you ensure vital business communication stays up and running? How do you demonstrate to senior management that additional resources are needed to meet growing demand or that service levels are being met?

Developed by Exchange architects with direct product input from Exchange MVPs, ENow's Mailscape makes your job easier by putting everything you need into a single, concise OneLook dashboard, instead of forcing you to use fragmented and complicated tools for monitoring and reporting. Easy to deploy and intuitive to use, get started with Mailscape in minutes rather than days.

ACCESS YOUR FREE 14-DAY TRIAL and combine all key elements for your Exchange monitoring and reporting to keep your messaging infrastructure up and running like a pro!

PRODUCT HIGHLIGHTS

• Consolidated dashboard view of messaging environments health
• Automatically verify external Mail flow, OWA, ActiveSync, Outlook Anywhere
• Mail flow queue monitoring
• DAG configuration and failover monitoring
• Microsoft Security Patch verification
• 200+ built-in, customizable reports, including: Mailbox size, Mail Traffic, Quota, Storage, Distribution Lists, Public Folders, Database size, OWA, Outlook version, permissions, SLA and mobile device reports