Moving mx records to O365

[skipster311-175]

Hello 

We are medium sized company, around 7000 mailboxes. We own several domains that we accept email for. Currently all mx records point to IronPorts. The emails are go through the messaging hygiene at  the ironports and then the message is delivered to Exchange online.

We want to move all mx records to O365. What i would like to understand, is what is the best strategy to do this? Should i move a domain that doesn't receive a high volume of mail traffic first. I think doing this will allow for fine tuning of the O365 filtering polices, and give us me some indication regarding how successful the move was and what the success rate will be for future domain moves. Also how should i construct my anti spam, anti malware polices? Should i start with the using Preset Security Policies" ? My concern with using the preset policies is you cant edit them. We will have a lot of safe and blocked senders that we will need to export from the IronPort's and import into O365. If i cant edit preset polices, then what is my best course of action? will i need to create custom polices ?

I know these are a lot of questions. I'm trying to understand how i should construct  the roadmap or process for moving domains to O365

Thank you 

[#2]

@skipster311-175 - Thanks for such a great question, and I'm super glad to hear you're going with MDO!

We have a detailed migration guide here you should find useful: Migrate from a third-party protection service to Microsoft Defender for Office 365 - Office 365 | Mi...

Speaking from my experience, I've done both the SCL-1 method detailed in the above guide, and your mentioned method of domain by domain. - Either way the desired outcome is the same, moving carefully and slowly to ensure minimal disruption, so that's completely up to you!

Regarding your comment for safe senders, my advice is that you shouldn't need to import a single safe sender, this brings legacy debt across to your new configuration and opens up holes in your protection stack. The good news however is that by moving slowly as you plan to, you can address senders one by one, sending test emails and then fixing issues with things like SPF/DKIM to ensure correct authentication and remove the need for a safe sender / allow list entry. 

However, these are sometimes required in situations where you don't control the sending infrastructure and for example the company who owns the sending infrastructure may not be in a position to support DKIM signing at this point in time - so I'd recommend using TABL here instead. (if however it's a false positive from our side, please report it to us so we can fix it!)

My final point is around preset policies, please do use them, it keeps everything up to date for you as / when we release new protection features, sets you up for continued success in the long term. - TABL will be honoured so if you do have to add a safe sender, this will be respected by the policy!

I wish you a really successful migration, and would love to hear how you get on, don't afraid to ask any other questions you may have, hopefully this has been helpful!

Thanks

Ben.

[#3]

Thanks Ben for the detailed information. I do like the idea of using preset security policies for the reasons that you mentioned, however if i cant edit them, then i fear it will open up the door to creating custom polices, to allow for things like block or allow bulk email. If i have to add a sender to skip spam filtering, is the recommended approach to use a transport rule , instead of adding the sending to allow list in anti spam policy ?

[#4 · Accepted solution]

You're so welcome!

So that's the beauty of TABL (see above link) - it will be honoured and is the correct new way to allow senders that are caught incorrectly, rather than in the spam filter policies or transport rules. (Please also do an admin submission!) - this way you can use secure presets and not need to edit them.

[#5]

Hi Ben

From my understanding around adding a sender to TABL is I have to use "Admin submission" I cannot add a sender using TABL. Is this correct? It does appear that I can use TABL to allow a spoofed sender ?

[#6]

If it's spoof, it should be as simple as the below steps :) (to allow)

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/allow-block-email-spoof?...

[#7]

I'd like to preface my reply by pointing out that I'm 4 years away from Asyncos; the last release note in my library is for version 11 and I can't remember if I implemented that or was still on 10 when I moved my MXs over to O365.

Definitely move a smaller domain first, just to get an idea of the differences in the two services and familiarity with the tools. With on-prem appliances you could make changes instantly and would have an accurate idea of message delivery within 3 to 5 minutes of the fact. With the cloud, you are waiting up to 30 minutes for mail flow rule changes and your delivery information is "near real-time" which can mean anything from minutes to hours.

How much work you have to do depends on how much effort you put into those IronPort configs. If you made your HAT more aggressive then you will probably want to set your SCL and BLC thresholds to be a little lower. If you differentiated your service (for example to allow devs or techs to handle file types you don't want near your ordinary recipients) then one-size-fits-all policies aren't going to work and you are back to writing policies for groups. If you ran a variety of different quarantines then now there's only one. You can differentiate items placed in the hosted quarantine by mail flow rules by adding an action to a rule to add a subject line stamp, but you can't do anything similar for policies.

If you used the Cisco Reporting plug-in for Outlook then that's got to go and be replaced by the Report Message add-in. That in turn may need a test as it's a bit picky on resources and uses a few things not in the published O365 resource list. If you enabled End User Quarantine, be aware that all Microsoft equivalents are serious phishing targets. If you ever regretted enabling EUQ, now could be an opportunity to reconsider.

You mention a lot of safe and blocked senders. Have you kept records of why they were included in their lists? Are we talking user decisions or tech decisions? Most tellingly, when did you last find time to review those listing? Safe list entries necessitated by sending organisation ineptitude will probably need to be replicated. For blocked senders, based on my own experience 4 years ago I would surprisingly agree with Ben's posting. I started with a reset of my block position and since then have only reinstated IP range blocks on a dozen ESPs. Again, having Report Message available and familiar to your recipients on day 1 will make that process easier.

Bear in mind that with Cisco the Talos list is transparent. The equivalent Microsoft edge protection is highly opaque, and you may not even be aware that it is blocking a sender unless they contact your organisation by other means. Your IronPort service will give you an aging view on what sending IP and envelope they used to use, after which the problem may become obvious. Your spam inflow is likely to radically change (as opposed to getting better or worse) when your MXs move. Mine did.

In summary, don't look for exact equivalences between Asyncos and MDO because you won't always find or need one. Accept that your organisation has chosen to use O365 and that it is going to be a major change in itself. No-one should expect things to be exactly as they were before.