When is the right time to cut over your DNS MX record in a migration?

When is the right time to cut over your DNS MX record in a migration?

And the importance of accurate Directory Synchronisation

When is the right time to cut over your MX in a Migration? This is a question that is often posed to us, particularly when migrating from Lotus Notes and Domino to Office 365.

Your options are basically down to three:

Cut over the MX at the beginning, the middle or the end.  Our recommendation is to do it either at the midway point, or at the end when all mailfiles/mailboxes have moved over – but you HAVE to have all your DirSync ducks all in a row.

Midway point

At the midway point your IT teams and stakeholders are still fully engaged, the service has been tested with early adopters & pilot users and is now in production mode. The project still has high visibility. Raising a Change Request gets adequate buy-in and importance. At the midway point your Directories should be in sync and steady-state operations are well in place.

Now is a good time top make that change.

Why not at the beginning?

Change as little as possible.

There is enough change going on during migration and coexistence without having to throw this in the mix.  Much like the joiner/leaver process.  Maintain the status quo, the tried and trusted processes. Wait till you are sure the Directory Sync and Coexistence is working as designed, make sure you truly understand your curent routing matrix and topology as it changes over time with bolt-ons and different engineers, Is there an up to date routing diagram.

The current routing topology is working

There is a lot more to changing the inbound (and outbound) routing endpoints than just changing the DNS MX record at your NS host.

When all your production email from the internet is successfully routing into your Domino infrastructure, perhaps via an appliance such as Mimecast, Ironport, MailControl, Trend etc this is a well known set-up with all the routes in place.

Admins know the routing hops and paths, how to troubleshoot, which logs to look in, how to access those devices and export the logs.

The valid address lookups used by the message hygiene appliances are mature and robust and looking at ‘good data’ honed over a period of time.

SPF, DKIM, DMARC records are all in place and should be working well to keep out spam and ensure your outbound email is not getting flagged as junk.

SMTP Relay whitelists, TLS, S/MIME, Transport Rules, Journaling, Archiving, Compliance, Signatures are probably all configured and working well. Any routing toplogogy will impact those.

Note on SMTP Relays, particulary with Multi-Function Devices (MFDs), and poorly coded Domino Applications. If the SMTP envelope is not correctly formed with the FROM information and resolvable in a lookup, some non Domino mail systems are less forgiving and will reject the messages.

AGAIN – changing outbound and inbound routing is more than just flipping the external DNS MX record.

Technology considerations

Domino inbound mail processing rules

Valid Domains are listed in Domino on the Global Domain Document (GDD). Domino has a particular set of routing rules that the router task works through.  It supports slightly more fuzzy routing that Office 365 EOP/EXO does.  Domino basically will allow email addressed to leftpart for any domain without it being explicitly listed on a Person Document.

e.g. Domino might accept mail for contoso.com, fabrikam.com, tailspintoys.com, but my Person Document may only have a primary smtp address of conrad.murray@contoso.com. But, becuase Domino accepts for all the other Domains, it will route to me by dropping the domain part and then looking up the local part “conrad.murray”. So as long as that is a match, I can receive email for conrad.murray@fabrikam.com conrad.murray@tailspintoys.com There is a wee bit more to Domino routing and is in another blog I wrote: https://www.neroblanco.co.uk/2015/03/exchange-to-domino-routing-rules-specifically-relating-to-binary-tree-coexistence-solutions/

Exchange inbound routing rules

Exchange Online / Exchange Online Protection expectsa recipient to have the exact unambiguous match on the destination address listed on the object. Either as a PrimarySMTPAddress or listed in teh proxyAddresses attribute for secondary (alias) addresses.

Directory Synchronisation

MUST be in place and robust

At the start of the project, all our mail objects are present in IBM Domino. All alternate email addresses are accounted for in fullname/shortname fields and variations.

Now, when we introduce directory synchronisation into the picture, it will go ahead and create (or update) objects from Domino in to the On-Premises Active Directory, an onwards to Azure AD via AAD Connect.

This process requires a collaborative design to ensure that our users are updated correctly based on matching attributes. We need to make sure attribute mappings are correct and that any attribute overrides and re-writes match the client’s needs. DirSync will be creating brand new Distribution Groups, Security Groups, Rooms & Resources and Mail-In Databases (Shared Mailboxes) that have almost certainly never existed in AD are created correctly. 

Working example


Now consider this use case.  I have deliberately detailed this at the far end of a potential use case, but it is not taht unusual, so take your own situation from it.

  • Organization: CONTOSO LIMITED
  • Accepted Domains: contoso.com, fabrikam.com, tailspintoys.com
  • User: Phillip Graham-Smythe
  • Job Title: CEO and Sales Director

His Person Document it might look like this:

Now as cluttered as this looks, this allows for sender-based typos for commonly misspelled names (becuase we’re nice admins). It also includes a previous Notes hierarchical name from a Domino Domain consolidation. Lastly an employee that left the organisation from the Sales team (Craig Green) was added to his Person Document as a catch-all for their inbound emails.

So, as a result of this there are (deliberately for this article) many name variations.

The list could of course be longer had this been a user that got married and changed their last name and so on.

Now, if you don’t plan for DirSync properly you will most likely just take over to the Office 365 GAL this users’ primary SMTP address:

“Phillip Graham-Smythe” < Phillip.Graham-Smythe@contoso.com >,

and in doing so when the MX is switched to EOP/EXO, any emails sent to the following list will bounce.

Alternate Domains

Phillip with “one L”

Variation spelling of surname Smyth v Smyth

Variation spelling of surname Smyth v Smyth and Phillip with “one L”

Variation spelling of surname Graham v Graeme

Variation spelling of surname Graham v Graeme and Phillip with “one L”

Former employee

Mail-in Databases and Distribution Groups

Now also look at these Mail-In Databases and Groups.  They do not have an Internet Address, so even in a DirSync model they will fail to synchronise to AD and Office 365, so cutting over teh MX before remediating these would cause email to fail for them unless your Domains are set to external relay, but that defats the purpose of the MX cutover in my opinion.

However, as Domino does not require objects populated with a SMTP address it will accept inbound email just fine for these objects.

In closing

Keep the MX pointing to source during the main migration and coexistence phase.  These types of oddities above will typically raise themselves to the surface over the course of the project and get fixed along the way without causing too much mass outages and disruptions for users.

Nero Blanco have delivered these types directory synchronisation solutions countless times and aware of the gotchas and common issues.  So if you need to some help and assistance, don’t hesitate to get in touch.

Next time…

When the Office 365 early adopters and pilot users create Microsoft Teams (and Unified Groups) with the same name as an On-Premises Group that has not yet sync’d… cue AAD Connect sync error.